00 — Overview

Queensland Audit Office (QAO) reference application. This is a demonstration prototype modelled on the Queensland Audit Office's public-facing documentation, reports, guidance and activities. It is not an official QAO system and holds no real audit data — every entity, agreement, request, submission and decision in the demo data is fictional and illustrates the data model and workflow only.

What ADIDAM is

The Audit Data Intake & Data Agreement Manager turns the receipt of audit data into a governed, evidence-backed pipeline. Data isn't "in" because a file arrived — it is accepted when it was authorised by a current data agreement and scope, matched a dataset definition and extract specification, passed validation and reconciled to its control totals, had its exceptions resolved, and received an authorised acceptance decision — after which access and retention/disposal are tracked to the end. ADIDAM holds every one of those links so the provenance and governance of audit data is always demonstrable.

The domain

Audit offices ingest large, sensitive datasets from audited agencies under legal data agreements. The hard parts are authorisation (is this permitted by an agreement and scope?), quality (does the data validate and reconcile to control totals?), and stewardship (who can access it, and when must it be destroyed?). ADIDAM models all three, keeping the intake honest against validation and reconciliation and the data itself under access and retention control.

The 19 models by area

Agreements (4) - Entity — the audited organisation. · AuditEngagement — the audit the data serves. - DataAgreement — the legal agreement authorising data sharing. · AgreementScope — a permitted dataset within it.

Requests & Datasets (5) - DataRequest — a request for data under an agreement. · DatasetDefinition — the expected dataset. - DatasetField — a field in the dataset (type, classification, PII). · ExtractSpecification — how to produce the extract. - ValidationRule — a rule the data must satisfy.

Submission & Validation (5) - SubmissionBatch — a submitted file (with checksum, counts, supersession). · ValidationRun — a validation of a submission. - ValidationResult — a rule's outcome in a run. · ControlTotalDefinition — a control total to reconcile. - Reconciliation — a source-vs-received control-total check.

Exceptions, Access & Retention (5) - IntakeException — a gap/failure (maybe blocking). · SubmissionDecision — the authorised accept/reject. - AccessGrant — who may access an accepted dataset. · RetentionDisposition — retention and disposal of a submission. - StatusHistory — the request's lifecycle trail.

(The source pack's DomainEvent outbox is Phase 2 — see page 03.)

The demo scenario

A QAO-style intake for a payroll-controls audit of the Department of Education:

  • Authorisation: a RESTRICTED, encryption-required payroll data agreement (DA-PAY) with a scoped dataset (excluding TFN and bank account); request REQ-PAY-01 for the full-year payroll extract.
  • Definition: dataset DS-PAYTXN (5 fields, PII flagged) with an extract spec, two validation rules (gross >= net blocking; pay_date in period warning) and two control totals (record count, sum of gross).
  • Submission: SUB-01 fails the blocking gross >= net rule on 3 records → intake exception EXC-01 → corrected SUB-02 (supersedes SUB-01) passes (one non-blocking warning) and reconciles (count + gross matched) → ACCEPTED.
  • Governance: audit-team access granted (expires at engagement end); retention set to destroy 12 months after the report.

35 rows across all 19 models — the whole pipeline in a realistic "failed, corrected, accepted, governed" state.