{ "coverage": { "by_status": { "ambiguous": 0, "context_only": 0, "direct": 0, "not_found": 4, "partial": 4, "possible": 2 }, "mapped_or_plausible": 6, "requirements_identified": 10 }, "coverage_explanation": "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.", "limitations": [ "The source is a six-text-cell virtual workbook; numeric values, formulas, formatting, and non-text workbook content were intentionally excluded.", "All substantive requirements are contained in a single text cell, Consultant Requirement!A5; decomposition into ten requirements is interpretive but preserves exact source citation.", "Current gold is bounded to two allowed pages in the selected build. Not-found results do not prove absence elsewhere in the client estate.", "The audited semantic-model page did not provide exact DAX for observed measures, so no existing measure can be semantically repurposed by assumption.", "The consultant evidence page supports upstream attribute availability but explicitly does not establish Power BI implementation.", "No report-page inventory, visual metadata, refresh configuration, row-level source samples, ledger-entry key, or acceptance-test artefacts were available.", "No substantive consultant-guidance comments were supplied beyond the trusted steering wrapper, so there was no additional guidance to apply." ], "report_markdown": "# Workbook-to-current-gold assessment\n\n## Requirement interpretation\n\nThe virtual workbook is explicitly declared as a consultant-authored requirement. Its description requests a month-end close-control capability with four connected elements:\n\n1. a monthly exception view before reporting-pack sign-off;\n2. journal-source and approval-status attributes at ledger-entry grain;\n3. an unapproved-adjustment value measure using absolute adjustment amounts and excluding approved entries; and\n4. traceability and acceptance controls covering drill-through, reconciliation, late approvals, and consultant confirmation.\n\nAll 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.\n\n## Current-gold foundations\n\nThe 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].\n\nSeparate 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].\n\n## Mapping results\n\n| ID | Requirement | Result | Current-gold assessment |\n|---|---|---|---|\n| 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]. |\n| 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]. |\n| 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]. |\n| 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]. |\n| 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]. |\n| 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]. |\n| 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]. |\n| 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]. |\n| 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]. |\n| 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]. |\n\n## Key gaps and decisions\n\n- Confirm whether the two upstream journal-control attributes are now approved additions to the semantic model scope.\n- Define the ledger-entry identifier and ensure it survives ingestion so drill-through can target the original record.\n- Specify the complete approval-status domain, including blanks, pending, rejected, reversed, and statuses changing after month close.\n- Decide whether absolute value is applied row by row before summation, as the requirement wording appears to indicate.\n- Establish the governed export version, closed-month cut-off, refresh timing, reconciliation tolerance, and accountable sign-off owner.\n- Implement and independently validate `Metrics.Unapproved Adjustment Value`; the observed current Metrics measures cannot be assumed to satisfy it.\n\n## Guidance influence and boundary\n\nNo 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.", "requirements": [ { "confidence": 0.93, "gold_page_ids": [ "fde-finance.current-model", "fde-finance.journal-controls" ], "label": "Provide a monthly close-control view identifying unapproved manual adjustments before reporting-pack sign-off", "questions": [ "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?" ], "rationale": "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.", "requirement_id": "R1", "source_cells": [ { "coordinate": "A5", "sheet": "Consultant Requirement" } ], "status": "partial" }, { "confidence": 0.98, "gold_page_ids": [ "fde-finance.current-model", "fde-finance.journal-controls" ], "label": "Obtain consultant confirmation that approved adjustments are excluded from the exception value", "questions": [ "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?" ], "rationale": "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.", "requirement_id": "R10", "source_cells": [ { "coordinate": "A5", "sheet": "Consultant Requirement" } ], "status": "not_found" }, { "confidence": 0.99, "gold_page_ids": [ "fde-finance.current-model", "fde-finance.journal-controls" ], "label": "Expose Ledger.JournalSource", "questions": [ "Is JournalSource approved for addition to the target semantic model?", "What source values constitute manual journals?", "Who owns value-domain governance and mapping changes?" ], "rationale": "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.", "requirement_id": "R2", "source_cells": [ { "coordinate": "A5", "sheet": "Consultant Requirement" } ], "status": "partial" }, { "confidence": 0.99, "gold_page_ids": [ "fde-finance.current-model", "fde-finance.journal-controls" ], "label": "Expose Ledger.ApprovalStatus", "questions": [ "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?" ], "rationale": "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.", "requirement_id": "R3", "source_cells": [ { "coordinate": "A5", "sheet": "Consultant Requirement" } ], "status": "partial" }, { "confidence": 0.99, "gold_page_ids": [ "fde-finance.current-model" ], "label": "Expose Metrics.Unapproved Adjustment Value", "questions": [ "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?" ], "rationale": "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.", "requirement_id": "R4", "source_cells": [ { "coordinate": "A5", "sheet": "Consultant Requirement" } ], "status": "not_found" }, { "confidence": 0.87, "gold_page_ids": [ "fde-finance.current-model", "fde-finance.journal-controls" ], "label": "Preserve JournalSource and ApprovalStatus at ledger-entry grain", "questions": [ "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?" ], "rationale": "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.", "requirement_id": "R5", "source_cells": [ { "coordinate": "A5", "sheet": "Consultant Requirement" } ], "status": "possible" }, { "confidence": 0.95, "gold_page_ids": [ "fde-finance.current-model", "fde-finance.journal-controls" ], "label": "Calculate the exception measure as the sum of absolute adjustment-entry values where approval status is not approved", "questions": [ "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?" ], "rationale": "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.", "requirement_id": "R6", "source_cells": [ { "coordinate": "A5", "sheet": "Consultant Requirement" } ], "status": "partial" }, { "confidence": 0.95, "gold_page_ids": [ "fde-finance.current-model", "fde-finance.journal-controls" ], "label": "Retain drill-through to the original ledger entry", "questions": [ "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?" ], "rationale": "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.", "requirement_id": "R7", "source_cells": [ { "coordinate": "A5", "sheet": "Consultant Requirement" } ], "status": "not_found" }, { "confidence": 0.91, "gold_page_ids": [ "fde-finance.journal-controls" ], "label": "Reconcile acceptance to the governed ledger export for a closed month", "questions": [ "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?" ], "rationale": "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.", "requirement_id": "R8", "source_cells": [ { "coordinate": "A5", "sheet": "Consultant Requirement" } ], "status": "possible" }, { "confidence": 0.98, "gold_page_ids": [ "fde-finance.journal-controls" ], "label": "Create an explicit definition of late approvals", "questions": [ "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?" ], "rationale": "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.", "requirement_id": "R9", "source_cells": [ { "coordinate": "A5", "sheet": "Consultant Requirement" } ], "status": "not_found" } ], "review_flags": [ { "priority": 1, "queue_name": "mapping", "reason": "Confirm that Metrics.Unapproved Adjustment Value is a new in-scope measure and define its implementation owner.", "subject": "R4" }, { "priority": 2, "queue_name": "client_question", "reason": "Late approval must be defined before calculation, refresh, and closed-month acceptance behaviour can be finalized.", "subject": "R9" }, { "priority": 3, "queue_name": "client_question", "reason": "A unique ledger-entry identifier and drill-through destination are required for traceability.", "subject": "R7" }, { "priority": 4, "queue_name": "consultant_review", "reason": "Validate row-wise absolute-value semantics and the complete not-approved status set before DAX design.", "subject": "R6" }, { "priority": 5, "queue_name": "evidence_research", "reason": "Obtain the governed export contract, selected closed month, reconciliation tolerances, and sign-off evidence.", "subject": "R8" }, { "priority": 6, "queue_name": "scope", "reason": "Resolve whether JournalSource is approved for semantic-model scope rather than merely available upstream.", "subject": "R2" }, { "priority": 7, "queue_name": "scope", "reason": "Resolve whether ApprovalStatus is approved for semantic-model scope and whether it is current-state or as-of-close data.", "subject": "R3" }, { "priority": 8, "queue_name": "revalidation", "reason": "After implementation, execute acceptance tests proving approved adjustments contribute zero to the exception value.", "subject": "R10" }, { "priority": 9, "queue_name": "consultant_review", "reason": "Confirm the control-view audience, sign-off timing, and definition of manual adjustment.", "subject": "R1" }, { "priority": 20, "queue_name": "consultant_review", "reason": "Review the decomposition of the single narrative requirement cell into ten traceable requirements.", "subject": "workbook" } ], "summary": "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." }