Data
How the system records facts, keeps them, destroys them on schedule, and moves them from the legacy systems without losing what the ministry knew and when.
Showing 31 of 31
How facts are recorded and kept 21
DR-001 Must
Every fact carries three dates, fixed before the first event
Every fact carries three time axes.Requirement
Every fact carries three time axes. It records when it was true (valid period) and when this system learned it (transaction time,
recorded_at; for a migrated fact, always the import time, ADR-002). Facts from the old systems also recordlegacy_asserted_at, the date the old system recorded them, with a rating of how confidently that date could be decoded. This structure is fixed before the first production event is written.Acceptance Criteria
A sample across fact classes, including facts from the old systems, shows for each fact its valid period, its recorded time and its old-system date (or an explicit UNKNOWN), and points to its source record.
Parameters
Rationale
The third date cannot be added later under the rule that new record formats must stay readable alongside all earlier ones (decision D10). Without it, corrections and supersessions made before cutover cannot be told apart PRIN-C10.
DR-002 Must
Fact states and lifecycle
The data model represents four fact states:Requirement
The data model represents four fact states: present, asserted negative, considered but not retainable, and disposed. It also represents four lifecycle states: asserted, active, superseded and invalidated. Invalidation is reserved for an assertion that should never have existed. Amended 2026-09-30 (ADR-004 §5): v1.3 read "An outside body, such as the tribunal, can invalidate a fact without a replacement determination." A tribunal rescission is recorded as external-determination evidence; the original determination stands, annotated, and the ministry re-determines.
Acceptance Criteria
Each state can be recorded and told apart at every point where data is captured and in every view built from it.
Parameters
Rationale
DR-003 Must
Security classification and storage placement for each fact class
Every fact class carries its security classification and is stored where that classification allows.Requirement
Every fact class carries its security classification and is stored where that classification allows. So does everything derived from it, including indexes, extracted text, thumbnails, caches and shadow comparison results (NFR-C-004).
Acceptance Criteria
An inventory of where data is stored shows no Protected C data at rest outside the permitted stores.
Parameters
Rationale
A search index built over Protected C content is itself Protected C (TA §C.11.6).
DR-004 Must
Retention class and disposal method for each fact class
Before the first production event, each fact class is given exactly one disposal method:Requirement
Before the first production event, each fact class is given exactly one disposal method:
- class-wide disposal on a schedule;
- keeping personal details in a separate store that can be deleted (reference-based indirection);
- destroying one person's encryption key (per-subject cryptographic erasure);
- permanent retention and transfer to the archives.
The shred-survivor list is published as a closed, versioned list. When a replay reaches a disposed fact, it returns a typed placeholder (a tombstone), never an error or a silent gap. Each disposal produces a signed certificate.
Acceptance Criteria
Every registered fact class has a method. A disposal run in test leaves the tamper-evident record chain verifiable and the financial control totals unchanged. The survivor list covers record header fields, the existence and outcome class of each determination, financial and recovery control facts, access-decision records, disclosure records and disposal certificates.
Added v1.6 (OB-LG4-40, RC-LG4-11, CK-LG4-17). Given a fact class that holds personal information used to make a decision that directly affects the individual, when its retention class is registered, then registration fails if the class could be disposed of sooner after that use than the minimum the Act sets (CK-LG4-17).
Parameters
Rationale
This cannot be added after the first event. The authority for it is the ARCS/ORCS records schedules, which the ministry must obtain first (decision D13; DEP-09).
DR-005 Must
Custodianship on every evidence type
Every evidence type records its custodian, governance regime, access conditions and transfer status.Requirement
Every evidence type records its custodian, governance regime, access conditions and transfer status. These are worked out for each person at the moment of access.
Acceptance Criteria
For any evidence type and person, the custodian is a value the system reads, and the access policy checks it.
Parameters
Rationale
A fixed value that cannot vary by person is what adding this later would produce (TA §B.8.2).
DR-006 Must
Limits on use recorded on facts
Facts record barred_from and permitted_for for each use.Requirement
Facts record
barred_fromandpermitted_forfor each use. These limits exist from the moment the fact is first captured, and they travel with every copy.Acceptance Criteria
A fact barred for one use and allowed for another is stored once. A copy test confirms the limit is still present on the copy.
Parameters
Rationale
A limit missing at capture is missing from every copy made before it was added (PRIN §V).
DR-007 Must
Every copy records its source, and every copy can be found
When one part of the system copies evidence from another, it records the source at the moment of copying.Requirement
When one part of the system copies evidence from another, it records the source at the moment of copying. For any fact, the system can list every part holding a copy. A correction at the source requires each of them to act, and a correction that goes unprocessed raises an alarm.
Amended 2026-09-30 (drift B6, B7; TA §B.3.3): every copy carries all five copy stamps, recorded at copy time:
Stamp Content source_contextThe owning context of the original source_evidence_idThe identity of the assertion copied source_evidence_versionWhich version of the succession set was copied source_transaction_timeThe owning context's recorded_atat the moment of the copycopied_atThe consuming context's own transaction time for the copy EvidenceCorrectionRecordedis a mandatory subscription: any context that holds a transform of an evidence assertion declares a subscription to corrections for that assertion's type in its manifest, and a fitness function checks the declaration at release. A context holding a derivative without a declared subscription fails its own pipeline. The on-premise continuity copy of NFR-A-009 is a registered derivative under this requirement (ADR-009).Acceptance Criteria
A correction test at the source lists every copy and records what each part did. An unprocessed correction raises an alarm. Given a corrected evidence id, the derivative set is returned by a lookup over the five stamps, not by asking teams. A test context that holds a copy without declaring the subscription fails its release pipeline.
Parameters
Rationale
Copying data without being able to find the copies spreads it with no record of where it went (PRIN N06). Policy says nothing about passing corrections to parties already given the information, so this requirement rests on the architecture (OBLG §6).
DR-008 Must
Policy and rate history captured when first loaded
From the first day, every rule is captured with its policy citation and the effective date shown on its own block of text.Requirement
From the first day, every rule is captured with its policy citation and the effective date shown on its own block of text. The archived rate tables are copied in once, not relied on where they sit. Older versions of policy text held by the ministry are kept under records retention for at least the replay horizon.
Acceptance Criteria
Every register row has its citation and effective date. The copied archive is kept under the programme's own retention.
Parameters
Rationale
The published archive has no retention statement and has gaps. Nothing can recover what was never published NOTE2-C1.
DR-009 Must
Data quality at the point of capture
Mandatory questions cannot be left blank, and "no" answers are captured as asserted negatives.Requirement
Mandatory questions cannot be left blank, and "no" answers are captured as asserted negatives. Every correction must say who caused the error. Values a machine reads from documents stay unverified until someone verifies them. Every migrated fact carries its confidence rating.
Acceptance Criteria
Validation rejects blank mandatory questions and corrections that do not say who caused the error.
Parameters
Rationale
Gaps in these fields cannot be fixed afterwards, because the information was never captured.
DR-020 Must M0
Evidence & Verification is event-sourced, with the evidence succession set as its aggregate
Added 2026-09-30 (drift B6;First needed in: M0
Description
Added 2026-09-30 (drift B6; TA §B.2.1, §B.3). Numbered after DR-019 and placed here because it belongs with the evidence model.
Requirement
Evidence & Verification is event-sourced. Its aggregate is the evidence succession set: the stream of versions of one logical fact about one subject. The commands
RecordEvidence,CorrectEvidence,SupersedeEvidence,VerifyEvidenceandInvalidateEvidenceappend events to that stream; nothing is updated or deleted in place. Current state is a projection rebuilt from the events. The context publishesEvidenceRecorded,EvidenceActivated,EvidenceSuperseded,EvidenceVerified,EvidenceInvalidatedandEvidenceCorrectionRecorded, under the domain-event compatibility class (NFR-I-003) and partitioned by aggregate (NFR-I-004). Every event carries the three time axes (DR-001).Acceptance Criteria
The Evidence & Verification store has no update or delete path for evidence. Dropping every projection and replaying the streams from origin reproduces the current state exactly. Given any fact, its full succession of versions, with the operation that produced each, can be read back in order. A mutable table with an audit log does not satisfy this requirement.
Parameters
Rationale
The difference between "the world changed" and "we were wrong" lives only in the succession of operations, and it decides whether a debt is recoverable. A store that overwrites current state loses it, and it cannot be rebuilt after the first event is written. No earlier version of this document required event sourcing, so a mutable table with an audit log would have passed.
DR-021 Must M0
Each program family's response to a correction is a versioned policy artefact
Added 2026-09-30 (drift B7;First needed in: M0 (mechanism), each capture module (mapping)
Description
Added 2026-09-30 (drift B7; TA §B.3.3).
Requirement
When evidence is corrected after determinations have been made from a pre-correction copy, the consuming context applies one of three responses:
Response When it applies Consequence Re-open The correction is material to entitlement and the program's rules require reassessment A fresh determination against the corrected snapshot; any difference flows to payment and to Overpayment & Recovery, classified by the operation that produced it (FR-051) Annotate-only The correction does not change the outcome, or the period is closed and the program's rules bar reassessment The determination record carries a correction annotation naming the corrected evidence id and why no reassessment followed; the original trace is untouched Flag-for-review Materiality cannot be decided mechanically, typically where a discretionary determination is among the inputs A work item with a statutory clock, routed to a delegated decision-maker, never auto-closed Each program family publishes its mapping from evidence type to response. The mapping is a versioned policy artefact under the same release governance as eligibility rules (FR-090), owned by the family's policy authority and ratified by the determination governance body before that family's first capture. The mapping version in force at the time of the correction is recorded on every correction annotation.
Acceptance Criteria
For each program family entering capture, a released mapping covers every evidence type its case context consumes. Given a correction, the annotation names the response applied and the mapping version. A consuming context that holds a derivative has a declared
EvidenceCorrectionRecordedsubscription, checked by the fitness function in DR-007.Parameters
Rationale
This is a policy decision, not an engineering one. Left to each team, five case contexts will reach five answers to the same statutory question, and the client will see a correction that the payment and debt engines never acted on (TA §B.3.3).
DR-022 Must
Youth justice information is kept apart from every other record of the young person
Information that identifies a young person's involvement in a youth justice process is held apart from any other record of that person.Priority: MUST_HAVE (the parts in groups CF15, CF17 and CF18 are conditional on DEP-26 and DEP-28)
Requirement
Information that identifies a young person's involvement in a youth justice process is held apart from any other record of that person. It is open only to those who need it and is destroyed when no longer required. Each youth justice record carries the date after which it may not be disclosed except to the youth and their counsel, worked out from the outcome and the period the federal Act sets. A copy disclosed to another person or body carries the same separation, restriction and duty to destroy. A record of an extrajudicial sanction and a record of extrajudicial measures are separate classes, each with its own access period. Youth justice record information is never included in a disclosure to an Indigenous authority unless the federal youth justice Act authorises it.
Acceptance Criteria
A test shows that no view, search, copy or disclosure of a child protection, mental health or support needs record returns youth justice information; that a record past its non-disclosure date opens only to the youth and their counsel; and that each disclosed copy is listed with its recipient until its destruction is recorded.
Parameters
Rationale
The federal youth justice Act requires the separation, the non-disclosure date and the destruction of copies, and mental health policy repeats the rule (CL-D5-140, CL-D3-037, CL-D3-042, CK-YJ1-16, CK-YJ1-17, CL-D4-041, CL-D4-042, CL-D7-016, CL-D3-054). The classes and their disposal rules cannot be added after the first record (DR-004). Needed by FR-114, FR-383, FR-414, FR-434 and FR-446 to FR-448. The federal Act's records provisions are not yet extracted (DEP-37).
DR-023 Must
Record classes that carry a bar on disclosure are marked when captured
Each of the following is its own record class, marked at the moment of capture so that the bar travels with every copy (DR-006):Priority: MUST_HAVE (test data, the custody health record and court-ordered reports are conditional on DEP-26 and DEP-28)
Requirement
Each of the following is its own record class, marked at the moment of capture so that the bar travels with every copy (DR-006):
- information obtained in a family conference, mediation or other alternative dispute resolution process, which the CFCSA bars from disclosure except as it lists;
- the identity of a person who reports that a child needs protection;
- information under solicitor-client privilege;
- raw psychological test data, test scores and completed test protocols, open only to qualified test users;
- the custody health record, which is not part of the youth's custody file;
- medical, psychological and psychiatric reports ordered by a court, externally written Gladue reports, and any report a court has ordered withheld from the youth or a parent;
- information a parent gives the parents' registry, which may be used only to give notice;
- what screening shows about a care provider, a caregiver, an applicant or another adult in a home (DR-030).
Acceptance Criteria
For each class, a test shows that the mark is present on the record and on a copy made from it, that a person outside the permitted group cannot open it, and that a disclosure package built from the surrounding record leaves it out unless a recorded basis allows it.
Parameters
Rationale
A mark cannot be added later to copies already made (CL-D8-039, CL-D1-114, CK-LG1-12, CL-D1-013, OB-IN1-24, CL-D7-016, R-MH2-42, RC-MH2-18, OB-MH2-74, CL-D3-051, CL-D3-166, RC-YJ5-03, CL-D4-052, CL-D2-195, CL-D1-153). Needed by FR-114, FR-143, FR-178, FR-196, FR-271, FR-310, FR-313, FR-389, FR-416, FR-450 and FR-471.
DR-024 Must
A restriction reaches every instance of a record, and each physical file has a known holder
Any record class can be restricted, contact and identity records included.Requirement
Any record class can be restricted, contact and identity records included. A restriction applies to every instance of the record in every medium the system holds or tracks. The system records, for each physical file, who holds it and where it is, as a fact with its own history. A restricted physical file is not sent to offsite storage while the restriction is active. When responsibility for a file transfers, the physical file goes to the receiving office. Under joint management the lead worker's office holds it.
Acceptance Criteria
Given a restricted record with an electronic part and a physical part, when the restriction is applied or removed, then both parts show the change, and a request to send the physical part offsite is refused while the restriction is active.
Parameters
Rationale
DR-025 Must
Adoption records are kept apart, and what the Act preserves for the child outlasts them
Information about the child, about the birth parents and about an adoptive applicant or prospective adoptive parent is held on three separate records.Requirement
Information about the child, about the birth parents and about an adoptive applicant or prospective adoptive parent is held on three separate records. No information about prospective adoptive parents is placed on the birth parents' record, and applicants' names are not kept on the child's record. The medical and social history of the child's biological family, and an Indigenous child's cultural identity and community information, are preserved for the child in a class that survives closure of the adoption records and stays linked to the birth identity. The preserved copy keeps identifying information that is removed from the version given to prospective adoptive parents. Original signed consents and statements of alternatives are kept as unmarked originals. A revoked consent is kept and marked as no longer valid, never removed. A homestudy is kept and disposed of as one record with every update. The signed acknowledgement of Indigenous community information is kept for each placement.
Acceptance Criteria
After an adoption order closes the child's record and the adoptive parent's record, the preserved history and cultural identity information can still be found from the birth identity by a person entitled to it, and a search of the birth parents' record returns nothing about the adoptive parents.
Parameters
Rationale
The Adoption Act requires the history and the cultural identity information to be preserved for the child, and policy requires the three records to be separate (RC-LG2-01, RC-LG2-15, CL-D2-237, CL-D2-073, CL-D2-076, CL-D7-097, CL-D7-100, CL-D7-092, CL-D2-257, CL-D2-253, CL-D2-186, CL-D2-208, CL-D2-143, RC-LG2-13, CL-D2-156). No source held states the retention period or the reopening rule for adoption records, and the period a job aid gives for applicant records is not confirmed (CK-AD4-01, CK-AD4-02; DEP-30). Needed by FR-237, FR-244, FR-256, FR-259, FR-263, FR-265, FR-267, FR-268, FR-273 and FR-276.
DR-026 Must
Records removed on an event, and records that are never kept
The disposal design (DR-004) covers classes whose removal is triggered by an event, not by a period, and classes that policy says are never kept:Priority: MUST_HAVE (recordings, referrals, communications and scan images are conditional on DEP-26 and DEP-28)
Requirement
The disposal design (DR-004) covers classes whose removal is triggered by an event, not by a period, and classes that policy says are never kept:
- adoption registry information, removed promptly when a registration is cancelled or no longer valid;
- copies of a proposal package, each registered when issued and tracked until returned, and the package and other identifying information about the child removed from the prospective adoptive parent's record after a disruption;
- audio and visual recordings of mental health sessions, which are never stored: the transcribed notes, the approval and the signed permissions are the record;
- a referral that is not accepted, and documents received from a guardian's social worker that policy calls transitory;
- recorded copies of a youth's communications in custody, kept under the short limit policy sets and extended only item by item on recorded grounds;
- body scan images, kept only where the scan led to separate confinement or a consequence, for the period policy sets from the end of that event.
For each, the system records that the removal took place, and what was removed, without keeping the content.
Acceptance Criteria
Parameters
Rationale
The Adoption Regulation requires prompt removal from the registries, and policy sets the other rules (OB-LG2-61, R-LG2-61, R-LG2-64, CK-LG2-14, RC-AD2-15, OB-AD2-20, OB-AD2-27, OB-AD2-28, CL-D2-127, CL-D2-124, CL-D5-023, CL-D5-038, RC-MH2-29, CL-D3-192, CK-YJ2-22, CL-D3-176, CK-YJ2-10, CK-YJ2-11). The rule for a referral that is not accepted rests on practice material only (CL-D5-037), and whether identification viewed to decide residency is kept waits on a ministry answer (CL-D6-016, MQ-085). Needed by FR-242, FR-245, FR-250, FR-353, FR-356, FR-473 and FR-477.
DR-027 Must
Agreements and consents made verbally are recorded with their later written confirmation
An agreement, a confirmation or a consent that the law or policy lets a person give verbally is recorded when it is given, with who gave it, how, and why it was not in writing where policy asks for the reason.Requirement
An agreement, a confirmation or a consent that the law or policy lets a person give verbally is recorded when it is given, with who gave it, how, and why it was not in writing where policy asks for the reason. The written copy, each party's signature or written confirmation (an email or text message included, where the Act allows it) and the date each arrived are added to the same record. The record keeps the terms as agreed and the date all parties agreed, which is the date the agreement takes effect. Each amendment and each renewal is kept as issued and linked in sequence to the first signing. Every version of a suicide risk assessment and of a safety plan is added to the record and none is replaced.
Acceptance Criteria
Given a safety plan agreement made verbally, when the written confirmations arrive later, then the record shows one agreement with its original effective date, each confirmation with its own date, and no confirmation overwrites what was first recorded.
Parameters
Rationale
The Act makes an agreement effective when the parties agree, whether or not anyone has signed, and the total duration of a care agreement is counted from the first signing (CL-D1-048, CL-D1-050, CL-D1-042, CL-D1-051, CL-D1-261, CL-D1-267, CL-D7-020, CL-D1-018, CL-D6-041, CL-D5-006, CL-D8-233). Needed by FR-122, FR-163, FR-166, FR-172, FR-175, FR-289, FR-349, FR-350 and FR-401.
DR-028 Must
Records that move with a child, and records that stay, on a transfer
For each kind of transfer the system records what moves, what is copied and what stays, with the custodian before and after:Priority: MUST_HAVE (the integrated care plan and custody parts are conditional on DEP-27 and DEP-28)
Requirement
For each kind of transfer the system records what moves, what is copied and what stays, with the custodian before and after:
- a transfer of responsibility between offices or agencies, where the record and the physical file move and agreements stay with the child;
- a written transfer of records from one director to another, which names the records and its effective date;
- a referral or a transition to an Indigenous authority, where the ministry's records close and the confirmations, proofs of notification and notices are kept as filed with the court;
- an adoption in another province, where the ministry's record states that the adoption records are held there and keeps a copy of every document forwarded;
- an integrated care plan, which moves with a child who leaves the region, with consent;
- health information that goes with a youth to another custody centre or to an appointment, which travels sealed;
- custody medical and master files, which stay with the ministry when a youth moves to adult custody.
The periods a child spent under each listed agreement, order or guardianship are kept, with exact dates and their source, for as long as the person can ask for an agreement as a specified adult, whatever happens to the rest of the child's record.
Acceptance Criteria
For each kind of transfer a test shows the list of records transferred, the custodian of each afterwards, that every copy the ministry keeps records its source (DR-007), and that a disposal run on a closed child's record leaves the periods that decide later eligibility.
Parameters
Rationale
The Act and policy set what moves on each transfer (CL-D1-218, CL-D8-025, CL-D1-267, CL-D1-164, CL-D7-035, CL-D1-187, CL-D1-183, CL-D7-026, CL-D2-232, CL-D2-229, R-IC1-31, CL-D3-211, CL-D3-022, OB-YJ1-07, CL-D3-051, R-LG2-90, R-LG2-91, CK-LG2-20). No source read says whether the ministry keeps its copy as custodian or transfers custody when information goes to an Indigenous authority; FR-084 needs that answer for each kind of record. Needed by FR-124, FR-126, FR-134, FR-135, FR-224, FR-277, FR-301, FR-302, FR-306, FR-314, FR-397, FR-442, FR-450 and FR-479.
DR-029 Must
A parent's contribution to a child's maintenance is held as a receivable
Where a maintenance agreement or a maintenance order requires a parent to pay, the amount owed is held as a receivable with the document that proves the debt.Requirement
Where a maintenance agreement or a maintenance order requires a parent to pay, the amount owed is held as a receivable with the document that proves the debt. One signed agreement is linked to the child's or youth's record and to the parents' record, and its retention follows the longer of the two. Its dates stay in step with the care agreement it accompanies. An in-kind contribution is recorded apart from the financial amount. Arrears owing under a maintenance order that the Act cancels on a withdrawal are kept. Financial support to a guardian after a permanent transfer of custody is held on a record of its own, which stays open after the child's service record closes.
Acceptance Criteria
Given a care agreement with a maintenance agreement, when the care agreement ends, then billing stops, the receivable keeps its history and its proving document, and the signed agreement can be found from both the child's record and the parents' record.
Parameters
Rationale
The Act keeps a parent responsible to contribute, and financial policy requires a copy of the agreement so the receivable can be set up (RC-CP2-25, OB-FI1-74, CL-D1-270, CL-D1-246, CL-D1-164, CL-D1-156, CL-D2-185). Needed by FR-135, FR-171, FR-199, FR-209 and FR-329 to FR-333. This entry states what must be kept. Where the receivable sits among the financial records is for the ledger decision (ADR-010).
DR-030 Must
Records about people who are not clients have their own handling
Information the ministry holds about a person who is not a client is held under its own access, use and retention rules, apart from any child's or youth's record it relates to.Priority: MUST_HAVE (visitor, staff search and victim records are conditional on DEP-28)
Requirement
Information the ministry holds about a person who is not a client is held under its own access, use and retention rules, apart from any child's or youth's record it relates to. This covers:
- adults in a care provider's home, and what record searches, voluntary disclosures and police say about them;
- care providers, caregivers and adoptive applicants: screening results, prior contact check consents and results, and the foster caregiver review report, which is filed on the caregiver's record and not released to the caregiver;
- visitors to a youth custody centre, in the visitor's registry;
- staff members and visitors who are searched, refuse a search or are detained;
- victims, whose identity and contact details are kept from the youth and from disclosure of the youth's own record;
- complainants and the staff a complaint is about.
What screening shows about a person is not shared with others, the parent and the Indigenous community included, without that person's consent. A prior contact check reads records collected for another purpose, so it starts only on the person's signed consent and its result carries a limit on use.
Acceptance Criteria
For each class a test shows that the record cannot be opened from a child's or youth's record by a person without access to the class, that a search or detention report about a staff member cannot be read by that person's peers, and that release outside the ministry or agency is refused without a recorded consent or legal basis.
Parameters
Rationale
Policy limits the sharing of screening results and requires consent for a prior contact check (CL-D1-064, CL-D1-153, CL-D1-150, CL-D2-006, CL-D2-009, OB-GU1-11, RC-GU1-02, OB-GU1-07, CL-D3-185, CL-D3-169, CL-D3-170, CL-D3-171, CL-D3-172, CL-D4-074, CL-D4-075, OB-QA1-04, CL-D8-155, RC-YJ2-39). No source held states a retention period for any of these classes. Needed by FR-168, FR-196, FR-226, FR-227, FR-230, FR-405, FR-424, FR-462, FR-472, FR-474 and FR-475.
DR-031 Must
Retention classes for children's services records are set before the first record, from schedules not yet held
Each children's services record class is given a retention class and a disposal method before the first record is written (DR-004).Requirement
Each children's services record class is given a retention class and a disposal method before the first record is written (DR-004). The classes include the child's service record, agreements and their amendments, court reports and orders kept as presented and as issued, notices of significant measures with proof of delivery, delegation records, reportable circumstance reports, administrative review and complaint records, the mental health client record with its physical part, and youth justice records. A delegation record is kept at least as long as any decision record that cites it. An agreement is kept at least as long as any decision made under it can be reviewed. Where policy keeps a record in both electronic and paper form, the design says which copy is the record.
Acceptance Criteria
Every children's services record class in the registry has a retention class, a start event and a disposal method, each citing the schedule entry it rests on, and none rests on a job aid alone.
Parameters
Rationale
The sources held state few retention periods and several defer to records schedules that are not in the corpus (CL-D1-010, CL-D7-112, CL-D7-129, CL-D8-190, CL-D8-192, RC-IN1-22, CL-D8-171, CL-D8-183, CL-D5-118, CL-D5-100, CL-D5-141, RC-LG3-18, CK-RP1-19; DEP-30). The guideline tells a person formerly in care they may apply for their information for a very long period, which implies a long retention class for the child's record. Needed by FR-104, FR-117, FR-136, FR-190, FR-192, FR-218, FR-338, FR-343, FR-380, FR-381 and FR-406.
Moving data from the legacy systems 7
Migration Scope: History that affects entitlement, current case state, case notes and practice history, and financial history held in ICM, MIS and the stores around them. The old audit trail is included because it is the evidence for when the old system recorded each fact.
Migration Strategy: Phased, by part of the system and by group of clients, with a shadow period before each group moves. Groups move in this order: new applicants; clients in one program with no active protection involvement; clients in several programs; and last, clients with active protection concerns or court involvement. No client is moved in the middle of a determination or an appeal.
Data Transformation: A mixed approach chosen per fact class (DR-010). Migration events use the old system's terms. Business events that claim to record what someone intended are never invented.
Data Validation: Record counts, financial control totals, checks that links between records hold, sample checks by program staff, a pilot on converted data, and the date-accuracy gate (DR-012).
Rollback Plan: Per group of clients, rehearsed, with the published list of what would be lost accepted in writing by the program policy authority (DR-015).
Migration Timeline: Per capture module (M2 onwards). Profiling the old data and the trial of decoding old-system dates both happen before design freeze.
DR-010 Must
A mixed migration approach, chosen per fact class
Facts that affect entitlement (income, assets, household, dependants, shelter, designation, enrolment periods, earlier determinations, overpayment balances) are loaded with all three time axes (DR-001):Requirement
Facts that affect entitlement (income, assets, household, dependants, shelter, designation, enrolment periods, earlier determinations, overpayment balances) are loaded with all three time axes (DR-001): valid time, transaction time (the import time, ADR-002) and legacy assertion time with its confidence, marked as coming from the old systems (provenance LEGACY). The case shell and current operational state migrate as current state only. Case notes and practice history are archived and made available through an adapter that marks them as coming from the old systems. Everything else is loaded through named migration events such as
LegacyClientWasImported.Acceptance Criteria
Every fact class appears in the migration register with its approach. No invented business events exist.
Parameters
Rationale
Each fact class has its own right answer, and using one approach for everything is an error (decision D10).
DR-011 Must
Migration records its source, can be re-run, and can be reversed per group
Every migrated fact records its source system, source record identifier, migration batch identifier, migration time and a confidence rating.Requirement
Every migrated fact records its source system, source record identifier, migration batch identifier, migration time and a confidence rating. Migration can be re-run without creating duplicates, keyed on the source record identifier, and can be reversed for each group of clients TA-C43.
Acceptance Criteria
Running a migration batch twice creates no duplicates. In test, a group of clients can be un-migrated and migrated again.
Parameters
Rationale
Migration is a product with its own quality gates, not a one-off task.
DR-012 Must
Migration quality gates, including date accuracy
Migration gates check record counts, control totals, links between records, samples checked by people, and a pilot on converted data.Requirement
Migration gates check record counts, control totals, links between records, samples checked by people, and a pilot on converted data. They also set two date-accuracy minimums for each fact class: the percentage of facts with a known valid period, and the percentage with a recoverable old-system date. Both minimums are agreed before migration begins.
Acceptance Criteria
No group of clients passes a gate whose minimums were set after the data was measured.
Parameters
Rationale
The standard gates cannot detect that the "when did we learn it" dates have all collapsed to the import date. The comparator ran no pilot on converted data and produced about 114,000 errors in converted legacy records (TA §C.2.8).
DR-013 Must
Unknown old-system dates are visible, and default in the client's favour
For a migrated fact, recorded_at is always the import time, and is never set to legacy_asserted_at;Requirement
For a migrated fact,
recorded_atis always the import time, and is never set tolegacy_asserted_at; a decoded or inferred old-system date is carried only inlegacy_asserted_atwith its confidence (ADR-002). When a fact's old-system date is UNKNOWN, the two kinds of question behave differently:- Valid-time questions (a recalculation, or a replay reproducing an amount) proceed, order the fact by its
recorded_at(the import time), and mark the determination TEMPORALLY_UNVERIFIED. This marker is carried onto the decision record, notices and appeal packages. - Knowledge-state questions (overpayment classification, tribunal reconstruction, disclosure history) return
INDETERMINATE. They never substitute the import time or the migration timestamp, and they direct the reader to the retained legacy audit trail.
An overpayment component whose classification is
INDETERMINATEdefaults to administrative error and is not recovered, unless a person reclassifies it on recorded evidence. Amended 2026-09-30 (ADR-002; drift B14): v1.3 read "it treats the fact as recorded at migration and marks the determination TEMPORALLY_UNVERIFIED" for every replay, without separating the two kinds of question. Before design freeze, the old audit trail is profiled across the most important fact classes, with at least 10,000 records for each.Acceptance Criteria
Profiling results are published for each class. A TEMPORALLY_UNVERIFIED determination cannot, on its own, show what the ministry knew at a past date. A knowledge-state query over an UNKNOWN fact returns INDETERMINATE and never a date.
Parameters
Rationale
If the ministry cannot show when it knew something, it cannot meet the burden of proof a tribunal places on it TA-C19. The client-favourable default is the architecture's administrative-error default (TA §C.7.5), stated from the client's side (ADR-002 §3; TA §B.3.1).
- Valid-time questions (a recalculation, or a replay reproducing an amount) proceed, order the fact by its
DR-014 Must
Running old and new systems side by side, and writing back to the old system
Responsibility for a record moves from the old system to the new one per part of the system and per group of clients, never one field at a time.Requirement
Responsibility for a record moves from the old system to the new one per part of the system and per group of clients, never one field at a time. When the new system writes changes back to the old one for groups it has taken over, the write-back:
- uses only insert and update operations. It never uses a synchronize operation on an object with child records, unless a check before writing confirms the data is complete;
- is kept out of the new system's outgoing event queue, so it cannot loop back;
- is removed from both sides of every reconciliation and shadow comparison;
- keeps the old system's validation, or records a decision for each case where validation is bypassed;
- runs one way only for records the new system has taken over;
- follows a published mapping, per fact class, that lists every field with nowhere to go in the old system.
Acceptance Criteria
A deliberately incomplete write is refused. A loop test shows no echoed events. The list of what would be lost is published before the new system takes over writing for a group (state S2).
Parameters
Rationale
Writing back to the old system is the most dangerous write path in the old and new systems combined (TA §C.2.6).
DR-015 Must
Rollback rehearsed, with its losses published
Every group of clients moved to the new system can be moved back to the old one without a separate data project.Requirement
Every group of clients moved to the new system can be moved back to the old one without a separate data project. The published list of losses names every fact class that would not survive the move back, and the difference between a correction and a supersession is always on it. Rollback is rehearsed before any group moves.
Acceptance Criteria
The rollback rehearsal record and the accepted list of losses are present at the capture gate.
Parameters
Rationale
A rollback plan that does not say what is lost has not been tested (PRIN N14).
DR-016 Must
Retiring the old systems and disposing of their data
Each old system is retired as its replacement goes live.Requirement
Each old system is retired as its replacement goes live. Each record class receives one of five outcomes: moved, archived for a period, transferred to the archives, permanently and ethically deleted, or transferred to another government (an Indigenous governing body or other sovereign). The oldest core systems and the old audit trail are kept in a complete archive with controlled access. People who use a core old system, staff and oversight bodies get at least twelve months' notice before it is shut down. Disposal decisions are in place before the new system takes over writing for each part (state S2).
Acceptance Criteria
Old interfaces are closed, with evidence, and counted against the full list of interfaces from Module 0.
Parameters
Rationale
Systems cannot be retired by deleting them, and retention duties run for decades beyond the programme (TA §C.2.9).
Using data and identity 3
DR-017 Must
Analysis without making copies
People and systems analysing data get what they are entitled to, at the level of detail they are entitled to, from one governed store, without a new copy being made.Requirement
People and systems analysing data get what they are entitled to, at the level of detail they are entitled to, from one governed store, without a new copy being made. Only de-identified, aggregated, synthetic or differentially private versions leave the trusted environment.
Acceptance Criteria
The list of data consumers shows no new extracts. Every dataset in public cloud is a registered de-identified or aggregated version.
Parameters
Rationale
Endless copying of production data is the defining data failure of the current systems (commitment 4; decision D6). Amended 2026-09-30 (drift B11): raised from SHOULD_HAVE. Commitment 4 can be relaxed only by the Chief Data Officer and the Ministry Privacy Officer, jointly (TA §A.3), and no relaxation is recorded. A data warehouse that already exists, built on shared reporting dimensions, means this is a migration from what exists (APP §9).
DR-018 Should
Mapping the old work categories to the new ones
Migrated work items and historical reporting are mapped from the old service request types and sub-types (about 30 types and 128 sub-types) to the new work item types through a published mapping.Requirement
Migrated work items and historical reporting are mapped from the old service request types and sub-types (about 30 types and 128 sub-types) to the new work item types through a published mapping. The new types come from the ministry's service catalogue and obligations, not from the old categories.
Acceptance Criteria
Every old type and sub-type maps to a new type or to a recorded retirement.
Parameters
Rationale
Reports need to stay comparable across the cutover (GAPS P-02). Carrying the old categories forward as the design would tie the new model to the old system's vocabulary (N10).
DR-019 Must
Identity data is read when needed, not stored
The system reads identity details from provincial identity services when it needs them and does not keep them longer than they stay valid.Requirement
The system reads identity details from provincial identity services when it needs them and does not keep them longer than they stay valid. The client index holds only identifiers and the personal details needed to match people, and does not become a second directory.
Acceptance Criteria
An inventory of stored data shows no login credential or identity-service detail kept beyond its validity.
Parameters
Rationale
Participant Identity holds only identifiers and matching details (TA §B.6.1).
The main information objects
Each object belongs to one part of the system. They are not a shared model that every part must use; each part keeps its own view of what it needs.
1 Evidence assertion
Description: A dated claim about the world, with a record of where it came from. Every decision is worked out from these claims. Owned by Evidence & Verification, which is event-sourced: the aggregate is the evidence succession set, the stream of versions of one logical fact about one subject. Commands append events, and the attributes below are a projection of that stream (DR-020).
Attributes:
Attribute Type Required Description Constraints assertion_id Identifier Yes Permanent identifier of the claim Never changes succession_set_id Identifier Yes The succession set (aggregate) this version belongs to; also the event partition key Never changes; added v1.4 (DR-020) version Integer Yes Position of this version in its succession set (the aggregate version) Monotonic per succession set; used for ordering and gap detection, never for rejection (NFR-I-004); added v1.4 evidence_type Reference Yes The registered kind of evidence (its structure, purpose, security classification, retention class and custodian rules) Must be registered (FR-076) subject_ref Reference Yes Reference to the subject of the claim Keyed by the participant identifier; carries no other context's internal identifiers. (v1.3 read "No identifier shared across parts", which contradicted keying projections by participant identifier, TA §B.2.1; drift B13.) value Typed value Conditional The claim itself Empty only for fact states that carry no value fact_state Enum Yes present, asserted_negative, considered_not_retainable, disposed DR-002 valid_period Period Yes When the claim is true in the world — recorded_at Instant Yes When this system learned it (for migrated facts, when it was imported) Set by the system legacy_asserted_at Instant No When the old system recorded it (the third time axis) With a confidence rating (DR-001); never copied into recorded_at(ADR-002)legacy_assertion_confidence Enum Conditional DECODED, INFERRED, UNKNOWN Required on migrated facts lifecycle_state Enum Yes asserted, active, superseded, invalidated — operation Enum Yes record, supersede, correct, invalidate — error_attribution Enum Conditional client, ministry, third_party, indeterminate Required on every correction provenance Structure Yes Who supplied it, through which channel, who acted, the source record, and the extraction tool version and confidence where a machine read it from a document — verification_status Enum Yes unverified, verified (with method) Machine extraction never sets verified use_constraints Structure No barred_from and permitted_for, per use DR-006 custodianship Structure Yes custodian, governance regime, access conditions, transfer status DR-005 Relationships: One claim can have many supporting documents, each linked by a typed relationship. One claim can have many copies in other parts of the system, and each copy records the five copy stamps (DR-007).
Data Volume: Not measured. The only indicators are the Release 26.7 volumes (NFR-P-001) and the record counts expected at cutover (NFR-S-003).
Access Patterns: Reads "as at" a declared point in the record stream (the watermark); history by when a fact was true and by when the system learned it.
Data Classification: Protected B by default, and Protected C for classes that are classified that way. Data from the old systems is treated as Protected C until it is reclassified.
Data Retention: Set per fact class under the approved records schedules (DR-004). The ministry has not yet obtained these schedules.
2 Determination record
Description: The permanent, unchangeable record of a decision. It holds everything needed to reproduce, explain and disclose the decision. Kept in the decision record store.
Attributes:
Attribute Type Required Description Constraints determination_id Identifier Yes Permanent identifier Never changes decision_type Enum Yes grant, deny, reduce_or_discontinue FR-001 classification Enum Yes Administrative decision; needs a human decision-maker; intermediate calculation FR-003 rules_artefact_digest Hash Yes Fingerprint of the exact rules file used Artefact 1 engine_version_and_digest Structure Yes Version number and fingerprint of the rules engine software Artefact 2 input_snapshot Serialised value Yes The facts as read, stored in full rather than as links Artefact 3 decision_trace Structure Yes The rules that fired, the branches taken and the intermediate values, in a format the ministry owns Artefact 4 notice_template_hash Hash Yes (Class A/B) Fingerprint of the notice template version Artefact 5 watermark Instant Yes The point in the record stream the facts were read at FR-009 components List Yes Benefit components, each with its amount, effective date and the rule version that calculated it FR-005 criteria_satisfied / criteria_not_satisfied List Yes With reasons for each criterion FR-001 assumptions_made / evidence_lacking List Yes An explicit "none" is allowed FR-001 provisions_applied List Yes The sections of legislation applied FR-001 decision_maker Structure Yes Person or system, authority and capacity; anything proposed to them is recorded apart from what they concluded FR-004 notification_date Date Yes once notified Date the client was told FR-064 replay_scope Enum Yes full, scoped_disposed, scoped_non_retainable, temporally_unverified FR-008, DR-013 Relationships: Supersedes earlier determinations for a period. A determination rescinded by the tribunal is not cancelled: it stands, annotated with the rescission reference, and a new retroactive determination follows (ADR-004). Produces payment instructions (written by Financial Components) and overpayment components.
Data Volume: The number of determinations a year for each program family has not been measured. The architecture calls it the single most important missing number (NFR-P-003).
Access Patterns: By person and period; replay by identifier; assembly into appeal records.
Data Classification: Protected B or C, taken from the classification of the facts it read.
Data Retention: For the full period during which the decision can be appealed, reviewed or requested under access law, and at least as long as the replay horizon (FR-008). The fields on the shred-survivor list remain after the rest is destroyed (DR-004).
3 Payment instruction
Description: The one lasting record that links a determination to a payment. Financial Components is the sole writer of this aggregate (it creates, cancels and supersedes instructions), and only the Issuance Service in Payments & Benefit Issuance accepts it. Acceptance, runs, disbursement, stops and returns belong to the separate
Disbursementaggregate, whose sole writer is Payments & Benefit Issuance (ADR-001).Attributes:
Attribute Type Required Description Constraints payment_instruction_id Identifier Yes Key that stops the same payment being made twice Calculated from the determination reference, benefit period, payee reference and sequence determination_refs List Yes The determinations this payment pays out Empty only on the exception path payee_ref, payee_role Reference, Enum Yes Client, alternate payee, trustee, provider, third party — amount_gross, deductions Money, List Yes Each deduction listed separately Minimum floor enforced at issuance (FR-048) value_date, benefit_period Date, Period Yes — — channel Enum Yes Direct deposit, cheque, provincial payment service — purpose_code Enum Yes Regular, supplement, reissue, emergency, interim provider, recovery credit, remedy — funding_code Structure Yes Corporate accounting code — requested_by, approved_by Reference Yes Two different people or systems Must not be the same (FR-046) state Enum Yes accepted, released, settled, returned, rejected, stop requested, stop confirmed, stop failed Cannot be edited once accepted Relationships: Belongs to one payment run. A reissue links to the instruction it replaces.
Data Volume: About 73,920 orders in the monthly rollover today (APP §10).
Access Patterns: By run, payee, determination and period; matched against other records during reconciliation.
Data Classification: Protected B.
Data Retention: The financial control facts are on the shred-survivor list.
4 Overpayment component
Description: One classified part of the difference between two determinations, or a repayable issuance resolved on denial (ADR-005). Owned by Overpayment & Recovery.
Attributes:
Attribute Type Required Description Constraints component_id Identifier Yes — — origin Enum Yes retroactive_recalculation, resolved_repayable_issuance Added v1.4 (ADR-005) cause_evidence_event Reference Conditional The change in evidence that caused it Required when origin is retroactive_recalculation prior_and_new_determinations Reference pair Conditional — Same period; required when origin is retroactive_recalculation repayable_issuance_ref Reference Conditional The resolved repayable issuance in Financial Components Required when origin is resolved_repayable_issuance; classification set by policy classification Enum Yes Recoverable, recoverable (misrepresentation), administrative error Nothing can act on an unclassified component amount, period Money, Period Yes — — human_decision Structure Yes before raising Decision-maker, authority, rationale FR-052 raising_batch_id Identifier Yes The batch that can be reversed as one unit FR-052 status Enum Yes computed, decided, raised, disputed, recovered, written off, reversed — Data Classification: Protected B.
Data Retention: The control facts remain after the rest is destroyed.
5 Clock and clock instance
Description: A time limit set by law or policy, registered once, and each running copy of it. Every program family uses the same registered clocks.
Attributes:
Attribute Type Required Description Constraints clock_id Identifier Yes Unique across the whole system Replaces the identifiers that were only unique within one part of the obligation register owner Enum Yes Ministry, client, tribunal, external adjudicator — class Enum Yes Entitlement or service standard — start_event, duration, base, day_type Structure Yes Base is one of the seven calendar bases; day type is business or calendar days No default extensions List No Each with the approval it needs — breach_consequence Reference Conditional Rule applied when the deadline is missed Follows from owner and class effective_period Period Yes Versioned like a rules file — Data Classification: Protected A for the definitions; each running clock takes the classification of the person or case it concerns.
6 Entitlement and variant
Description: A catalogue entry for a benefit, supplement or program, with its adjudicability (whether and how its decisions can be challenged). Held in the rules and adjudicability registers.
Attributes:
Attribute Type Required Description Constraints entitlement_id, variant_of Identifier, Reference Yes, No — A variant inherits nothing unless it says so statutory_basis Text Yes Or "none under either Act" — reconsiderable, appealable, forum Enum, Enum, Reference Yes — An unresolved value blocks notices adjudicating_authority Reference Yes Who decides and who reviews, recorded separately FR-036 rules, rates, intervals References Yes Into the rules register Effective-dated Data Volume: 95 adjudicability rows today, covering 58 entitlements and 37 variants.
7 Consent instrument
Description: A consent, with its scope, period, legal authority and lifecycle. Owned by Consent & Disclosure, the single master of client consent and the consent registry consulted by access-policy evaluation (ADR-003). Distinct from the data-sharing agreement (Entity 8), which binds organisations and stays with Secure Data Exchange.
Attributes: instrument type; subject; the person giving consent and anyone acting for them; scope (sources, purposes, parties); valid period; lifecycle state (granted → scoped → expired | revoked); how it can be revoked; evidence of signature or the verbal record.
Data Classification: Protected B.
8 Data-sharing agreement
Description: A machine-readable agreement that is the only source of authority for every data exchange and access right. Held in the agreement registry.
Attributes: agreement identifier; participants by class (provincial, federal, Indigenous governing body, contracted provider); permitted services; authorities relied on; purpose; retention and onward-disclosure terms; expiry and review dates; accountable executives; lifecycle state; unchangeable change history.
Data Classification: Protected A.
9 Work item
Description: A unit of work that points to the record it concerns in the part of the system that owns it. Owned by Work Management, a single domain context consumed by all five case contexts (ADR-001).
Attributes: work item type (registered); subject reference; owning part of the system; state; priority; due date and where it comes from (a legal clock or a service standard); assignment history with reasons; supervisors watching after escalation.
Constraints: Program-specific fields are not allowed.
Data Classification: Protected B.
10 Issued notice
Description: What the client was actually sent. Owned by Notices & Correspondence.
Attributes: notice identifier; determination reference; template version fingerprint; language; format; the rendered document; delivery events (issued, delivered, deemed received, proven served); notification date.
Data Classification: Same as the determination it explains.
Data Retention: Same as the decision it explains. The rendered document is kept for every notice that conveys a decision.
11 Issuance run
Added v1.5 (TA §C.6.2).
Description: One scheduled batch of payments for a value date and benefit period. A supplementary or off-cycle payment is a run of one. Owned by Payments & Benefit Issuance.
Attributes:
Attribute Type Required Description Constraints run_id Identifier Yes — — value_date, benefit_period Date, Period Yes — — cycle_definition_version Reference Yes The versioned query that selected the instructions Stored with the run stage Enum Yes open, cutoff, assembled, totals set, approved, released, settling, reconciled, closed A closed run cannot be reopened stage_owner Reference Yes The named owner of the current stage — control_totals Structure Yes Count, gross, deductions and net, by channel and by program Fixed at assembly; never changed requested_by, approved_by Reference Yes — The approver requested no instruction in the run (FR-046) delegated_authority_ref Reference Yes The approver's authority at the time Not below the run's net value Relationships: Holds many payment instructions (Entity 3) and their disbursements (Entity 12).
Data Classification: Protected B.
Data Retention: The control totals are on the shred-survivor list.
12 Disbursement
Added v1.5 (TA §C.6.1, §C.6.3; ADR-001).
Description: What happened to one payment instruction once the chokepoint accepted it. Payments & Benefit Issuance is its sole writer.
Attributes:
Attribute Type Required Description Constraints disbursement_id Identifier Yes — — payment_instruction_id Reference Yes The instruction it carries out One per instruction run_id Reference Yes — No disbursement exists outside a run channel_ref Reference Yes Bank file item, cheque number, or the provincial payment service's token and settlement reference Cheque numbers come from a controlled range; no cardholder data (FR-097) released_at, settled_at Timestamp Conditional — Two separate events with two dates stop Structure No requested, confirmed or failed Success is never assumed recall Structure No The request and its outcome A failed recall becomes an overpayment by an event return Structure No Return or rejection, with the channel's reason Reopens the entitlement as unpaid reissue_request Reference No The request for a new instruction Only when stopped, returned or rejected Data Classification: Protected B.
Data Retention: As Entity 3.
13 Ledger entry
Added v1.5 (TA §C.6.4).
Description: One double-entry record in the ministry's subsidiary ledger of benefit obligations. Owned by Financial Components. The corporate financial system remains the book of record.
Attributes:
Attribute Type Required Description Constraints entry_id Identifier Yes — Entries are added, never changed entry_type Enum Yes obligation raised, disbursement released, disbursement settled, reversal, receivable raised, recovery, write-off Interest only where FR-102 is switched on debit, credit Money Yes — Every entry balances coding_block Structure Yes The corporate accounting code — determination_ref Reference Yes — An obligation with no determination is a break run_id Reference Conditional — Required for disbursement entries period Period Yes The entitlement period the entry belongs to — Data Classification: Protected B.
Data Retention: On the shred-survivor list; totals are the same before and after disposal (DR-004).
14 Reconciliation break
Added v1.5 (TA §C.6.4).
Description: One unmatched item or variance found by reconciliation.
Attributes:
Attribute Type Required Description Constraints break_id Identifier Yes — — reconciliation Enum Yes ledger to channel settlement, ledger to corporate financial system, determination to obligation — items List Yes The entries, postings or determinations that do not match — owner Reference Yes Payment operations lead, financial systems lead, or determination platform owner Set by the reconciliation type opened_at, age Timestamp, Duration Yes — Age is published (NFR-M-003) escalation_threshold Duration Yes — FR-045 status Enum Yes open, escalated, explained, cleared Cleared only by finance operations, who cannot approve runs (FR-046) Data Classification: Protected B.
15 Repayment agreement
Added v1.5 (TA §C.7.1, §C.7.3).
Description: The terms on which a debt is repaid. Owned by Overpayment & Recovery.
Attributes:
Attribute Type Required Description Constraints agreement_id, version Identifier, Integer Yes — Each change is a new version component_refs List Yes The overpayment components it covers (Entity 4) — basis Enum Yes agreed with the client, default terms — rate Structure Yes The rate, the period it applies to and the date it was recorded Between the statutory minimum protection and the policy maximum (FR-101) mechanism Enum Yes deduction, set-off, direct repayment Set-off only through Overpayment & Recovery and the chokepoint (FR-048) hardship_or_deferral Structure No The decision, the decision-maker, the authority, the reasons, the end date FR-101 Data Classification: Protected B.
Data Retention: The existence and status of the agreement remain after the rest is destroyed.
16 Repayable issuance
Added v1.5 (TA §C.6.1; ADR-005; FR-041).
Description: Money paid against a promise to repay, where a later determination settles whether it must be repaid. Financial Components is its sole writer and decides nothing.
Attributes:
Attribute Type Required Description Constraints repayable_issuance_id Identifier Yes — — undertaking Structure Yes The promise to repay, with its signature requirement No payment without it awaited_determination Reference Yes The determination that will settle it — covered_period Compound clock Yes — — payment_instruction_refs List Yes The instructions that paid it Each passes the chokepoint with its own purpose code resolution Enum Conditional closed, partly repayable, fully repayable Set only by the awaited determination's event Relationships: On denial it produces an overpayment component (Entity 4) whose classification policy sets.
Data Classification: Protected B.
Data quality
Data Accuracy: Shadow comparison proves correctness separately for each type of difference (FR-095). A single overall match rate does not count. Two wrong amounts that cancel each other out to a zero total count as a defect.
Data Completeness: Mandatory questions are answered or recorded as asserted negatives (DR-009). Determination records carry every required field (FR-001). Migrated facts that affect entitlement meet minimum rates, agreed in advance, for having a known valid period and a recoverable old-system date (DR-012).
Data Consistency: There is one writer per aggregate per cohort (N05). (Restored 2026-09-30, drift Δ1.2: v1.1–v1.3 read "Only one system can change each record for each group of clients".) Reference data has one master copy, published as events (FR-094). Money is reconciled three ways every day (FR-045). Read-only views are compared with the old system every day, with rows written back by the new system removed from both sides first (DR-014).
Data Timeliness: The system refuses a determination when its facts are older than the consistency limit allows (FR-009). Delays in processing published events have limits and raise alarms (NFR-P-005).
Data Lineage: Every fact records where it came from, including the extraction tool version and confidence where a machine read it. Every copy records its source (DR-007). Every migrated fact records its source system, source record, migration batch, migration time and confidence (DR-011).