Workbook / requirement → current gold walk

Findings authored from evidence

The model receives a layered workbook-evidence packet—labels, structure, formulas and supported connection/model metadata—or one clearly labelled consultant text requirement. It then walks only current-state and evidence pages in selected gold. The workbook is the run unit, the sheet is the review slice, and each finding is the final-decision unit.

No spreadsheet required

Declare a requirement in ordinary text

The text becomes consultant-authority evidence and a one-sheet virtual workbook. It then follows the same LLM comparison, review, queue and scope path as an XLSX without claiming that a physical spreadsheet existed.

Source input

Physical XLSX or consultant text

XLSX.evidence

Labels + logic + metadata

Current gold

Discovered BI landscape

Model walk

codex · medium

Saved result

Receipts before evaluation

Consultant-supplied gold evidence

Synthetic journal control attributes

consultant · Synthetic Consultant · 2026-07-30T12:39:29.939Z

ev_sha256_388c689a963f313c709060d18bf37954425b7060a7ac0a5d541be0c51c738a78

TargetArchitecture_Match.xlsx

complete

blind_compare_e5fde20f0b2901928289388bde640026

8 sheets · 217 literal text cells · 9681 characters · xlsx-evidence-v2

Extraction review

Model: codex
Current gold: wiki_7c268dbf7f8b78844080cae53f6f0a0e
Started: 2026-07-31T02:13:59.384Z
Finished: 2026-07-31T02:15:18.186Z

Requirements/concepts

Direct

Partial

Possible

Not Found

Ambiguous

Model assessment

The workbook declares the `Target Fields` register as authoritative and requires 14 semantic-model objects: 10 columns across Account, Calendar and Ledger, plus four measures in Metrics. All 14 qualified objects were observed in the available current-gold semantic model with the requested object kind and compatible data type. This is therefore a full current-state coverage pass (14/14 direct) with minimal validation effort, not an implementation-gap assessment. Validation remains appropriate for measure DAX/business semantics, AccountType domain wording, and the current summarisation setting on Calendar.FiscalMonth.

Coverage method

Primary denominator: 14 rows in the authoritative `Target Fields` table (`Read Me!B8`; `Target Fields!A2:J15`). Coverage is 14 direct, 0 partial, 0 possible, 0 ambiguous and 0 not found. Each requested qualified object exists in current gold with the same table/entity and name, the same object kind, and a compatible declared data type. The prototype sheets and formulas were treated as corroborating context only because the workbook explicitly says the register is authoritative and the working sheets merely illustrate grain and intended behaviour.

Model-authored Markdown report

# Workbook-to-current-gold assessment

## Conclusion

The workbook appears to specify the core data dictionary for a finance reporting semantic model. It explicitly identifies **Target Fields** as the authoritative register of requested data objects (`Read Me!B8`). That register contains 14 required objects (`Target Fields!A2:J15`):

- 3 Account columns
- 3 Calendar columns
- 4 Ledger columns
- 4 Metrics measures

All 14 are present in the discovered current semantic model with matching qualified names, compatible object kinds and compatible data types. The result is a **full current-state coverage pass: 14/14 direct** against current-gold page `fde-finance.current-model`.

This means the declared target structure appears already represented in the audited model. Remaining questions are validation matters rather than identified implementation gaps.

## Authoritative scope and interpretation

The workbook states that `Target Fields` is the authoritative register and that the other working sheets contain synthetic records and formulas illustrating grain and intended report behaviour (`Read Me!B8`). It also states that sample values are fictional and not intended for reconciliation or production reporting (`Read Me!B10`). Accordingly:

- `Target Fields!A2:J15` is the comparison denominator.
- Chart of Accounts, Fiscal Calendar, Ledger Sample and Management P&L are corroborating design context, not additional authoritative requirements.
- Formula text demonstrates stored prototype logic but does not prove successful recalculation, current cached results or equivalence to production DAX.

No consultant comments were supplied, so consultant guidance did not materially alter the workbook interpretation.

## Coverage summary

| Status | Count | Meaning |
|---|---:|---|
| Direct | 14 | Qualified object exists with compatible kind and data type |
| Partial | 0 | No declared requirement appears to need an additional object or material model adaptation |
| Possible | 0 | No name-only or weak inferred mappings were required |
| Ambiguous | 0 | No authoritative object identity was unresolved |
| Not found | 0 | Every authoritative object was found within the available gold boundary |

## Mapped requirements

### Account

The workbook requires `Account.AccountKey` as Int64, `Account.AccountName` as String and `Account.AccountType` as String (`Target Fields!A2:J4`). Current gold directly observes all three columns with those data types in `fde-finance.current-model`.

### Calendar

The workbook requires `Calendar.DateKey` as Int64, `Calendar.Date` as DateTime and `Calendar.FiscalMonth` as Int64 (`Target Fields!A5:J7`). Current gold directly observes all three with compatible types in `fde-finance.current-model`.

The fiscal-calendar prototype says the fiscal year starts in July and stores formulas calculating July as fiscal month 1 (`Fiscal Calendar!A2`, `Fiscal Calendar!C4:C34`). This supports intended semantics but is not proof of current-model calculation logic. Current gold also flags that `Calendar.FiscalMonth` currently summarises by Sum, which should be reviewed for a month-number attribute.

### Ledger

The workbook requires `Ledger.DateKey` as Int64, `Ledger.AccountKey` as Int64, `Ledger.SignedAmount` as Decimal and `Ledger.IsAdjustment` as Boolean (`Target Fields!A8:J11`). Current gold directly observes all four with those types in `fde-finance.current-model`.

Current gold additionally observes active many-to-one relationships from `Ledger.DateKey` to `Calendar.DateKey` and from `Ledger.AccountKey` to `Account.AccountKey`, consistent with the foreign-key descriptions in the register. Those relationships corroborate the requested ledger-star structure but are not separate authoritative register rows.

### Metrics measures

The workbook requires Decimal measures `Metrics.Actual Net`, `Metrics.Actual Revenue`, `Metrics.Budget Net` and `Metrics.Net Variance` (`Target Fields!A12:J15`). Current gold directly observes all four qualified measures in `fde-finance.current-model`.

The register describes Actual Net as actual revenue plus signed expense balances and Net Variance as Actual Net minus Budget Net (`Target Fields!H12`, `Target Fields!H15`). The prototype similarly stores formulas for actual net, budget net and net variance (`Management P&L!B6`, `Management P&L!B9:B10`). However, current gold did not return exact DAX expressions, so formula equivalence and production semantics remain to be validated. Under the comparison rules, this does not downgrade structurally present measures from direct coverage.

## Contextual observations

- The workbook describes posting-level ledger data using a reporting-sign convention (`Ledger Sample!A1:A2`) and a management P&L prototype using positive revenue, negative expense and favourable-positive variance conventions (`Management P&L!A3:D10`). These are useful semantic validation cues, not additional authoritative target objects.
- The authoritative definition of `Account.AccountType` says “Revenue or expense classification” (`Target Fields!E4`), while the representative account sheet also lists Asset, Liability and Equity classifications (`Chart of Accounts!B4:C13`). The column itself is directly present, but the intended permitted-value domain and definition should be reconciled.
- The hidden reference sheet indicates AUD reporting currency and a July fiscal-year start (`Reference Data!A2:C3`). These are contextual parameters; the authoritative register does not declare them as model objects.

## Current-gold boundary

The comparison uses only the available current-state gold knowledge. A direct result means the object was observed in that bounded audit. Conversely, a not-found result would mean only that an object was not found within that boundary, not that it is absent enterprise-wide. In this case, no authoritative requirement was not found.

Workbook finding	Status	Evidence links	Reasoning
Account.AccountKey column (Int64) TF-01	direct 99% confidence	Target Fields!A2:J2 fde-finance.current-model	Current gold observes the qualified column `Account.AccountKey` as Int64, matching the requested column kind and data type.
Account.AccountName column (String) TF-02	direct 99% confidence	Target Fields!A3:J3 fde-finance.current-model	Current gold observes the qualified column `Account.AccountName` as String, matching the requested column kind and data type.
Account.AccountType column (String) TF-03	direct 98% confidence	Target Fields!A4:J4 Chart of Accounts!B4:C13 fde-finance.current-model	Current gold observes the qualified column `Account.AccountType` as String. The object is directly covered, although the authoritative wording limits the definition to revenue/expense while representative rows also show Asset, Liability and Equity values. Should the AccountType business definition and permitted domain explicitly include Asset, Liability and Equity as shown by the representative chart of accounts?
Calendar.DateKey column (Int64) TF-04 confirmed match	direct 99% confidence	Target Fields!A5:J5 fde-finance.current-model	Current gold observes the qualified column `Calendar.DateKey` as Int64, matching the requested column kind and data type. Confirm that current DateKey values follow the requested YYYYMMDD encoding; current gold establishes the object and type but not value-level conformance.
Calendar.Date column (DateTime) TF-05	direct 99% confidence	Target Fields!A6:J6 fde-finance.current-model	Current gold observes the qualified column `Calendar.Date` as DateTime, matching the requested column kind and data type.
Calendar.FiscalMonth column (Int64) TF-06	direct 98% confidence	Target Fields!A7:J7 Fiscal Calendar!A2 Fiscal Calendar!C4:C34 fde-finance.current-model	Current gold observes the qualified column `Calendar.FiscalMonth` as Int64. The July-start prototype supports intended semantics. Current gold reports that the column summarises by Sum, which is a configuration review item rather than an absent-object gap. Should `Calendar.FiscalMonth` be changed from Summarise by Sum to Summarise by None? Confirm that the current model uses July as fiscal month 1, as illustrated by the workbook formulas.
Ledger.DateKey column (Int64) TF-07	direct 99% confidence	Target Fields!A8:J8 fde-finance.current-model	Current gold observes `Ledger.DateKey` as Int64 and an active many-to-one relationship to `Calendar.DateKey`, consistent with the requested posting-date foreign key.
Ledger.AccountKey column (Int64) TF-08	direct 99% confidence	Target Fields!A9:J9 fde-finance.current-model	Current gold observes `Ledger.AccountKey` as Int64 and an active many-to-one relationship to `Account.AccountKey`, consistent with the requested account foreign key.
Ledger.SignedAmount column (Decimal) TF-09	direct 98% confidence	Target Fields!A10:J10 Ledger Sample!A2:D3 Management P&L!C4:D10 fde-finance.current-model	Current gold observes the qualified column `Ledger.SignedAmount` as Decimal. The prototype provides reporting-sign context, but value-level currency and sign conformance were not established by the bounded evidence. Confirm that the current column is consistently expressed in the required reporting currency and reporting-sign convention.
Ledger.IsAdjustment column (Boolean) TF-10	direct 99% confidence	Target Fields!A11:J11 fde-finance.current-model	Current gold observes the qualified column `Ledger.IsAdjustment` as Boolean, matching the requested column kind and data type. Confirm the operational rule used to classify late or manual postings as adjustments; the object and type are observed but value-level business logic is not.
Metrics.Actual Net measure (Decimal) TF-11	direct 96% confidence	Target Fields!A12:J12 Management P&L!A4:D6 Management P&L!B6 fde-finance.current-model	Current gold observes the qualified measure `Metrics.Actual Net` with currency formatting, satisfying the declared measure object. Exact DAX was not returned, so equivalence to the stated revenue-plus-signed-expenses logic remains a validation question. Does the production DAX implement Actual Revenue plus signed expense balances with the intended account classification and filter context?
Metrics.Actual Revenue measure (Decimal) TF-12	direct 96% confidence	Target Fields!A13:J13 Management P&L!A4:D4 Management P&L!B4 fde-finance.current-model	Current gold observes the qualified measure `Metrics.Actual Revenue` with currency formatting. The workbook prototype illustrates revenue selection, but exact production DAX and business semantics were not available in current gold. What production account-classification rule should Actual Revenue use, and does the current DAX implement it?
Metrics.Budget Net measure (Decimal) TF-13	direct 95% confidence	Target Fields!A14:J14 Management P&L!A7:D9 Management P&L!B9 fde-finance.current-model	Current gold observes the qualified measure `Metrics.Budget Net` with currency formatting. The workbook does not declare authoritative budget fact objects or a detailed budget calculation, and current gold did not expose the exact measure DAX. What is the production budget source and grain, and does the current Budget Net DAX implement the intended budget revenue-plus-expenses logic?
Metrics.Net Variance measure (Decimal) TF-14	direct 96% confidence	Target Fields!A15:J15 Management P&L!A10:D10 Management P&L!B10 fde-finance.current-model	Current gold observes the qualified measure `Metrics.Net Variance` with currency formatting. The declared logic is Actual Net minus Budget Net, but exact DAX was not returned for equivalence checking. Confirm that current DAX is `Actual Net - Budget Net` and that favourable-positive sign behaviour is preserved across report contexts.

Physical XLSX XLSX.evidence packet Model transcript Structured result

TargetArchitecture_CompleteMiss.xlsx

complete

blind_compare_37e381a7ee80632c3fc67bc9b6b4d9c8

7 sheets · 197 literal text cells · 7833 characters · xlsx-evidence-v2

Extraction review

Latest scope: blocked · 0 scoped · 8 unresolved · download Markdown

Model: codex
Current gold: wiki_7c268dbf7f8b78844080cae53f6f0a0e
Started: 2026-07-30T13:21:55.969Z
Finished: 2026-07-30T13:23:49.465Z

Requirements/concepts

Direct

Partial

Possible

Not Found

Ambiguous

Model assessment

The workbook is a discovery/design pack for a new customer and sales-order analytics subject area. Its explicitly authoritative `Target Fields` register declares eight required objects: six columns across Customer and SalesOrder plus two SalesMetrics measures. None of those eight objects was observed in the available current-gold Power BI landscape. The discovered current model is instead a finance-ledger model containing Account, Calendar, Ledger and Metrics, with four finance measures; generic similarities such as a Metrics table or a decimal amount column do not establish customer/order semantic matches. Authoritative coverage is therefore 0 of 8 direct, partial or possible mappings, and 8 of 8 not found within the bounded current-gold evidence.

Coverage method

The workbook explicitly states that `Target Fields` is the authoritative register and that the other sheets are synthetic illustrations (`Read Me`!B8). Accordingly, the primary denominator is the eight register rows `Target Fields`!A2:J9, all marked required. Result: 0 direct, 0 partial, 0 possible, 0 ambiguous and 8 not_found. The sample, reference and KPI sheets were used only to clarify intended grain, domains and calculation behaviour; they were not counted as additional authoritative objects. `not_found` means absent from the available discovered current-gold boundary, not proven absent elsewhere in the client estate.

Model-authored Markdown report

# Workbook-to-current-gold assessment

## Executive conclusion

This workbook appears to specify a **new customer and booked-sales-order analytics subject area** for FY2026–FY2027. It requires customer identity, segmentation and relationship ownership; sales-order identity, gross value and acquisition channel; and two commercial measures: Customer Lifetime Value and Gross Order Intake.

The workbook explicitly designates `Target Fields` as its authoritative register (`Read Me`!B8). That register contains eight rows and marks every row required (`Target Fields`!F2:F9). None of the eight declared objects was found in the available current-gold model.

The current-gold landscape instead describes a small finance ledger model with `Account`, `Calendar`, `Ledger` and `Metrics` as its business-facing tables. Its observed measures are `Actual Net`, `Actual Revenue`, `Budget Net` and `Net Variance`; its observed amount is `Ledger.SignedAmount`. There are no observed Customer, SalesOrder or SalesMetrics objects [fde-finance.current-model]. The separate journal-controls page concerns two finance-ledger attributes and does not supply customer/order coverage [fde-finance.journal-controls].

**Authoritative coverage:** **0/8 mapped**; **8/8 not found** in the available discovered landscape.

## Interpreted business and data requirements

The authoritative register implies two principal business entities and a calculation layer:

- **Customer**, at customer-level grain, with enterprise identity, commercial segment and accountable relationship owner (`Target Fields`!A2:I4; corroborated by `Customer Sample`!A1:C3).
- **SalesOrder**, at representative booked-order grain, with order identity, gross value before discounts and sales channel (`Target Fields`!A5:I7; corroborated by `Sales Orders`!A1:D3).
- **SalesMetrics**, containing Customer Lifetime Value and Gross Order Intake (`Target Fields`!A8:I9; corroborated by `Sales KPI Prototype`!A3:C5 and formulas B4:B5).

The sample order sheet also contains `CustomerIdentifier` on each order (`Sales Orders`!B3:B15), implying a customer-to-order linkage. However, that order-side field is not declared as its own row in the authoritative register, so it is treated as design context rather than a ninth authoritative requirement.

The hidden reference sheet supplies candidate controlled domains for CustomerSegment and SalesChannel (`Reference Data`!A2:C7). These are design semantics, not proof of implemented validation or a production reference-data solution.

## Authoritative mapping results

| ID | Required object | Workbook evidence | Result | Current-gold assessment |
|---|---|---|---|---|
| TF-01 | `Customer.CustomerIdentifier` | `Target Fields`!A2:J2 | Not found | No Customer table or customer identifier was observed [fde-finance.current-model]. |
| TF-02 | `Customer.CustomerSegment` | `Target Fields`!A3:J3 | Not found | No Customer table or commercial-segment attribute was observed [fde-finance.current-model]. |
| TF-03 | `Customer.RelationshipOwner` | `Target Fields`!A4:J4 | Not found | No Customer table or relationship-owner attribute was observed [fde-finance.current-model]. |
| TF-04 | `SalesOrder.OrderIdentifier` | `Target Fields`!A5:J5 | Not found | No SalesOrder table or order identifier was observed [fde-finance.current-model]. |
| TF-05 | `SalesOrder.OrderGrossValue` | `Target Fields`!A6:J6 | Not found | `Ledger.SignedAmount` is a finance-ledger amount, not evidence of gross order value before discounts; no SalesOrder amount was observed [fde-finance.current-model]. |
| TF-06 | `SalesOrder.SalesChannel` | `Target Fields`!A7:J7 | Not found | No SalesOrder table or acquisition-channel attribute was observed [fde-finance.current-model]. |
| TF-07 | `SalesMetrics.Customer Lifetime Value` | `Target Fields`!A8:J8 | Not found | The current `Metrics` table contains only four named finance measures. A generic measure table does not establish this commercial measure [fde-finance.current-model]. |
| TF-08 | `SalesMetrics.Gross Order Intake` | `Target Fields`!A9:J9 | Not found | No measure with this name or booked-order semantics was observed. `Actual Revenue` and other finance measures cannot be treated as equivalents because their exact DAX and business semantics are unknown [fde-finance.current-model]. |

## Calculation interpretation

- **Gross Order Intake** is declared as the sum of `OrderGrossValue` (`Target Fields`!H9), and the prototype stores `=SUM('Sales Orders'!C4:C15)` (`Sales KPI Prototype`!B4). This is evidence of intended stored logic, not proof of successful recalculation, current cached results or production-ready semantics.
- **Customer Lifetime Value** is described as average gross order value multiplied by expected order frequency (`Target Fields`!H8). The prototype stores `=B4/COUNTA('Customer Sample'!A4:A11)*3.2` (`Sales KPI Prototype`!B5). The multiplier 3.2 is explicitly illustrative for discovery (`Sales KPI Prototype`!C5), so the production frequency basis, time horizon, cohorts and treatment of discounts, cancellations and returns remain undefined.

## Contextual design observations

1. **Customer-order relationship:** The order sample places `CustomerIdentifier` on orders (`Sales Orders`!B3:B15), but the authoritative register does not request `SalesOrder.CustomerIdentifier` or explicitly declare a relationship. A production semantic model will require a documented customer/order key and cardinality.
2. **Controlled values:** The workbook proposes CustomerSegment values Enterprise, Mid-market and Small business, and SalesChannel values Direct, Partner and Online (`Reference Data`!A2:C7). No workbook data-validation rule was found, so these are reference examples rather than enforced constraints.
3. **Planned sources:** Customer fields point to a CRM customer master, order fields to an order-management platform, and measures to a sales analytics calculation layer (`Target Fields`!I2:I9). The workbook contains no connections, queries or external links, so source accessibility and integration status are not evidenced.
4. **Current-model mismatch:** The available gold model is finance-ledger oriented, while this workbook requests customer/order analytics [fde-finance.current-model]. This may represent a genuine greenfield gap, a different subject-area model, or selection of a current model that was not intended to satisfy this request.

## Consultant guidance

The supplied consultant-guidance object contained no workbook-level or sheet-level comments. Consequently, no steering note changed the interpretation; the workbook's own explicit authority statement determined the denominator.

## Recommended decisions and next steps

1. Confirm whether the audited finance model is actually the intended destination for this customer/order subject area, or whether another semantic model/workspace should be discovered.
2. Add or explicitly reject `SalesOrder.CustomerIdentifier` in the authoritative register and document the customer-to-order relationship, key uniqueness and handling of unmatched customers.
3. Define production semantics for Gross Order Intake: booked-status event, booking date, cancellations, returns, discounts, tax, currency conversion and late changes.
4. Define production semantics for Customer Lifetime Value: forecast horizon, order-frequency method, customer cohort, margin versus gross value, churn assumptions and refresh cadence.
5. Confirm source contracts and ownership for the CRM customer master, order-management platform and calculation layer.
6. Re-run discovery against the intended sales/customer model or source estate before concluding that the objects are enterprise-wide gaps.

Workbook finding	Status	Evidence links	Reasoning
Customer.CustomerIdentifier column TF-01	not_found 99% confidence	Target Fields!A2:J2 fde-finance.current-model	The authoritative register requires a String customer identity sourced from the CRM customer master. The current-gold model has no Customer table or customer identifier. AccountKey is an accounting key and is not evidence of enterprise customer identity. What is the governed customer key, and is it stable and unique across all CRM records? Must source-system identifiers be retained alongside an enterprise customer identifier?
Customer.CustomerSegment column TF-02	not_found 99% confidence	Target Fields!A3:J3 Reference Data!A2:C4 fde-finance.current-model	The required commercial segment and its illustrative ENT/MID/SMB domain are not present in the observed finance-ledger model. AccountType is not a supported equivalent because it describes accounting accounts rather than customers. Are Enterprise, Mid-market and Small business the complete governed segment domain? Is segmentation current-state only, or must historical segment changes be analysed?
Customer.RelationshipOwner column TF-03	not_found 99% confidence	Target Fields!A4:J4 fde-finance.current-model	No customer entity or accountable relationship-owner attribute was observed in current gold. Should the model retain owner identifiers as well as display names? How should reassignment history, vacancies and shared ownership be represented?
SalesOrder.OrderIdentifier column TF-04	not_found 99% confidence	Target Fields!A5:J5 fde-finance.current-model	No SalesOrder table or customer-order identifier was observed in the current model. Ledger keys and finance entries do not establish order identity. What defines a unique order across order-management systems or legal entities? Are revisions, split orders and cancelled orders represented by the same identifier or separate records?
SalesOrder.OrderGrossValue column TF-05	not_found 99% confidence	Target Fields!A6:J6 Sales Orders!A1:D3 fde-finance.current-model	The workbook requires gross order value before discounts at order grain. Current gold contains Ledger.SignedAmount at finance-ledger grain, which is not a semantic or structural match to gross booked order value. Does gross value include tax, freight or other charges? Which currency fields and conversion rules are required? How are cancellations, returns and subsequent order amendments reflected?
SalesOrder.SalesChannel column TF-06	not_found 99% confidence	Target Fields!A7:J7 Reference Data!A5:C7 fde-finance.current-model	No sales-order acquisition-channel attribute was observed. The workbook's Direct, Partner and Online values are illustrative reference data, not a current-gold implementation. Are Direct, Partner and Online exhaustive governed channels? Can an order have multiple contributing channels, and if so what attribution rule applies?
SalesMetrics.Customer Lifetime Value measure TF-07	not_found 99% confidence	Target Fields!A8:J8 Sales KPI Prototype!A5:C5 Sales KPI Prototype!B5 fde-finance.current-model	No Customer Lifetime Value measure or supporting customer/order structure was observed. The current model's four finance measures are differently named and have unknown exact DAX. The workbook prototype's 3.2 frequency multiplier is illustrative and does not establish a production definition. What forecast horizon and expected-order-frequency method should production CLV use? Should CLV use gross order value, net revenue, gross margin or contribution margin? How should churn, returns, discounts and customer tenure affect the calculation?
SalesMetrics.Gross Order Intake measure TF-08	not_found 99% confidence	Target Fields!A9:J9 Sales KPI Prototype!A4:C4 Sales KPI Prototype!B4 fde-finance.current-model	The required sum of OrderGrossValue and its prototype formula have no observed counterpart in current gold. Actual Revenue cannot be assumed equivalent to gross booked order value, particularly because exact DAX and production semantics for current measures were not returned. What event makes an order count as booked intake, and which date drives reporting? Should cancelled or amended orders restate prior periods? Are intake values reported before discounts, tax and currency conversion in all views?

Physical XLSX XLSX.evidence packet Model transcript Structured result

TargetArchitecture_Partial.xlsx

complete

blind_compare_59f1a566bfa719941495e65ed65c05fd

8 sheets · 249 literal text cells · 10109 characters · xlsx-evidence-v2

Extraction review

Model: codex
Current gold: wiki_7c268dbf7f8b78844080cae53f6f0a0e
Started: 2026-07-30T13:17:21.366Z
Finished: 2026-07-30T13:19:23.086Z

Requirements/concepts

Direct

Partial

Possible

Not Found

Ambiguous

Model assessment

The workbook explicitly makes the 13 rows in the Target Fields register the authoritative denominator. Of those 13 required data objects, 10 map directly to the observed current semantic model and 3 management-enrichment columns are not found in the available current-gold landscape. This gives direct structural coverage of 10/13 (76.9%). The unmapped objects are Ledger.CostCentre, Ledger.CurrencyCode and Account.AccountGroup. The separate Management P&L prototype is contextual rather than authoritative: four of its named metrics are observed as measures, while three are not separately observed, and exact DAX was unavailable. No substantive consultant steering comments were supplied.

Coverage method

Coverage uses the workbook's own authority statement at Read Me!B8 and therefore counts only the 13 requested-object rows in Target Fields!A2:J14. All 13 rows say Required=Yes, corroborated by Validation!A3:C3. Ten rows have exact table/column name and compatible data-type matches in fde-finance.current-model; three declared columns have no supporting current-gold object and are classified not_found within the bounded discovered landscape. Other sheets contain fictional examples and prototype formulas, so they are treated as corroborating context and excluded from the 13-row denominator. Contextual P&L measure coverage is partial: Actual Revenue, Actual Net, Budget Net and Net Variance are observed, but Actual Expenses, Budget Revenue and Budget Expenses are not separately observed. Gold does not expose the four observed measures' exact DAX, so semantic equivalence is not established merely from matching names.

Model-authored Markdown report

# Workbook-to-current-gold assessment

## Interpretation and authority

The workbook describes a finance reporting management extension for FY2026–FY2027, focused on organisational and transaction-currency enrichment (`Read Me!B3:B6`). It explicitly states that **Target Fields is the authoritative register of requested data objects**, while the working sheets contain synthetic records and formulas illustrating grain and report behaviour (`Read Me!B8`). Accordingly, the primary denominator is the 13 register rows in `Target Fields!A2:J14`, not the examples on the other sheets. The validation sheet also states that all register rows are required (`Validation!A3:C3`).

No substantive consultant steering comments were supplied, so consultant guidance did not alter the workbook-led interpretation.

## Coverage result

- **Authoritative requested objects:** 13
- **Directly mapped:** 10
- **Not found in available current gold:** 3
- **Direct structural coverage:** **76.9% (10/13)**

All ten direct mappings are supported by the observed business-facing inventory in `fde-finance.current-model`. The three gaps are specifically the requested management extension fields:

1. `Ledger.CostCentre` (`Target Fields!A12:J12`)
2. `Ledger.CurrencyCode` (`Target Fields!A13:J13`)
3. `Account.AccountGroup` (`Target Fields!A14:J14`)

Their absence means only that they were not found in the bounded current-gold discovery; it is not proof that they do not exist in upstream systems or elsewhere in the estate.

## Authoritative register mapping

| ID | Requested object | Workbook evidence | Result | Current-gold evidence |
|---|---|---|---|---|
| TF-01 | Account.AccountKey | `Target Fields!A2:J2` | Direct | Exact Int64 column in `fde-finance.current-model` |
| TF-02 | Account.AccountName | `Target Fields!A3:J3` | Direct | Exact String column in `fde-finance.current-model` |
| TF-03 | Account.AccountType | `Target Fields!A4:J4` | Direct | Exact String column in `fde-finance.current-model` |
| TF-04 | Calendar.DateKey | `Target Fields!A5:J5` | Direct | Exact Int64 column in `fde-finance.current-model` |
| TF-05 | Calendar.Date | `Target Fields!A6:J6` | Direct | Exact DateTime column in `fde-finance.current-model` |
| TF-06 | Calendar.FiscalMonth | `Target Fields!A7:J7` | Direct | Exact Int64 column in `fde-finance.current-model`; current summarisation setting needs review |
| TF-07 | Ledger.DateKey | `Target Fields!A8:J8` | Direct | Exact Int64 column and observed relationship to Calendar.DateKey in `fde-finance.current-model` |
| TF-08 | Ledger.AccountKey | `Target Fields!A9:J9` | Direct | Exact Int64 column and observed relationship to Account.AccountKey in `fde-finance.current-model` |
| TF-09 | Ledger.SignedAmount | `Target Fields!A10:J10` | Direct | Exact Decimal column in `fde-finance.current-model` |
| TF-10 | Ledger.IsAdjustment | `Target Fields!A11:J11` | Direct | Exact Boolean column in `fde-finance.current-model` |
| TF-11 | Ledger.CostCentre | `Target Fields!A12:J12` | Not found | No supporting column in available current gold; audited Ledger has only four business-facing columns in `fde-finance.current-model` |
| TF-12 | Ledger.CurrencyCode | `Target Fields!A13:J13` | Not found | No supporting column in available current gold; audited Ledger has only four business-facing columns in `fde-finance.current-model` |
| TF-13 | Account.AccountGroup | `Target Fields!A14:J14` | Not found | No supporting column in available current gold; audited Account has only three columns in `fde-finance.current-model` |

## Context from the working sheets

The examples corroborate intended grain and usage but are not additional authoritative register rows:

- The account example is one row per finance account and includes AccountGroup (`Chart of Accounts!A2:D13`).
- The fiscal calendar is daily grain with a July fiscal-year start (`Fiscal Calendar!A2:C3`), and stored formulas calculate FiscalMonth as `MOD(MONTH(Date)-7,12)+1` (`Fiscal Calendar!C4:C34`). This is evidence of intended workbook logic, not proof of successful/current recalculation.
- The ledger example is posting-level and includes CostCentre and CurrencyCode (`Ledger Sample!A2:F15`).
- The management P&L prototype names Actual Revenue, Actual Expenses, Actual Net, Budget Revenue, Budget Expenses, Budget Net and Net Variance (`Management P&L!A4:D10`). Current gold observes exact-name measures for Actual Revenue, Actual Net, Budget Net and Net Variance, but not separate measures for Actual Expenses, Budget Revenue or Budget Expenses (`fde-finance.current-model`). The observed measures' DAX was not returned, so name matches do not establish formula equivalence with workbook formulas such as `Management P&L!B4:B6,B9:B10`.

## Important semantic observations

- `Account.AccountType` is defined in the register as “Revenue or expense classification” (`Target Fields!E4`), but the fictional chart-of-accounts examples also use Asset, Liability and Equity (`Chart of Accounts!C4:C13`). The object maps structurally, but the intended domain/definition should be clarified.
- The target describes FiscalMonth as a month number (`Target Fields!E7`), while current gold reports `Calendar.FiscalMonth` summarised by Sum (`fde-finance.current-model`). This does not block the direct object match, but the model setting should be reviewed.
- Current gold confirms active many-to-one relationships from Ledger to Calendar and Account, supporting the intended foreign-key structure for `Ledger.DateKey` and `Ledger.AccountKey` (`fde-finance.current-model`).

## Overall conclusion

The current model already contains the core Account, Calendar and Ledger key/amount/adjustment structure requested by the workbook. The material current-state gap is the management enrichment layer: cost-centre accountability, transaction-currency analysis and account-group roll-up are all explicitly required by the authoritative register but not found in available current gold. Contextual P&L measure coverage is incomplete or semantically unverified because only four named measures were observed and their DAX definitions were unavailable.

Workbook finding	Status	Evidence links	Reasoning
Management P&L metric prototype CTX-01	context_only 88% confidence	Management P&L!A1:D10 Management P&L!B4:B6 Management P&L!B9:B10 fde-finance.current-model	This sheet is explicitly a formula-driven illustration rather than part of the authoritative Target Fields register. Current gold observes exact-name measures for Actual Revenue, Actual Net, Budget Net and Net Variance, but not separate measures for Actual Expenses, Budget Revenue or Budget Expenses. Exact DAX for observed measures was unavailable, so semantic equivalence cannot be confirmed. Are Actual Expenses, Budget Revenue and Budget Expenses required as production measures even though they are absent from the authoritative register? What are the approved DAX definitions and source for budget values? Should revenue/expense classification use account-number ranges as in the prototype formulas, or governed AccountType/AccountGroup mappings?
Account.AccountKey column TF-01	direct 99% confidence	Target Fields!A2:J2 fde-finance.current-model	The authoritative register requires an Int64 Account.AccountKey stable identifier. Current gold observes the exact table, column name and data type.
Account.AccountName column TF-02	direct 99% confidence	Target Fields!A3:J3 fde-finance.current-model	The authoritative register requires a String Account.AccountName. Current gold observes the exact table, column name and data type.
Account.AccountType column TF-03	direct 98% confidence	Target Fields!A4:J4 Chart of Accounts!C3:C13 fde-finance.current-model	Current gold observes the exact String Account.AccountType column. Structural coverage is direct, although the register definition mentions revenue/expense while the fictional examples also include asset, liability and equity values. Should AccountType cover the full balance-sheet and P&L domain (Asset, Liability, Equity, Revenue, Expense), rather than only the register's stated revenue-or-expense classification?
Calendar.DateKey column TF-04	direct 97% confidence	Target Fields!A5:J5 fde-finance.current-model	The authoritative register requires an Int64 Calendar.DateKey in YYYYMMDD form. Current gold observes the exact table, column name and data type; actual value encoding was not available for verification. Should the YYYYMMDD encoding and uniqueness of Calendar.DateKey be tested against source/model data during implementation validation?
Calendar.Date column TF-05	direct 99% confidence	Target Fields!A6:J6 fde-finance.current-model	The authoritative register requires a DateTime Calendar.Date. Current gold observes the exact table, column name and data type.
Calendar.FiscalMonth column TF-06	direct 95% confidence	Target Fields!A7:J7 Fiscal Calendar!A2:C3 Fiscal Calendar!C4:C34 fde-finance.current-model	Current gold observes the exact Int64 Calendar.FiscalMonth column. Workbook context indicates a July fiscal-year start and supplies a formula for month numbering. Gold does not establish that the current model uses that exact derivation and notes that the column is summarised by Sum. Does the current Calendar.FiscalMonth use the required July-start numbering shown by the workbook formula? Should Calendar.FiscalMonth be changed from Summarise by Sum to Summarise by None?
Ledger.DateKey column and calendar linkage TF-07	direct 99% confidence	Target Fields!A8:J8 fde-finance.current-model	The authoritative register requires an Int64 Ledger.DateKey posting-date foreign key. Current gold observes the exact column and an active many-to-one Ledger.DateKey to Calendar.DateKey relationship.
Ledger.AccountKey column and account linkage TF-08	direct 99% confidence	Target Fields!A9:J9 fde-finance.current-model	The authoritative register requires an Int64 Ledger.AccountKey account foreign key. Current gold observes the exact column and an active many-to-one Ledger.AccountKey to Account.AccountKey relationship.
Ledger.SignedAmount column TF-09	direct 97% confidence	Target Fields!A10:J10 Ledger Sample!A2:C3 fde-finance.current-model	The authoritative register requires a Decimal Ledger.SignedAmount in reporting-sign convention. Current gold observes the exact Decimal column. The audit confirms structure and formatting, but not source currency conversion logic or detailed sign semantics. Is SignedAmount already converted into a single reporting currency, and what conversion-rate/date rules are intended when CurrencyCode is added? Is the workbook's positive-revenue/negative-expense sign convention the required production convention?
Ledger.IsAdjustment column TF-10	direct 99% confidence	Target Fields!A11:J11 fde-finance.current-model	The authoritative register requires a Boolean Ledger.IsAdjustment. Current gold observes the exact table, column name and data type. What business rule distinguishes late or manual adjustments, and is the current field populated consistently with that rule?
Ledger.CostCentre column TF-11	not_found 99% confidence	Target Fields!A12:J12 Ledger Sample!E3:E15 Reference Data!A1:A4 fde-finance.current-model	The authoritative register requires Ledger.CostCentre for operating-area accountability, and working sheets illustrate cost-centre codes. The audited Ledger inventory contains only DateKey, AccountKey, SignedAmount and IsAdjustment; no CostCentre object is present in available current gold. Is CostCentre available in the finance posting source at the same posting grain as Ledger? Is a separate Cost Centre dimension required, or is a code column on Ledger sufficient? Who owns the authoritative cost-centre hierarchy and effective-dating rules?
Ledger.CurrencyCode column TF-12	not_found 99% confidence	Target Fields!A13:J13 Ledger Sample!F3:F15 Reference Data!C1:C4 fde-finance.current-model	The authoritative register requires an ISO transaction CurrencyCode for transaction-currency analysis, and working sheets illustrate AUD/NZD codes. No CurrencyCode object is present in the audited Ledger inventory in available current gold. Is transaction currency available on every posting in the finance source? Are transaction amount, reporting amount and exchange-rate fields also needed to make transaction-currency analysis meaningful? Should CurrencyCode link to a governed currency dimension?
Account.AccountGroup column TF-13	not_found 99% confidence	Target Fields!A14:J14 Chart of Accounts!D3:D13 Reference Data!B1:B4 fde-finance.current-model	The authoritative register requires an Account.AccountGroup management roll-up. The audited Account inventory contains AccountKey, AccountName and AccountType only; no AccountGroup object is present in available current gold. What is the authoritative source and owner for AccountGroup mappings? Can an account belong to more than one management group, and are mappings effective-dated? The reference examples differ in grouping vocabulary from some chart-of-accounts examples; what controlled hierarchy is intended?

Physical XLSX XLSX.evidence packet Model transcript Structured result

Month-end close adjustment controls

consultant requirement complete

blind_compare_3b7e886b9150f8be988bfa3587672c05

1 sheet · 6 literal text cells · 1045 characters · xlsx-text-v1

Extraction review

Model: codex
Current gold: wiki_7c268dbf7f8b78844080cae53f6f0a0e
Started: 2026-07-30T12:49:57.537Z
Finished: 2026-07-30T12:51:21.679Z

Requirements/concepts

Direct

Partial

Possible

Not Found

Ambiguous

Model assessment

The consultant-declared requirement is for a month-end finance control that surfaces unapproved manual ledger adjustments before reporting-pack sign-off, preserves entry-level detail, calculates an exception value from absolute adjustment amounts, supports drill-through, and is accepted through reconciliation and approval-governance checks. Current gold provides useful foundations: an observed Ledger table with SignedAmount and IsAdjustment, calendar relationships, and consultant evidence that JournalSource and ApprovalStatus are available upstream at ledger-entry grain. However, neither control attribute nor the requested Metrics.Unapproved Adjustment Value measure was observed in the audited model, and gold does not evidence the requested report view, drill-through, closed-month reconciliation, late-approval definition, or consultant acceptance confirmation. Overall mapping is therefore partial and design-dependent rather than implementation-complete.

Coverage method

Ten coherent requirements were identified from the consultant description in Consultant Requirement!A5. None maps directly to a completed current-state implementation. Four are partial because current gold contains relevant model or source foundations but lacks the full requested implementation; two are possible because gold supports feasibility or recommends the control but does not establish delivery; four are not found in the available discovered landscape. This assessment is bounded to the two allowed current-gold pages and must not be read as proof of absence elsewhere in the estate. The consultant_guidance contained no workbook- or sheet-specific comments, so no additional steering altered the interpretation; the declared consultant authority was respected by treating the description as a requirement rather than as observed implementation evidence.

Model-authored Markdown report

# Workbook-to-current-gold assessment

## Requirement interpretation

The virtual workbook is explicitly declared as a consultant-authored requirement. Its description requests a month-end close-control capability with four connected elements:

1. a monthly exception view before reporting-pack sign-off;
2. journal-source and approval-status attributes at ledger-entry grain;
3. an unapproved-adjustment value measure using absolute adjustment amounts and excluding approved entries; and
4. traceability and acceptance controls covering drill-through, reconciliation, late approvals, and consultant confirmation.

All requirement statements are sourced from `Consultant Requirement!A5`. The title at `Consultant Requirement!A2` corroborates the overall subject. `Consultant Requirement!A8` identifies the contributor but is not implementation evidence.

## Current-gold foundations

The observed semantic model contains `Ledger.SignedAmount`, `Ledger.IsAdjustment`, `Ledger.DateKey`, and active relationships from Ledger to Calendar and Account. It also contains a `Metrics` table, but its four observed measures do not include the requested exception measure, and exact DAX was unavailable in the bounded audit [fde-finance.current-model].

Separate consultant evidence states that the governed ledger export contains `Ledger.JournalSource` and `Ledger.ApprovalStatus` at ledger-entry grain. That page explicitly says these fields were not observed in the audited Power BI model and that their implementation scope remains unresolved [fde-finance.journal-controls].

## Mapping results

| ID | Requirement | Result | Current-gold assessment |
|---|---|---|---|
| R1 | Monthly close-control view identifying unapproved manual adjustments before sign-off | Partial | Ledger amount, adjustment flag, and calendar foundations exist, but approval status is absent from the audited model and no completed control view is evidenced [fde-finance.current-model; fde-finance.journal-controls]. |
| R2 | Expose `Ledger.JournalSource` | Partial | Upstream entry-grain availability is consultant-supported, but the field was not observed in the selected semantic model [fde-finance.journal-controls; fde-finance.current-model]. |
| R3 | Expose `Ledger.ApprovalStatus` | Partial | Upstream entry-grain availability is consultant-supported, but the field was not observed in the selected semantic model [fde-finance.journal-controls; fde-finance.current-model]. |
| R4 | Expose `Metrics.Unapproved Adjustment Value` | Not found | The requested measure is not among the four observed Metrics measures, and no supporting current-gold object with that name is present [fde-finance.current-model]. |
| R5 | Keep journal attributes at ledger-entry grain | Possible | The upstream attributes are described as entry-grain, but the audited model does not contain them and gold does not establish the ledger-entry key or implemented grain after ingestion [fde-finance.journal-controls; fde-finance.current-model]. |
| R6 | Sum absolute adjustment-entry values where approval status is not approved | Partial | `Ledger.SignedAmount` and `Ledger.IsAdjustment` exist and ApprovalStatus is reported upstream, but no DAX implementation or exact status-handling logic is evidenced [fde-finance.current-model; fde-finance.journal-controls]. |
| R7 | Drill through to the original ledger entry | Not found | Gold does not evidence a unique original-entry identifier, drill-through page, or report interaction implementing this requirement [fde-finance.current-model; fde-finance.journal-controls]. |
| R8 | Reconcile acceptance results to the governed ledger export for a closed month | Possible | Gold identifies a governed export and recommends reconciliation, but it does not evidence a closed-month reconciliation result, control design, or acceptance record [fde-finance.journal-controls]. |
| R9 | Define late approvals explicitly | Not found | Gold says late approval changes and refresh treatment require documentation; no explicit definition is recorded [fde-finance.journal-controls]. |
| R10 | Obtain consultant confirmation that approved adjustments are excluded | Not found | No requested measure implementation or consultant acceptance confirmation is present in current gold [fde-finance.current-model; fde-finance.journal-controls]. |

## Key gaps and decisions

- Confirm whether the two upstream journal-control attributes are now approved additions to the semantic model scope.
- Define the ledger-entry identifier and ensure it survives ingestion so drill-through can target the original record.
- Specify the complete approval-status domain, including blanks, pending, rejected, reversed, and statuses changing after month close.
- Decide whether absolute value is applied row by row before summation, as the requirement wording appears to indicate.
- Establish the governed export version, closed-month cut-off, refresh timing, reconciliation tolerance, and accountable sign-off owner.
- Implement and independently validate `Metrics.Unapproved Adjustment Value`; the observed current Metrics measures cannot be assumed to satisfy it.

## Guidance influence and boundary

No substantive consultant-guidance comments were supplied. Consequently, no extra workbook-level or sheet-level steering changed the requirement decomposition. The assessment is limited to available current gold: absence here means not found in the discovered boundary, not enterprise-wide nonexistence.

Workbook finding	Status	Evidence links	Reasoning
Provide a monthly close-control view identifying unapproved manual adjustments before reporting-pack sign-off R1	partial 93% confidence	Consultant Requirement!A5 fde-finance.current-model fde-finance.journal-controls	The observed model has Ledger.SignedAmount, Ledger.IsAdjustment, Calendar support, and a Metrics table. Consultant evidence supports upstream JournalSource and ApprovalStatus. However, ApprovalStatus is not in the audited model and no delivered close-control view or sign-off workflow is evidenced. Which report page or audience should own the control view? What exact event and timestamp define reporting-pack sign-off? How is a manual adjustment identified: JournalSource, IsAdjustment, or a combination?
Obtain consultant confirmation that approved adjustments are excluded from the exception value R10	not_found 98% confidence	Consultant Requirement!A5 fde-finance.current-model fde-finance.journal-controls	No Unapproved Adjustment Value implementation or consultant acceptance record is present in current gold. Although the requirement clearly states the intended exclusion, no evidence confirms that a delivered calculation enforces it. Who is authorised to provide consultant confirmation? What test cases will demonstrate exclusion of approved adjustments? Must confirmation be recorded in a test script, deployment approval, or governance register?
Expose Ledger.JournalSource R2	partial 99% confidence	Consultant Requirement!A5 fde-finance.current-model fde-finance.journal-controls	A consultant evidence page states that Ledger.JournalSource is available in the governed ledger export at entry grain, but the audited Ledger table has only DateKey, AccountKey, SignedAmount, and IsAdjustment. Thus source support exists while current-model implementation was not observed. Is JournalSource approved for addition to the target semantic model? What source values constitute manual journals? Who owns value-domain governance and mapping changes?
Expose Ledger.ApprovalStatus R3	partial 99% confidence	Consultant Requirement!A5 fde-finance.current-model fde-finance.journal-controls	A consultant evidence page states that Ledger.ApprovalStatus is available in the governed ledger export at entry grain, but it was not observed in the audited Ledger table. Source feasibility is supported; implementation in the current model is not. Is ApprovalStatus approved for addition to the semantic model? What is the authoritative status domain and case handling? Is status captured as current state or as-of close cut-off?
Expose Metrics.Unapproved Adjustment Value R4	not_found 99% confidence	Consultant Requirement!A5 fde-finance.current-model	The requested measure is not one of the four observed Metrics measures. Current gold contains no supporting object with this qualified name. This means not found within the available discovered landscape, not proof of enterprise-wide absence. Should this be a new explicit DAX measure in Metrics? What currency and formatting rules apply? Must the measure respond to all account and calendar filters?
Preserve JournalSource and ApprovalStatus at ledger-entry grain R5	possible 87% confidence	Consultant Requirement!A5 fde-finance.current-model fde-finance.journal-controls	Consultant evidence describes both upstream attributes as ledger-entry-grain fields and recommends preserving that grain. The audited model does not contain the attributes, and current gold does not establish a unique ledger-entry key or confirm the implemented Ledger table grain, so feasibility is supported but conformity is unverified. What column or composite key uniquely identifies a ledger entry? Can one ledger entry have multiple approval history rows? Will ingestion deduplicate, aggregate, or otherwise change source grain?
Calculate the exception measure as the sum of absolute adjustment-entry values where approval status is not approved R6	partial 95% confidence	Consultant Requirement!A5 fde-finance.current-model fde-finance.journal-controls	The model contains SignedAmount and IsAdjustment, while ApprovalStatus is supported upstream. No exact DAX was available and the requested measure was not observed. The component concepts partially map, but the calculation and treatment of status values remain unimplemented or unverified. Does 'sum the absolute value' mean SUMX over ABS(SignedAmount) per qualifying entry? Does 'not approved' include blank, pending, rejected, cancelled, or unknown statuses? Should reversals and duplicate adjustment entries be handled specially?
Retain drill-through to the original ledger entry R7	not_found 95% confidence	Consultant Requirement!A5 fde-finance.current-model fde-finance.journal-controls	Current gold does not identify a ledger-entry key, original-entry URL/reference, drill-through report page, or interaction. Existing Ledger columns are insufficient to establish traceability to an individual original entry. What is the authoritative ledger-entry identifier? Should drill-through remain inside Power BI or deep-link to the finance system? Which entry attributes may be displayed, considering access and sensitivity?
Reconcile acceptance to the governed ledger export for a closed month R8	possible 91% confidence	Consultant Requirement!A5 fde-finance.journal-controls	The evidence page supports the existence of a governed finance ledger export and recommends reconciliation, but no completed closed-month reconciliation, tolerance, results, or acceptance sign-off is recorded. The control is plausible but not established. Which export, version, and owner are authoritative? Which closed month will be used for acceptance? Must reconciliation cover row counts, qualifying entry IDs, values, or all three? What tolerance and sign-off evidence are required?
Create an explicit definition of late approvals R9	not_found 98% confidence	Consultant Requirement!A5 fde-finance.journal-controls	Current gold notes that late approval changes and refresh behaviour need documentation, but it provides no explicit definition of late approval. The required definition is therefore not found in the available discovered landscape. Is an approval late when it occurs after month end, close lock, export extraction, refresh, or pack sign-off? Should late approvals restate the closed-month result or remain visible as subsequent changes? Which timestamp and time zone are authoritative?

Consultant requirement evidence XLSX.evidence packet Model transcript Structured result

Earlier comparison receipts14 superseded, failed or experimental runs+

Workbook	State	Run	Started	Receipts
TargetArchitecture_Match.xlsx	failed	blind_compare_0b702c2f36cc32d82403eea441345713	2026-07-31T02:13:31.868Z
TargetArchitecture_Match.xlsx	complete	blind_compare_8a88cf368aed0cddd5f5259b259d1601	2026-07-30T13:19:31.073Z	transcript result
TargetArchitecture_Partial.xlsx	complete	blind_compare_ebb7818238b874dbe6ddbbd1cedaab86	2026-07-30T12:48:08.687Z	transcript result
TargetArchitecture_CompleteMiss.xlsx	complete	blind_compare_7f89535f0737b6b1d00f1ef95175b36b	2026-07-29T18:28:09.971Z	transcript result
TargetArchitecture_Partial.xlsx	complete	blind_compare_2aaebff529a5fac91b6a9fab0db317fb	2026-07-29T18:26:40.945Z	transcript result
TargetArchitecture_Match.xlsx	complete	blind_compare_08993d33284bd52fe4083429c3e9e96e	2026-07-29T18:25:20.422Z	transcript result
TargetArchitecture_CompleteMiss.xlsx	complete	blind_compare_8f0e1bf9675c01e2e3ef7b0b51e15eee	2026-07-29T18:18:28.920Z	transcript result
TargetArchitecture_Partial.xlsx	complete	blind_compare_99dcc58bfbef2dc711d7d9c5df2ce81a	2026-07-29T18:16:22.769Z	transcript result
TargetArchitecture_Match.xlsx	complete	blind_compare_76563bcdfe03d6e5df53b10bb4b1e28b	2026-07-29T18:14:42.760Z	transcript result
TargetArchitecture_Partial.xlsx	failed	blind_compare_ad2ae3ab9346725b425a44a0ad86a611	2026-07-29T18:10:31.483Z
TargetArchitecture_Partial.xlsx	failed	blind_compare_3631135efc7c7a4c876b7acb9c1e016d	2026-07-29T18:07:35.155Z	transcript
TargetArchitecture_Match.xlsx	complete	blind_compare_ed66f4ffa1e5f74026f4642ec16a42e7	2026-07-29T18:05:33.367Z	transcript result
TargetArchitecture_Match.xlsx	failed	blind_compare_db64ddc5dd7bc19a6154ca5ce00dc9da	2026-07-29T18:05:03.964Z	transcript
TargetArchitecture_Match.xlsx	failed	blind_compare_a8998ad318cf2c04ab589dd0c604b66c	2026-07-29T18:01:58.033Z