# Analyst AI verification lab

Original local teaching workflow. Candidate answers are deliberately authored fixtures, not recorded outputs from a named model. No model API has been called and no model benchmark result is claimed.

Run `python calculator.py` from this directory with Python 3.12 or a compatible version. The standard-library calculator reads the sibling commerce lab's original synthetic `orders.csv`, validates grain/types, applies `contract.json`, and writes reference evidence, seeded candidates and checker results.

## Metric contract

January 2026 completed-order amount, one row per order, local Asia/Kolkata timestamps for this exercise, inclusive January 1 and exclusive February 1. The supplied `order_total_paise` is used directly; discounts are not subtracted again. Unmatched customer identity does not exclude the order.

Expected amount is 104,000 paise (₹1,040) across eight eligible orders. This is a defined order-amount measure, not recognized revenue, cash collection, profit or a causal effect. The sibling refund fixture has no refund timestamps, so it cannot establish January cash-flow or as-of refund timing.

## What the checker establishes

The answer contract checks metric identity, period, timezone, currency, unit, exact integer value, eligible order count and evidence IDs. It checks a small structured claim schema and rejects a declared causal claim because this dataset has no causal design.

It does **not** interpret arbitrary prose reliably. A deliberately mislabeled causal sentence is included as an expected structural pass but a required semantic-review failure. This is an intentional demonstration of a grader blind spot, not an accepted publishable answer. Every result retains `human_review_required: true`.

The seeded cases exercise fan-out, customer-join loss, distinct-amount misuse, wrong units, wrong periods, wrong counts, missing evidence and numeric-string types. They evaluate the local checking code. They must never be presented as accuracy scores for an AI assistant or evidence that prompt injection is solved.

## Additional components

Run `python verify_extensions.py` to exercise the bounded SQL tool, versioned glossary, citation metadata and review-record binding. All use Python's standard library. No network access or model account is needed.

- `readonly_sql.py` creates a fresh synthetic in-memory database exposing only order ID, timestamp, status and amount. It combines query-only mode, a default-deny SQLite authorizer, allowed functions/columns, statement and result limits, and a VM work budget. It rejects writes, metadata reads, attachment, arbitrary pragmas, unapproved functions, recursive operations and excess results. Limits are trusted application configuration. It is not a production gateway, tenant-access system, OS sandbox or guarantee against every resource attack; source loading is a trusted fixture step outside the SQL budget. SQL permission does not establish metric correctness.
- `glossary.json` and `glossary.py` supply original current/historical definitions and an explicitly untrusted seeded instruction. Exact-term retrieval filters approval and effective dates and abstains on unknown terms. There is no vector search or language model. The `approved` metadata is authored teaching configuration; a production workflow must protect who can set it.
- Citation checks establish document identity, effective period and metric alignment, not arbitrary prose entailment or numeric provenance. The glossary contains definitions, not calculated business totals.
- `review.py` binds a local review record to exact answer/evidence bytes and rejects edits or source changes. The synthetic reviewer field is not authenticated; scripted approval fixtures are not real human approvals. No function sends or publishes anything.

The source contract and deterministic reference remain distinct from any future language-model output. `verification-results.json` covers the 11 seeded answer cases; `extension-verification.json` records separately executed boundary/retrieval/review checks.

## Weekly reporting scaffold

`python weekly_assistant.py` reuses the separate report-automation fixture for January 5–12 UTC: E1/E2/E5, three selected paid events, 3,500 paise. It writes `weekly-review-packet.json` and `weekly-verification.json`. Its narrative is a deterministic authored template, with seeded wrong candidates used to test the checker. No live model is called and review remains pending. The monthly completed-order calculator and this weekly paid-event workflow are different contracts and must not be conflated.

See [the verification protocol](VERIFICATION_PROTOCOL.md) and [the portfolio case](../../projects/verified-weekly-reporting-assistant.md) for pass criteria, reproduction, limitations and a proposed rubric.