Audit Data Intake & Data Agreement Manager (ADIDAM)
Make audit data intake a governed, connected model — from the data agreement that authorises it, through the request, the dataset definition and extract specification, to the submission, its validation and reconciliation, the acceptance decision, and the access and retention that follow.
Its central question:
For each audit data request, is it authorised by an agreement, did the submitted data pass validation and reconcile to its control totals, were exceptions resolved before acceptance — and is access and retention/disposal of that data governed end to end?
It sits beside the audit office's engagement tooling and the agency's source systems — it owns the agreement → request → submission → validation → acceptance → retention intake pipeline and the governance around it.
The intake spine
Entity / Audit Engagement → Data Agreement → Agreement Scope → Data Request → Dataset Definition / Field / Extract Specification / Validation Rule → Submission Batch → Validation Run / Result → Control Total → Reconciliation → Intake Exception → Submission Decision → Access Grant / Retention Disposition, with a Status History trail on each request.
The documents
| Page | What's in it |
|---|---|
| 00 — Overview | What the app is, the domain, the 19 models by area, the demo scenario |
| 01 — Quick Reference | Menu map, every model, key status vocabularies, the demo data set |
| 02 — System Diagram | The data-intake model as a diagram (+ interactive viewer) |
| 03 — Phase 2 Scope | The runtime not yet built: the request/submission state machines, the validation engine, reconciliation, acceptance guards and the DomainEvents outbox |
Status
Phase 1 (built): all 19 models render as an AI-Safe CRUD register with a dashboard, seeded with one coherent QAO-style intake (35 rows) — a payroll extract whose first submission fails a blocking validation (raising an exception), then a corrected resubmission passes and reconciles, is accepted, granted and retained.
Phase 2 (scoped, not built): the request/submission lifecycle state machines, the
validation engine and control-total reconciliation, the acceptance guard rules (validation
passed, reconciliations within tolerance, no blocking exceptions), retention/disposal
scheduling, and the DomainEvent outbox — see page 03.
Prototype system; draft. All entities, engagements, agreements, datasets, submissions and decisions in the demo data are fictional; values demonstrate structure only and are not real audit data.