{
  "content": "# Phase Two Power BI Delivery Scope\n\n## 1. Purpose\n\nThis engagement will address the requirements that were not found, or were only partly evidenced, within the discovered Power BI landscape following the data readiness assessment.\n\nThe proposed delivery is organised into three evidence-based areas:\n\n1. Finance model enrichment for management accountability and transaction-currency analysis.\n2. Customer and sales-order modelling and measures.\n3. Month-end close controls for unapproved manual adjustments.\n\nThe scope does not include rebuilding requirements already matched to objects in the current gold boundary. Those existing objects remain dependencies where unanswered questions about their business rules, values or calculations affect the proposed work.\n\nNo effort estimate, duration, delivery date, resource model or commercial rate is stated because none was included in the evidence bundle.\n\n## 2. Decision basis and status of findings\n\nThe following acceptance rule governs this scope:\n\n- Where a named consultant recorded an explicit disposition, that decision governs the item.\n- Where no consultant decision was recorded, the model finding is carried forward unchanged as the working position.\n- An effective disposition such as `confirmed_gap` does not mean that a consultant confirmed it. Its authority is determined by the separate `basis` field.\n\nFor this evidence bundle:\n\n- No scope-bearing item has a consultant decision.\n- All 45 scope-bearing items are carried on unreviewed model findings.\n- Of those items, 21 are proposed work items.\n- Two proposed work items are weak-signal assumptions based on possible or ambiguous evidence.\n- The month-end close requirement was authored by a consultant on the client\u2019s behalf, but the ten individual comparison findings against it remain model-unreviewed.\n\nThe implications are set out in the assumption register in section 6.\n\n## 3. Scope boundary\n\nThe assessment compared requirements with the current promoted gold wiki, build `wiki_7c268dbf7f8b78844080cae53f6f0a0e`. That wiki is bounded by what the Power BI audit could access.\n\nAccordingly:\n\n- \u201cNot found\u201d means not found within the discovered landscape. It is not proof that the object or capability is absent elsewhere in the client\u2019s estate.\n- Before constructing an item classified as not found, the client must identify any candidate source, semantic model, measure, report or governed artefact that may already satisfy it.\n- If an existing asset is identified, it will be assessed against the stated requirement. A conforming asset will be reused rather than duplicated. A partially conforming asset may require adaptation. The affected deliverable and acceptance evidence must then be updated before implementation proceeds.\n- Workbook evidence consists of literal text, workbook structure, formulas and declared metadata. Ordinary numeric, date and Boolean cell values were excluded from the assessment.\n- Stored formulas show intended or prototype logic. They do not prove successful recalculation, current cached results or production correctness.\n- The client-supplied workbooks describe fictional or synthetic examples. They support design intent but do not constitute production source data, reconciliation evidence or proof of readiness.\n- Nothing in this scope states that any target object, report, refresh process or control has already been built, deployed, refreshed or adopted.\n\n## 4. Deliverables\n\n### 4.1 Finance model enrichment\n\n#### Business outcome\n\nFinance requires additional classification and transaction attributes to:\n\n- assign ledger activity to operating areas;\n- analyse transactions by transaction currency; and\n- roll accounts into governed management reporting groups.\n\nThese needs were declared in `TargetArchitecture_Partial.xlsx` and were not found in the audited `Account` and `Ledger` inventories.\n\n#### Proposed delivery\n\n| Deliverable | Business purpose | Proposed technical outcome | Evidence trace |\n|---|---|---|---|\n| Cost-centre attribution | Attribute ledger postings to the responsible operating area. | Add `Ledger.CostCentre` at the agreed posting grain, or implement a Cost Centre dimension if the client determines that a governed hierarchy is required. | `TargetArchitecture_Partial.xlsx`, item TF-11; `Target Fields!A12:J12`; `Ledger Sample!E3:E15`; `Reference Data!A1:A4` |\n| Transaction currency | Support analysis of ledger activity in its transaction currency. | Add `Ledger.CurrencyCode` using the agreed ISO code domain. Any transaction amount, reporting amount, exchange-rate fields or currency dimension are conditional on the client\u2019s design decisions. | `TargetArchitecture_Partial.xlsx`, item TF-12; `Target Fields!A13:J13`; `Ledger Sample!F3:F15`; `Reference Data!C1:C4` |\n| Management account grouping | Provide a governed management roll-up above individual accounts. | Add `Account.AccountGroup` using the approved mapping source, hierarchy, membership and effective-dating rules. | `TargetArchitecture_Partial.xlsx`, item TF-13; `Target Fields!A14:J14`; `Chart of Accounts!D3:D13`; `Reference Data!B1:B4` |\n\n#### Acceptance criteria\n\nThis work area will be accepted when:\n\n1. `Ledger.CostCentre`, `Ledger.CurrencyCode` and `Account.AccountGroup` are present in the agreed target semantic model with the agreed names and data types.\n2. `CostCentre` and `CurrencyCode` retain the agreed ledger posting grain and do not introduce unintended aggregation or duplication.\n3. The cost-centre source, hierarchy owner and effective-dating treatment are documented and reflected in the implemented design.\n4. The currency design records whether analysis uses transaction amount, reporting amount, exchange rates and a Currency dimension, and the implementation conforms to that decision.\n5. `AccountGroup` values reconcile to the approved mapping source, including the agreed handling of multiple group membership and effective dating.\n6. Test evidence demonstrates that each attribute can filter or group the relevant ledger or account records as intended.\n7. Any equivalent assets found outside the current gold boundary are assessed and either reused, adapted or rejected with the reason recorded.\n\n### 4.2 Customer and sales-order model\n\n#### Business outcome\n\nThe client-supplied sales architecture requires customer accountability, customer segmentation, sales-order analysis, gross order intake and customer lifetime value. None of the eight declared customer, sales-order or sales-measure requirements were found in the finance-led discovered landscape.\n\n#### Proposed delivery\n\n| Deliverable | Business purpose | Proposed technical outcome | Evidence trace |\n|---|---|---|---|\n| Customer identity | Provide a stable customer identity for analysis across customer records. | Add `Customer.CustomerIdentifier` using the approved governed key and agreed treatment of source-system identifiers. | `TargetArchitecture_CompleteMiss.xlsx`, item TF-01; `Target Fields!A2:J2` |\n| Customer segmentation | Analyse customers by an agreed commercial segment. | Add `Customer.CustomerSegment` using the approved domain and agreed current-state or historical treatment. | Item TF-02; `Target Fields!A3:J3`; `Reference Data!A2:C4` |\n| Relationship ownership | Attribute customer relationships to accountable owners. | Add `Customer.RelationshipOwner`, with owner identifier, display-name and history treatment subject to client decisions. | Item TF-03; `Target Fields!A4:J4` |\n| Sales-order identity | Establish the grain and identity of booked sales orders. | Add `SalesOrder.OrderIdentifier` using agreed uniqueness, revision, split-order and cancellation rules. | Item TF-04; `Target Fields!A5:J5` |\n| Gross order value | Report order value before the agreed deductions or adjustments. | Add `SalesOrder.OrderGrossValue` with approved inclusion, currency, cancellation, return and amendment rules. | Item TF-05; `Target Fields!A6:J6`; `Sales Orders!A1:D3` |\n| Sales channel | Analyse booked orders by acquisition channel. | Add `SalesOrder.SalesChannel` using the governed channel domain and attribution rule. | Item TF-06; `Target Fields!A7:J7`; `Reference Data!A5:C7` |\n| Customer lifetime value | Provide the approved forward-looking or historical customer value measure. | Add `SalesMetrics.Customer Lifetime Value` using the client-approved value basis, forecast horizon and treatment of frequency, churn, returns, discounts and tenure. | Item TF-07; `Target Fields!A8:J8`; `Sales KPI Prototype!A5:C5`; `Sales KPI Prototype!B5` |\n| Gross order intake | Measure the gross value of orders that meet the approved booked-intake definition. | Add `SalesMetrics.Gross Order Intake` using the approved booking event, reporting date, restatement and value rules. | Item TF-08; `Target Fields!A9:J9`; `Sales KPI Prototype!A4:C4`; `Sales KPI Prototype!B4` |\n\nThe workbook does not explicitly declare a `SalesOrder.CustomerIdentifier` field or a customer-to-order relationship, although the sales-order content implies that such a linkage is required. The client must approve the necessary linkage before customer lifetime value can be implemented. The precise key and relationship are not committed as named deliverables until that requirement is resolved.\n\n#### Acceptance criteria\n\nThis work area will be accepted when:\n\n1. The eight qualified objects listed above are available in the agreed target semantic model.\n2. `Customer.CustomerIdentifier` is demonstrated to be stable and unique under the client-approved key rule.\n3. The approved customer-segment domain and history treatment are documented and enforced by the model design.\n4. Relationship-owner handling covers the approved combination of owner identifiers, names, reassignment history, vacancies and shared ownership.\n5. `SalesOrder.OrderIdentifier` supports the agreed treatment of revisions, split orders, cancellations and multiple source systems or legal entities.\n6. `SalesOrder.OrderGrossValue` implements the approved treatment of tax, freight, discounts, returns, cancellations, amendments and currency.\n7. `SalesOrder.SalesChannel` uses the approved governed domain and attribution rule.\n8. A client-approved customer-to-order linkage is in place before customer-level order measures are accepted.\n9. `SalesMetrics.Customer Lifetime Value` reproduces the approved calculation across agreed test cases. The illustrative `3.2` frequency multiplier in the workbook is not accepted as a production rule unless the client explicitly approves it.\n10. `SalesMetrics.Gross Order Intake` reconciles to approved test orders under the agreed booking event, reporting date, cancellation, amendment and restatement rules.\n11. The current finance measure `Metrics.Actual Revenue` is not treated as equivalent to gross booked order intake without calculation and semantic evidence.\n12. Any candidate customer, order or sales assets found elsewhere in the estate are assessed before duplicate construction begins.\n\n### 4.3 Month-end close adjustment controls\n\n#### Business outcome\n\nFinance requires a monthly control view that identifies unapproved manual adjustments before the reporting pack is signed off. Users must be able to understand the exception value and trace it to the original ledger entries.\n\nThis requirement was authored by the Synthetic Consultant on the client\u2019s behalf. Consultant-added evidence states that `JournalSource` and `ApprovalStatus` are available in the governed ledger export at ledger-entry grain. The assessment did not find those fields in the audited semantic model and did not find the requested measure, control view, drill-through or acceptance evidence.\n\n#### Proposed delivery\n\n| Deliverable | Proposed outcome | Evidence trace |\n|---|---|---|\n| Journal control attributes | Expose `Ledger.JournalSource` and `Ledger.ApprovalStatus` from the governed ledger export in the target semantic model. | Month-end controls items R2 and R3; `Consultant Requirement!A5`; gold pages `fde-finance.current-model` and `fde-finance.journal-controls` |\n| Ledger-entry grain preservation | Preserve the two control attributes at the original ledger-entry grain, using an agreed entry key and treatment of approval history. | Item R5; `Consultant Requirement!A5` |\n| Unapproved adjustment measure | Add `Metrics.Unapproved Adjustment Value`, calculated from qualifying adjustment entries whose status is not approved. | Items R4 and R6; `Consultant Requirement!A5` |\n| Monthly close-control view | Provide a Power BI control view for the agreed Finance audience showing unapproved manual adjustments before the defined reporting-pack sign-off event. | Item R1; `Consultant Requirement!A5` |\n| Original-entry traceability | Provide drill-through to the original ledger entry, either within Power BI or through an approved finance-system link. | Item R7; `Consultant Requirement!A5` |\n| Late-approval definition | Document and apply an explicit rule for when an approval is late, including the authoritative timestamp, time zone and closed-period treatment. | Item R9; `Consultant Requirement!A5` |\n| Closed-month reconciliation | Reconcile the result to the agreed governed ledger export for one client-selected closed month. | Item R8; `Consultant Requirement!A5`; gold page `fde-finance.journal-controls` |\n| Consultant acceptance confirmation | Obtain and record confirmation from an authorised consultant that approved adjustments are excluded from the exception value. | Item R10; `Consultant Requirement!A5` |\n\n#### Required calculation rule\n\nSubject to resolution of the status and adjustment definitions, the measure is to sum the absolute value of each qualifying adjustment entry where approval status is not approved.\n\nThe following details must be approved before the calculation is finalised:\n\n- whether the calculation is an entry-level iteration over `ABS(Ledger.SignedAmount)`;\n- whether manual adjustments are identified through `JournalSource`, `IsAdjustment`, or both;\n- which statuses count as \u201cnot approved\u201d;\n- treatment of blank, pending, rejected, cancelled and unknown statuses;\n- treatment of reversals and duplicates;\n- the applicable currency and formatting;\n- required account and calendar filter behaviour.\n\n#### Acceptance criteria\n\nThis work area will be accepted when:\n\n1. `Ledger.JournalSource` and `Ledger.ApprovalStatus` are present in the agreed target semantic model and trace to the governed ledger export.\n2. The attributes remain at ledger-entry grain, with a documented unique entry key or composite key.\n3. The status domain, case handling and as-of treatment are documented and implemented.\n4. The rule identifying a manual adjustment is documented and applied consistently.\n5. `Metrics.Unapproved Adjustment Value` calculates the sum of absolute values for qualifying entries and excludes entries with the approved status.\n6. Approved, unapproved, blank-status, reversal and duplicate scenarios are covered by agreed test cases.\n7. The control view identifies the qualifying entries and their exception value for the agreed monthly close audience.\n8. The reporting-pack sign-off event and timestamp are explicitly defined.\n9. Users can drill through to the original entry using the approved traceability approach and only approved entry attributes are displayed.\n10. The late-approval definition states:\n    - the event after which approval is late;\n    - the authoritative timestamp and time zone; and\n    - whether a later approval restates the closed-month result or remains visible as a subsequent change.\n11. For the selected closed month, reconciliation evidence compares the agreed combination of row counts, qualifying entry identifiers and values with the specified governed ledger export, using the client-approved tolerance.\n12. An authorised consultant records confirmation, in the agreed acceptance artefact, that approved adjustments are excluded from the exception value.\n\n## 5. Existing matched objects\n\nThe assessment carried forward 24 model-unreviewed findings as confirmed matches. They are not proposed construction work under this scope.\n\nThese include existing finance objects such as:\n\n- `Account.AccountKey`\n- `Account.AccountName`\n- `Account.AccountType`\n- `Calendar.DateKey`\n- `Calendar.Date`\n- `Calendar.FiscalMonth`\n- `Ledger.DateKey`\n- `Ledger.AccountKey`\n- `Ledger.SignedAmount`\n- `Ledger.IsAdjustment`\n- `Metrics.Actual Net`\n- `Metrics.Actual Revenue`\n- `Metrics.Budget Net`\n- `Metrics.Net Variance`\n\nTheir existence was evidenced by object names, types and, where applicable, relationships. Exact production DAX, value-level conformance and several business rules were not available. These objects will not be assumed semantically correct where their behaviour affects a scoped deliverable.\n\n## 6. Assumption register\n\n### 6.1 Authority of scoped findings\n\n| Category | Position carried into this scope | Implication |\n|---|---|---|\n| Consultant-decided findings | None | No proposed work item has been individually accepted, rejected or amended by a consultant. |\n| Model-unreviewed proposed work | All 21 proposed work items | The model\u2019s effective disposition is the working scope position unless a consultant or authorised client decision changes it. |\n| Model-unreviewed matched items | 24 items | These objects are treated as present and are excluded from construction scope, subject to the unresolved semantic and value-level dependencies in section 7. |\n| Consultant-authored requirement | Month-end close adjustment controls | The business requirement carries consultant authority, but its ten comparison dispositions are still model-unreviewed. |\n| Context-only observation | Management P&L metric prototype | It creates no current scope obligation. Decisions could create additional scope if the prototype measures are confirmed as production requirements. |\n\n### 6.2 Proposed work carried on model findings\n\n| Work area | Model-unreviewed items |\n|---|---|\n| Finance model enrichment | `TargetArchitecture_Partial.xlsx`: TF-11, TF-12, TF-13 |\n| Customer and sales-order model | `TargetArchitecture_CompleteMiss.xlsx`: TF-01 to TF-08 |\n| Month-end close controls | `Month-end close adjustment controls`: R1 to R10 |\n\n### 6.3 Weak-signal assumptions\n\nThe following are the most likely scope items to change because the underlying comparison was classified as a possible or ambiguous match.\n\n| Item | Weak-signal assumption | Why it may change |\n|---|---|---|\n| R5, preserve `JournalSource` and `ApprovalStatus` at ledger-entry grain | The governed export is understood to provide both attributes at entry grain, but the audited model does not establish a unique ledger-entry key or confirm the implemented `Ledger` grain. | Discovery may show that approval history creates multiple rows per entry, or that ingestion aggregates or deduplicates records. |\n| R8, reconcile to the governed ledger export for a closed month | Consultant evidence supports the existence of a governed export and recommends reconciliation, but no specific export, month, tolerance or sign-off evidence was identified. | The authoritative export, reconciliation grain or acceptance tolerance may differ from the current assumption. |\n\nThese two items require explicit confirmation before their related design and acceptance approach is treated as fixed.\n\n## 7. Dependencies and decisions required\n\nUnanswered model questions are delivery dependencies. The client must provide decisions, authoritative owners or evidence for the following matters.\n\n### 7.1 Cross-cutting finance model decisions\n\n| Area | Required decision or evidence | Related evidence |\n|---|---|---|\n| Account type | Confirm whether `AccountType` covers Asset, Liability, Equity, Revenue and Expense, rather than only Revenue and Expense. | `TargetArchitecture_Partial.xlsx` TF-03; `TargetArchitecture_Match.xlsx` TF-03 |\n| Date key | Confirm and permit testing of the `YYYYMMDD` encoding and uniqueness of `Calendar.DateKey`. | Partial TF-04; Match TF-04 |\n| Fiscal month | Confirm that July is fiscal month 1 and decide whether `Calendar.FiscalMonth` must use Summarise by None rather than Sum. | Partial TF-06; Match TF-06 |\n| Date strategy | Confirm the intended use of the explicit Calendar table given that the audit also observed two hidden automatic date tables. | Current-gold limitation |\n| Signed amount | Confirm the reporting-sign convention and whether `Ledger.SignedAmount` is already in a single reporting currency. Define conversion-rate and conversion-date rules where transaction currency is introduced. | Partial TF-09; Match TF-09 |\n| Adjustment flag | Define the operational rule used to classify late or manual postings in `Ledger.IsAdjustment` and confirm that current values conform. | Partial TF-10; Match TF-10 |\n| Existing finance measures | Supply or approve the production DAX and business rules for Actual Net, Actual Revenue, Budget Net and Net Variance where those measures interact with scoped reporting. | `TargetArchitecture_Match.xlsx` TF-11 to TF-14 |\n| Budget source | Identify the approved production budget source and grain. | Match TF-13; contextual Management P&L questions |\n| Revenue and expense classification | Decide whether calculations use account-number ranges or governed `AccountType` and `AccountGroup` mappings. | Management P&L contextual observation |\n\n### 7.2 Finance enrichment decisions\n\n| Area | Required decision or evidence |\n|---|---|\n| Cost centre | Confirm source availability at ledger posting grain; decide between a Ledger code and separate dimension; nominate the hierarchy owner; define effective-dating rules. |\n| Currency | Confirm transaction-currency availability for every posting; decide whether transaction amount, reporting amount and exchange rate are also required; decide whether a governed Currency dimension is required. |\n| Account group | Nominate the authoritative mapping source and owner; define whether accounts may belong to multiple groups; define effective dating; resolve the inconsistent grouping vocabulary in the workbook examples. |\n\n### 7.3 Customer and sales decisions\n\n| Area | Required decision or evidence |\n|---|---|\n| Customer identifier | Define the governed stable and unique customer key and whether source-system identifiers must also be retained. |\n| Customer segment | Approve the segment domain, including whether Enterprise, Mid-market and Small business are exhaustive; decide whether historical segment changes must be retained. |\n| Relationship owner | Decide whether both owner identifiers and display names are required; define reassignment history, vacancies and shared ownership. |\n| Customer-order linkage | Define and approve the customer key carried by sales orders and the relationship between Customer and SalesOrder. |\n| Order identifier | Define uniqueness across systems and legal entities; define treatment of revisions, split orders and cancellations. |\n| Gross order value | Define treatment of tax, freight, discounts, currencies, cancellations, returns and amendments. |\n| Sales channel | Approve the governed channel domain and determine whether multiple-channel attribution is possible. |\n| Customer lifetime value | Approve the forecast horizon, expected-order-frequency method, value basis and treatment of churn, returns, discounts and customer tenure. |\n| Gross order intake | Define the booking event and reporting date; decide whether cancellations and amendments restate prior periods; define treatment of discounts, tax and currency conversion. |\n\n### 7.4 Month-end close-control decisions\n\n| Area | Required decision or evidence |\n|---|---|\n| Control audience and location | Nominate the report page, workspace or audience that will own the control view. |\n| Pack sign-off | Define the exact reporting-pack sign-off event and authoritative timestamp. |\n| Manual adjustment | Decide whether manual adjustments are identified by `JournalSource`, `IsAdjustment`, or both. |\n| Journal source | Approve addition to the semantic model; define the source values that constitute manual journals; nominate the value-domain owner. |\n| Approval status | Approve addition to the semantic model; define the authoritative status domain and case handling; decide whether status is current-state or as-of the close cut-off. |\n| Entry grain | Supply the authoritative ledger-entry identifier; define treatment of multiple approval-history rows; confirm whether ingestion changes source grain. |\n| Exception calculation | Confirm entry-level absolute-value logic, the meaning of \u201cnot approved\u201d, reversal and duplicate handling, currency format and filter behaviour. |\n| Drill-through | Decide between an internal Power BI drill-through and a finance-system deep link; approve the entry attributes that may be displayed. |\n| Reconciliation | Identify the authoritative export, version and owner; select the closed month; define whether row counts, identifiers and values are reconciled; set the tolerance and required sign-off evidence. |\n| Late approvals | Define the late event, closed-period treatment, authoritative timestamp and time zone. |\n| Consultant confirmation | Nominate the consultant authorised to confirm acceptance; approve test cases; choose the acceptance record, such as a test script, deployment approval or governance register. |\n\n### 7.5 Context-only decisions that could change scope\n\nThe Management P&L sheet in `TargetArchitecture_Partial.xlsx` was explicitly treated as contextual rather than authoritative. The following are not included deliverables unless the client or consultant confirms them as requirements:\n\n- `Actual Expenses`\n- `Budget Revenue`\n- `Budget Expenses`\n\nA decision is also required on their approved DAX, budget source and account-classification approach if they are brought into scope.\n\n## 8. Client responsibilities\n\nThe client is responsible for:\n\n1. Identifying authoritative business and technical owners for Finance, Chart of Accounts, Cost Centre, Currency, CRM customer data, sales orders, journal approvals and the month-end close process.\n2. Providing access to the approved source systems, exports, semantic models and reports required to confirm whether not-found items already exist elsewhere in the estate.\n3. Supplying the governed ledger export containing `JournalSource` and `ApprovalStatus`, including the ledger-entry identifier and data needed for the selected closed-month reconciliation.\n4. Supplying or approving the source and mapping rules for cost centres, currencies, account groups, customer segments, relationship owners and sales channels.\n5. Defining customer and sales-order keys, grain, relationships and history requirements.\n6. Approving the production definitions for customer lifetime value and gross order intake.\n7. Resolving the dependencies and decisions in section 7 before the affected design or calculation is finalised.\n8. Selecting the closed month and reconciliation tolerance for month-end control acceptance.\n9. Defining the reporting-pack sign-off event and late-approval rule.\n10. Confirming which ledger-entry attributes may be exposed through drill-through and any applicable access or sensitivity restrictions.\n11. Nominating business and consultant approvers and providing timely acceptance decisions.\n12. Reviewing the assumption register and either confirming the model-unreviewed positions or supplying corrections before they become fixed implementation commitments.\n\n## 9. Exclusions\n\nThe following are excluded unless separately approved through an updated scope:\n\n- Rebuilding the 24 objects classified as matched.\n- Production implementation of `Actual Expenses`, `Budget Revenue` or `Budget Expenses`, which were context-only observations.\n- Treating workbook sample values, prototype formulas or formula results as production source data.\n- Reusing existing finance measures as sales or control measures without exact DAX and semantic evidence.\n- Source-system remediation not required to expose the declared target objects.\n- Additional customer, order, currency, exchange-rate, budget or approval-history objects that are not confirmed through the decisions in section 7.\n- A customer-to-order field or relationship whose key and requirement have not been approved.\n- Report pages other than the declared month-end close-control view.\n- Refresh architecture, gateway configuration, deployment pipelines, workspace design or operational support arrangements. No supporting requirement was included in the evidence bundle.\n- Row-level security, information-protection design or broader security governance. The workbook inspection does not establish those requirements.\n- Training, communications, user adoption or organisational change activities.\n- Evidence that any target has already been deployed, refreshed or adopted.\n- Estate-wide certification that an item does not exist. The assessment boundary cannot support such a claim.\n\n## 10. Scope change conditions\n\nThe scope must be reviewed before implementation proceeds where:\n\n- an item classified as not found is located elsewhere in the client\u2019s estate;\n- a consultant changes a model-unreviewed disposition;\n- a weak-signal assumption is disproved;\n- the client confirms additional Management P&L measures as production requirements;\n- transaction-currency analysis requires additional amount or exchange-rate fields;\n- customer lifetime value requires undeclared customer-order structures;\n- approval history changes the required ledger-entry grain;\n- reconciliation requires data, periods or tolerances materially different from the stated acceptance approach; or\n- a required source, key, mapping, business definition or approver cannot be supplied.\n\nA conforming existing asset will be reused rather than duplicated. A non-conforming asset will not be treated as satisfying the requirement solely because it has a similar name.\n\n# Appendix A: Inputs used to define this scope\n\n## A.1 Client-supplied spreadsheets\n\n### Compared spreadsheet snapshots\n\nThese client-supplied spreadsheets produced the scope-bearing workbook findings.\n\n| Spreadsheet | Sheets |\n|---|---|\n| `TargetArchitecture_Partial.xlsx` | `Read Me`; `Target Fields`; `Chart of Accounts`; `Fiscal Calendar`; `Ledger Sample`; `Management P&L`; `Reference Data` (hidden); `Validation` |\n| `TargetArchitecture_Match.xlsx` | `Read Me`; `Target Fields`; `Chart of Accounts`; `Fiscal Calendar`; `Ledger Sample`; `Management P&L`; `Reference Data` (hidden); `Validation` |\n| `TargetArchitecture_CompleteMiss.xlsx` | `Read Me`; `Target Fields`; `Customer Sample`; `Sales Orders`; `Sales KPI Prototype`; `Reference Data` (hidden); `Validation` |\n\n### Earlier not-compared intake snapshots\n\nThe evidence bundle also contained earlier records of the same client-supplied filenames. They were not compared with current gold and did not produce scope-bearing findings.\n\n| Spreadsheet record | Sheets |\n|---|---|\n| Earlier `TargetArchitecture_Partial.xlsx` record | `Instructions`; `Target Fields`; `Mapping Rules`; `Reference Data` (hidden); `Validation` |\n| Earlier `TargetArchitecture_Match.xlsx` record | `Instructions`; `Target Fields`; `Mapping Rules`; `Reference Data` (hidden); `Validation` |\n| Earlier `TargetArchitecture_CompleteMiss.xlsx` record | `Instructions`; `Target Fields`; `Mapping Rules`; `Reference Data` (hidden); `Sample Input Data`; `Validation` |\n\n## A.2 Consultant-authored requirements\n\nThese requirements were authored by the consultant on the client\u2019s behalf. They carry consultant authority rather than being direct client-authored spreadsheet evidence.\n\n| Requirement | Contributor | Input form and sheet |\n|---|---|---|\n| Month-end close adjustment controls | Synthetic Consultant | Virtual workbook `consultant-requirement-month-end-close-adjustment-controls.json`; sheet `Consultant Requirement` |\n\nThe requirement calls for a monthly close-control view, `Ledger.JournalSource`, `Ledger.ApprovalStatus`, `Metrics.Unapproved Adjustment Value`, ledger-entry grain, drill-through, closed-month reconciliation, a late-approval definition and consultant confirmation that approved adjustments are excluded.\n\n## A.3 Consultant-added evidence and steering\n\nThe following consultant evidence was added to the knowledge base during the assessment and shaped what the comparison could see.\n\n| Title | Contributor | Original file | Effect on scope |\n|---|---|---|---|\n| Synthetic journal control attributes | Synthetic Consultant | `consultant-synthetic-journal-control-attributes.md` | Supported the working position that `JournalSource` and `ApprovalStatus` are available in the governed ledger export at ledger-entry grain. It did not establish implementation in Power BI. |\n\nNo separate consultant steering entries were included in the evidence bundle.",
  "id": "resp_0bb78dcc5665c49b016a6c2a1bc1788191a7c828769849db98",
  "model": "codex",
  "status": "draft",
  "usage": {
    "completion_tokens": 8574,
    "completion_tokens_details": {
      "accepted_prediction_tokens": null,
      "audio_tokens": null,
      "reasoning_tokens": 2189,
      "rejected_prediction_tokens": null
    },
    "prompt_tokens": 24491,
    "prompt_tokens_details": {
      "audio_tokens": null,
      "cache_write_tokens": null,
      "cached_creation_tokens": 0,
      "cached_tokens": 0
    },
    "total_tokens": 33065
  }
}