Seven archetypes. Each one has a known shape, a known boundary and a known way to prove it works.

Recommended architecture

• · Pure calculation core in a typed language: a function of (inputs, rule_version) with no I/O, using decimal arithmetic and explicit rounding per field.
• · Rules held as data, not code branches, so a rule change is a reviewable diff with an effective date rather than a deployment of new logic.
• · Input resolution layer that snapshots every source value with its lineage at submission time; results are always reproducible from the snapshot.
• · Scenario evaluation as stored input deltas replayed through the same core — no parallel implementation.
• · Trace object emitted alongside every result: inputs used, rules fired in order, intermediate values, warnings.
• · Thin approval application over the service: submit, review trace, approve or reject, immutable audit record with both identities.

How correctness is proven

• · Golden-master regression against a corpus of historical runs, executed on every commit, with per-field tolerances agreed in writing.
• · Property tests for invariants that must hold regardless of inputs (e.g. monotonicity, conservation between components and total).
• · Mutation testing on the rule set to confirm the corpus actually detects a changed rule.

Recommended architecture

• · Measure registry as the tool catalogue: each approved measure exposed with description, synonyms, valid filter dimensions, owner and grain.
• · Two-stage handling: resolve question → plan (measure + filters + as-of), then execute the plan in the user's security context.
• · Retrieval over curated definition notes for the 'why' half of an answer, returned with document identifiers and versions.
• · Numeric reconciliation post-check: every figure in the drafted answer must match a tool result token-for-token, or the answer is regenerated.
• · Explicit refusal path with a named human owner per domain, plus a logged gap so unanswerable-but-reasonable questions become a backlog.
• · Conversation memory limited to the current thread and never used as a source of facts.

How correctness is proven

• · A curated question set built from real historical questions, each with a known-correct measure, filter set and expected value.
• · Scored on measure-resolution accuracy, numeric exactness, citation correctness, groundedness of prose, and refusal precision.
• · Paired-identity tests to prove permission inheritance.
• · Adversarial set: prompt-injection attempts embedded in retrieved documents, leading questions, requests for figures that do not exist.

Recommended architecture

• · Target data model designed first, from the questions the database must answer — not inferred from whatever the extractor happens to produce.
• · Deterministic pre-processing: format detection, text layer extraction, OCR fallback, page and clause segmentation with stable offsets.
• · Schema-constrained extraction per field group, each returned value carrying a confidence signal and a character-offset citation back to source.
• · Three-lane routing: high-confidence auto-accept, mid-confidence human validation queue, low-confidence routed to manual capture, thresholds set per field.
• · Immutable extraction versions: re-running a better extractor creates a new version and a diff for review, never an in-place overwrite.
• · Search served from the structured store with permission filters; document text is a citation target, not the primary query surface.

How correctness is proven

• · A gold set of documents annotated by a human, held out from prompt iteration, scored field-by-field on precision, recall and exact-match.
• · Calibration check: does the confidence signal actually predict correctness?
• · Stratified sampling by document type and vintage, because older or non-standard templates are where accuracy collapses.
• · Ongoing production audit: a random sample of auto-accepted fields reviewed monthly, feeding the accuracy trend.

Recommended architecture

• · Markdown-first, file-based, version-controlled notes as the source of truth — diffable, reviewable, portable.
• · Required front-matter: owner, status (draft/approved/deprecated), effective date, review date, source system, related measure identifiers.
• · Structure by domain with a stable identifier per note so citations remain valid across renames.
• · Retrieval index rebuilt on change; approved notes ranked above drafts, deprecated notes excluded from answering but retained for history.
• · Review workflow: notes past their review date surface on an owner dashboard; unreviewed notes lose 'approved' status automatically.
• · Write-back loop: recurring unanswerable questions become suggested notes assigned to the domain owner.

How correctness is proven

• · Retrieval quality on a question set: recall@k against known-correct notes, plus citation-correctness of generated answers.
• · Freshness metrics: proportion of approved notes within their review window, and the age distribution of the corpus.
• · Coverage metrics: proportion of the measure registry with a corresponding definition note and owner.

Recommended architecture

• · Integration through the planning platform's API with a typed client and a contract test suite, so a platform-side change fails a test, not a month-end.
• · Validation harness that recomputes selected planning outputs independently and reconciles, converting silent model errors into alerts.
• · Guided input surfaces for high-friction steps, with client-side validation, saved drafts and clear submission state.
• · Scenario comparison built on stored parameter sets rather than duplicated models.
• · AI assistance restricted to narration of variances, anomaly flagging against history, and drafting commentary — always alongside the figure.

How correctness is proven

• · Reconciliation tests between the independent validation harness and the planning platform on every cycle.
• · Contract tests against the API, run on a schedule to detect upstream change.
• · Task-level UX measurement: time to complete a submission, error rate, rework rate — baselined before any change.

Recommended architecture

• · Start with an inventory: every existing automation with owner, trigger, criticality, failure history and manual workaround.
• · Standard flow skeleton: validated trigger payload → idempotency key → typed work step → outcome event → structured logging → dead letter + alert.
• · Logic-heavy steps extracted from low-code into versioned, testable services so they can be unit-tested.
• · Reusable components: shared error handler, notification format, retry policy, secret access — published as templates.
• · AI used inside flows for bounded tasks with structured outputs, always with a deterministic fallback when confidence is low.
• · A single operations view: run counts, success rate, latency and failure reasons across the automation estate, with an owner per flow.

How correctness is proven

• · Automated tests per flow against recorded trigger payloads, including malformed and duplicate ones.
• · Chaos checks: connector timeout, partial failure, the same event delivered twice.
• · Operational metrics: success rate, mean time to detect and recover, tracked per flow and reviewed monthly.

Recommended architecture

• · Medallion layering with contracts: bronze immutable landings, silver conformed entities with tested keys, gold business-shaped tables.
• · Data-quality assertions as promotion gates — uniqueness, referential integrity, freshness, accepted ranges, row-count deltas — a failure blocks publication.
• · One certified semantic model with named owners per subject area; a measure exists once, described for a non-specialist with synonyms for a machine.
• · Row-level security defined in the model and inherited by every consumer, including AI surfaces.
• · Machine-readability as a requirement: complete descriptions, synonyms, valid dimension combinations, documented grain.
• · Lineage captured from source to measure, so an answer can be traced back to a landing file and load timestamp.

How correctness is proven

• · Assertion pass rate and freshness SLAs per gold table, monitored and alerting.
• · Reconciliation against an independent trusted source for key totals, run every load.
• · Documentation coverage: proportion of measures with owner, description, synonyms and lineage complete.