# Metric and request-context contract Complete this with the metric owner for one permitted question. The completed example below is hypothetical teaching material, not accounting policy, a live financial record, or evidence of customer results. Replace its definitions with your owner's approved rules. Completing this worksheet grants no data access, accounting decision, or write authority. ## Start with these questions 1. Which number did the person request, and which similar number must not be substituted? 2. Who approves its definition, sources, period, and calculation? 3. Which records may this caller use, and which fields may reach the model and the recipient? 4. Which unresolved fact would make you pause the answer or ask the owner? ## Completed hypothetical metric | Field | Hypothetical entry | | --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Question | Explain the approved September 2026 management total for accounts A and B | | Metric identifier | `management_recognized_revenue@rev-4` | | Different metric to keep separate | Billed amounts in the billing report; do not substitute this for the requested management metric | | Owner and approver | Controller owns the reporting definition; finance reporting lead independently checks the result | | Permitted purpose | Internal management-report explanation; no external statement preparation or accounting treatment decision | | Population and exclusions | Approved accounts A and B in this company; no other accounts or later entries outside snapshot `fin-sep-7` | | Period | September 2026 reporting period defined by the approved report; exact source period boundaries must accompany a real request | | Currency | CAD; no conversion | | Grain | One approved account-period total per account | | Calculation | Sum the approved account-period totals once each; no join to invoice lines | | Source and revision | Approved finance snapshot `fin-sep-7`; definition `rev-4` | | Inputs and arithmetic | A: CAD 60,000; B: CAD 35,000; sum: CAD 95,000 | | Alternative report | Billing report shows CAD 120,000 for billed amounts; the different measure does not establish an error | | Unresolved fact | Later credit C-9 has no approved treatment and is not reflected in this snapshot | | Response | Explain CAD 95,000 as the approved snapshot total; state that C-9 is unresolved; ask the controller whether it changes this report and which approved figure would support an adjusted answer | | Prohibited inference | Do not subtract C-9, select a revenue-recognition policy, or alter finance records | | Verification | Finance reporting lead checks metric identity, period, account totals, addition, references, and unresolved-credit limitation against the approved report | These invented numbers show an evidence boundary. They do not imply a revenue-recognition treatment or recommend an accounting method. ## Completed hypothetical request packet | Packet field | Hypothetical entry | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | Request identity | `request-17`; accounts A and B; approved internal reporting purpose | | Caller and scope | Internal finance reviewer whose current access permits both accounts; trusted software rechecks access before reading records | | Context contents | Metric `rev-4`; approved totals and record references from `fin-sep-7`; task instruction to explain; unresolved status for C-9 | | Fields excluded | Other customers, payment identifiers, bank details, unnecessary contact data, and inaccessible report entries | | Source time | September reporting period; effective and fetched times retained separately in the request record | | Freshness decision | Approved historical snapshot can answer the historical question; current or adjusted totals require a new owner-approved source | | Derived content | Any generated explanation stays a proposed summary with source references and producer revision; it does not replace the approved report | | Failure response | Ask which metric applies when ambiguous; withhold prohibited account data; pause the adjusted answer while C-9 is unresolved | | Recheck triggers | Definition, source, account permission, preparation query, model, or task purpose changes | ## Blank metric record For the completed example, check that each account appears once and that its total belongs to the approved September report. If your question instead calculates a metric from underlying rows, also agree how to handle missing values, combine subtotals, and join tables without duplicating money. Those rules need the metric owner's approval; the model cannot choose them while answering. - Question, recipient, and permitted purpose: - Metric identifier and revision: - Similar labels that mean something different: - Who owns the definition, who checks the result independently, and who may approve a definition change? - Which records are included or excluded? What does one row represent, and which fields identify it? - Which tables may be joined, and how will the calculation avoid counting a record more than once? - What formula applies? How are missing values, combined totals, rounding, and permitted differences handled? - Period boundaries, reporting calendar, currency, and conversion rule if applicable: - Authoritative source, schema, snapshot/revision, and source references: - Unresolved facts, the decision needed about each, and who can make it: - Allowed answer and prohibited inference: - Verification method and reference-result source: - Review date and correction process: ## Blank request packet - Request ID and task state: - Who is asking, for which customer/accounts and purpose, and what current access check permits the request? - Which approved definition and permitted source references does the packet contain? - Which fields may the model see, and which must be excluded? - When did the source facts take effect, and when were they observed or fetched? How current must they be, and which packet revision is this? - Which preparation or query version assembled the packet, and what checks ran on the final contents? - Which facts remain unresolved, conflicting, corrected, or missing? - Where are task instructions kept separate from source evidence? - When must the service answer, escalate, or stop? - Is the output a proposal or an accepted result? Which sources, reviewer, and retention rule accompany it? Keep confidential records in the approved work environment. Do not upload them to a public worksheet or a provider without permitted access and data policy. ## Cases to review before using the answer - A request using the other metric label returns the other definition or asks for clarification. - The wrong period and an out-of-scope account cannot enter the answer. - A repeated account or one-to-many join cannot duplicate a total. - Missing or unresolved treatment stays unresolved. - Corrected sources do not silently overwrite the earlier answer or definition. - Current permission checks cover the evidence, response, citations, and logs. - Independently checked answers remain outside runtime context when evaluating calculation or retrieval. A supplied approved total is valid for a summary task but does not test derivation from underlying records. Record failed cases and the decision to correct, constrain, or pause the answer. An agreed definition still needs implementation and source checks.