Quality requirements

Before design freeze, every cell of the architecture's capacity table is filled in and has a named owner. The table covers peak and average transactions per second, concurrent workers, annual determination volume, p95 and p99 response times, availability, recovery time and recovery point. It covers the Open Host Service, the anti-corruption layer, the determination service, the event backbone, each domain store, work management and payments.

• Figures come from the legacy system's own telemetry over a full monthly issuance cycle, not from workshop estimates.
• Concurrent worker numbers come from directory and session data. Determination volumes come from legacy counts per program family.
• Response targets start from observed legacy behaviour, plus the improvement the service standard commits to.

The table is reviewed at the design-freeze gate. Every figure must trace to a telemetry extract.

The only volumes recorded today are per-interface and batch figures from the technical design documents APP-C1. For example, the employment-assistance monthly rollover covers about 158,414 benefit plans, 414,225 benefit lines and 73,920 orders. MIS feedback runs to about 400,000 header and 400,000 detail records a month. A CPP request file holds about 250,000 records. The predecessor's audit counted about 9,400 user accounts (TA §C.16.4). That is the number of users, not the number working at once.

Nobody can responsibly approve the combined caseworker read while the legacy platform's saturation point is unmeasured. The anti-corruption layer's rate limits, circuit breakers and bulkheads are sized from these numbers (TA §C.15.2).

N16 [PROPOSED], N18

A full monthly issuance cycle at production volume completes within the window the corporate financial calendar allows. The cycle includes assembly, pre-flight checks, approval, release, settlement intake and three-way reconciliation. If release is interrupted, it resumes and still finishes within the same window.

A full-scale synthetic run in a production-shaped environment, including a test that interrupts release part-way (TA §C.6.8 criterion 3).

Monthly rollover volumes as in NFR-P-001. The peak follows the issuance run, not the working day.

Load on the payments service peaks with the issuance run, not over the course of the day (TA §C.15.1).

N17

The determination service handles the measured annual determination volume for each program family and the measured peak rate. This includes recalculating every affected case in batch after a rate change. The capacity model records the headroom factor, set by its owner, the ministry CTO.

A load test that replays a recorded month of determinations, and a rate-change simulation across the full affected population.

The architecture calls annual determination volume "the single most important number" in its capacity table (TA §C.15.1).

N07

Before the first production determination, the system sets a limit on how far the evidence snapshot may lag behind the latest recorded facts. There is one limit per determination class (interactive, batch issuance and retroactive recalculation), set from measured projection lag. The system monitors the lag against the limit.

Projection-lag telemetry for each contributing stream, with an alarm as lag approaches the limit.

The architecture's example limits (seconds for interactive decisions, about a minute for batch) are unverified. The real numbers must come from measurement (TA §B.4.3).

N09

Each consumer publishes the most lag it can tolerate. The system raises an alarm at half that figure. Past the maximum, captured cohorts move to manual verification before any payment issues.

Lag metrics for each consumer against its own threshold.

When the backbone degrades, messages pile up, and a pile-up is only safe if it has a limit (TA §E.8.3).

N06, N18

Interactive analytics queries must filter on a partition. Service tiers are committed per data class, as decided under D5. Caching for the most sensitive class happens in memory only.

The Module 0 object-store benchmark, and query-plan checks that reject interactive queries without a partition filter.

The object store's documented profile is response times over 100 ms and 1,000 active connections per node. Partition pruning is the first lever, and local disk caching is forbidden for Protected C (TA §A.5, §C.14).

N12

Each component on the caseworker's interactive path is available 99.9% of the time. The combined caseworker read has a design target of 99.5%. That read runs through the experience back end, the Open Host Service, three contexts and the determination service. Availability is stated per service, and the combined figure is recalculated whenever the chain of calls changes.

• A 99.5% combined figure allows about 2¼ minutes of unplanned downtime per 7.5-hour working day [D].
• Maintenance windows for payment services come from the financial calendar (NFR-M-007).

Availability is measured at the contract boundary, as the consumer experiences it (NFR-M-002).

Availability multiplies along a chain of dependencies, and nobody has yet done that arithmetic for this system's own chain of calls (TA §C.3.8).

N16 [PROPOSED]

• RPO: zero for anything that affects an entitlement or a payment, meaning determinations, payment instructions and evidence assertions TA-C29. Other data may have a stated RPO.
• RTO: stated for each service against the harm its failure causes. Shared infrastructure takes the strictest target of anything that depends on it.
• Recovery objectives are proven by exercise for each release train, not just stated.

Recovery exercise results for each tier-1 component. A figure nobody has measured is not a target.

A lost payment instruction is a person without money TA-C13.

N16 [PROPOSED]

Every synchronous dependency has a declared timeout, a circuit breaker and a declared fallback behaviour. Every screen that depends on the exchange states what the worker sees, what they can still do, and what is queued.

• Circuit breaker for external dependencies
• Timeout on all network calls
• Retry with backoff only for idempotent operations
• Bulkhead isolation, including per external provider
• Degraded behaviour documented per screen

An architecture fitness function that checks every outbound client has a timeout and a breaker, plus tests of each fallback mode.

A dependency without a stated fallback takes the caseworker desktop down with it (TA §C.15.3).

N16 [PROPOSED], N18

No interactive path depends synchronously on more than one external participant TA-C30. Any exchange on a caseworker path that blocks the worker needs 99.9% availability, run active-active across multiple sites, with bulkheads for each provider. Where two or more participants are involved, the design is asynchronous and uses a work item.

Call-graph analysis for each interactive journey. The exchange's availability commitment is obtained in writing (dependency DEP-06).

Four participants at 99.5% each combine to 98.0%, which is too low for work a caseworker waits on (TA §C.3.8).

N16 [PROPOSED]

Payments keep issuing while the corporate financial system is closed for month-end or year-end posting. Postings wait in a queue that has an owner and an age alarm, and they are released when posting reopens.

A blackout simulation in the M6 test cycle, plus an age alarm on queued postings.

A benefit payment must not depend on a finance system's maintenance window (TA §C.6.6).

N16 [PROPOSED], N17

Disaster recovery exercises run twice a year, and at least one each year is unannounced to the operations team TA-C31. They cover catalogue restore, event backbone recovery, read-model rebuild and determination replay from the decision record store.

The business owns a business continuity plan that is separate from rollback. It covers how an office serves a client with no system for a day and for a week, how staff record actions for later entry, and who authorises payment. It is exercised each year with the regional offices before the first capture.

Exercise reports with measured recovery times, checked against NFR-A-002.

A restore nobody has run is a hypothesis (TA §E.8.5).

N16 [PROPOSED], N14

The 24/7 statutory child protection reporting line has the highest availability target in the platform, set by its business owner with the CIO. Its intake path depends on no service whose combined availability falls below that target. A rehearsed fallback path receives and safely records a report when downstream services are down. The line has its own change window.

The combined-availability arithmetic is run against this chain of calls specifically, and the fallback path is rehearsed.

If the reporting line is down for two hours on a Sunday, a child protection report goes unreceived (TA §C.12.2).

N16 [PROPOSED], N15

Each failure below has a fallback mode that is rehearsed and has a named decision-maker:

• The anti-corruption layer is unavailable. Read models keep serving and show a visible staleness indicator.
• The event backbone is unavailable. The outbox accumulates messages.
• The determination service is unavailable. Determinations queue, and a captured cohort never falls back to legacy.
• The exchange is unavailable. Where policy permits, determinations proceed on the evidence held and are flagged for verification after issue TA-C32.
• The legacy platform is unavailable. Cohorts not yet captured become read-only.

Amended v1.5 (TA §E.8.3), payments under each fallback:

• The event backbone is unavailable. Each consumer has a published maximum lag, with an alarm at half of it. Past the maximum, captured cohorts are verified by a person before payment is issued.
• The determination service is unavailable. Once determinations have queued for longer than the stated interval, the trigger for emergency issuance is met (FR-047).
• The exchange is unavailable. No client's payment waits on another organisation's gateway.

Rehearsal records for each fallback mode.

A fallback mode first discovered during an incident is an outage (TA §E.8.3).

N05, N16 [PROPOSED]

The ministry must be able to keep its mission-critical services running if the supplier of any core software-as-a-service (SaaS) product cuts off access to it, or the product is lost for a long time for any other reason. Any recovery that depends on reaching the SaaS product at that point, such as a batch data export, fails in this case. The fallback must not need it.

Restated 2026-09-30 under ADR-009 Part A (ACCEPTED). The programme direction of 2026-09-29 is unchanged: supplier cut-off is the contingency; the copy is retrieved continuously or on a cycle while the service is live; it serves mission-critical services only; monthly payment issuance comes first; the cut-off is rehearsed without warning. What changed is that the copy now preserves the architecture's evidence model (drift Δ2.4, Δ3.1–Δ3.7).

• Scope by context, not by product. A SaaS product sits wholly inside one bounded context, behind that context's published contract, and exchanges only evidence and determinations with other contexts (N02, N03, N10). A product is core if losing it would stop a mission-critical service of the context it sits in. (v1.3 read: "if losing it would stop determinations, payment issuance, or caseworkers' access to case records". That wording presumed a SaaS product could hold the system of record or host determination; see Part B below.)
• What the continuity copy is. For each core SaaS product, the ministry holds on-premise, on infrastructure it controls, a replica of records, not of state:
• the owning context's covered event streams, with their evidence succession sets, all three time axes and the operation (Record, Supersede, Correct, Verify, Invalidate) preserved, verified against the hash chain and signed heads (NFR-SEC-009);
• the decision-record store;
• the rules artefacts and engine images;
• projections rebuilt from those.

A vendor table snapshot, a CRUD change-data-capture feed or a CSV extract does not conform unless it is transformed, at capture, into the owning context's registered events with all three time axes and the operation preserved. (v1.3 read: "a copy of a defined core subset of the product's data".)

• Kept current while the service is live. The copy is retrieved continuously or on a stated cycle while the service is available. Its maximum age may not exceed the batch watermark bound (FR-009, NFR-P-004); otherwise a separate fallback bound is recorded and stamped on every determination made in fallback.
• What the copy is for. The copy supports the mission-critical services only, not every service. The ministry defines and owns the list of mission-critical services and the records each one needs.
• Payments come first. The first mission-critical service is monthly payment issuance: determining, issuing and reconciling the monthly payment run. Its fallback is designed, built and rehearsed before any other.
• Fallback runs the same function. Determinations made in fallback run the same Determine(), with the five bound artefacts and the watermark (FR-001, FR-008, FR-009). Payments made in fallback go through the same controls as normal payments (FR-042, FR-046).
• One writer at every moment. Switching to fallback is a recorded single-writer handover per context and per cohort (N05). Events written in fallback are appended to the authoritative streams when service returns, never merged (FR-098). Payment instruction identifiers keep their FR-042 derivation, so an entitlement cannot be paid twice across the switch. (v1.3 read: "reconciled if and when service is restored or replaced", which is the both-write-then-reconcile pattern N05 forbids.)
• The copy is a registered derivative. It is subject to correction propagation, use constraints, disposition and cryptographic erasure like any other copy (DR-004, DR-006, DR-007).
• Plan details for each product. The continuity plan (NFR-A-006) states the copy's maximum age, when a loss of service counts as protracted, who decides to switch to the fallback, and who decides to switch back.
• Products that cannot be core. A SaaS product cannot be a core element if the records above cannot be retrieved continuously or on a cycle while the service is running, or if its function cannot run outside the supplier's service. (Function portability restored from v1.2; v1.3 removed it without a changelog entry, drift Δ3.4.)

What this requirement does not authorise (ADR-009 Part B, PROPOSED). NFR-A-009 is a continuity requirement. It does not by itself authorise any SaaS product to store Protected C data, to hold the system of record, or to host determination. Each of those needs a recorded relaxation by its named authority: storing Protected C data or holding the system of record needs A.3 commitment 5, agreed jointly by the Ministry Privacy Officer, the provincial CISO and the Ministry Records Officer (a reclassification question under D12; TC-1, NFR-C-004); hosting determination needs A.3 commitment 2, agreed jointly by the Chief Architect and the ADM Policy and Program Design (FR-090; NFR-I-006). Until such a relaxation is recorded, a SaaS product may be core only where its data stays below Protected C, or it holds a projection whose system of record is on-premise, and it does not host determination.

A rehearsal is recorded for each core SaaS product, as for NFR-A-008. In the rehearsal, access to the product is cut off without warning, and the mission-critical services run from the continuity copy alone. The rehearsal verifies the copy against the hash chain, runs fallback determinations through the same Determine(), and on return appends the fallback events without a merge. The monthly payment run is rehearsed first, at production volume, before that SaaS product goes live.

If a supplier withdraws access, the source system is offline by construction, so nothing can be exported from it at that point. A client's monthly payment is still due on a set date. Programme direction, 2026-09-29, recorded as ADR-009 Part A. The copy must preserve the evidence model, because a state replica loses succession sets, the three time axes, the difference between Supersede and Correct, registered schemas and hash-chain continuity, and a fallback built on it could not produce a defensible determination.

BR-004, BR-013, FR-001, FR-008, FR-009, FR-042, FR-043, FR-046, FR-047, FR-098, DR-004, DR-006, DR-007, NFR-A-005, NFR-A-006, NFR-A-008, NFR-C-004, TC-1, TC-11

N16 [PROPOSED], N05, N03, N01, N17

ADR-009 (Part A ACCEPTED; Part B PROPOSED)

NFR-A-007 covers receipt of a report on the reporting line. This requirement covers the work that follows it and runs on limits counted in hours or from the moment a person is informed. Outside office hours and away from the office, a worker can screen a report and a supervisor can approve the screening; contact an Indigenous authority, record its confirmation and refer a report; record a safety assessment, a verbal safety plan agreement and a withdrawal from one; record that a child was taken charge of or removed, with the start time, the efforts to reach a parent and the supervisor's approval; and write, approve and send a reportable circumstance report. When the system is unavailable, an entry made afterwards carries the time each act took place, and no start time is lost.

The availability target for these functions is set by their business owner with the CIO and measured for evenings, weekends and holidays apart from office hours. A rehearsal takes the system down during a taking charge and shows that the start time and the approval are recorded afterwards with their true times.

The Act requires a prompt report, policy requires an immediate screening assessment in a dangerous situation, taking charge runs on limits counted in hours, and the reportable circumstance limit runs from being informed with no stated allowance for weekends or holidays (CL-D1-022, CL-D1-023, CL-D7-160, CL-D1-018, CL-D1-019, CL-D1-042, CL-D1-051, CL-D1-059, CL-D1-060, CL-D1-131, CL-D7-211, CL-D1-118, CK-QA1-07, CK-QA1-08, CK-QA1-09). The standards for delegated agencies require an on-call service with access to a supervisor at all times, subject to DEP-29. Needed by FR-122, FR-123, FR-145, FR-160, FR-165, FR-166, FR-180, FR-182 and FR-338.

N16, N19, N01

A custody centre runs day and night. The system is available for custody records through nights, weekends and holidays, or takes entries made after the event with the time each act took place. This covers the restraint log and its intervals, the use of force notice, the health care assessment after a restraint, an emergency medical leave approved in the centre Director's absence, a serious complaint made after hours to the on-call youth custody director, a warrant of suspension sought by police out of hours, and the provincial director's review for a youth detained on a weekend.

The availability target for custody functions is set by their business owner with the CIO and measured across all hours. A rehearsal records a restraint during an outage and shows each interval entered afterwards with its true time.

The restraint intervals, the use of force notice and the health care assessment run in minutes and hours, and policy sends out-of-hours warrants, reviews and serious complaints to an on-call manager or director (CL-D3-157, CL-D3-161, CL-D3-163, CL-D3-166, CL-D4-129, CL-D4-130, AU-YJ3-12, OB-YJ2-78). Needed by FR-427, FR-458, FR-462 and FR-469 to FR-471.

N16, N19

Services scale horizontally, without code changes, to the measured peaks in NFR-P-001 to NFR-P-003. The capacity model records growth projections for caseload and determination volume, set by its owner.

None of the sources give any. The capacity model's owner (the ministry CTO, with the operations directorate) records them before design freeze.

A scale test to the recorded headroom factor.

Scale depends on the number of people served, not on the legacy system, so today's volumes are a minimum.

N16 [PROPOSED]

Stores can be partitioned by retention class from the first event, and are sized to keep records for decades. The current system keeps child services records for up to 90 years after closure and investigation records for 15 years (APP §6). Records are disposed of by class when their schedule expires.

Set per fact class under DR-004. The default is disposal of a whole class on schedule. Large, loosely structured content uses reference-based indirection. Per-subject cryptographic erasure applies only to named classes. Archival transfer applies where required.

Partitioning by retention class must be in place from the first event (TA §B.7.1).

N12

Migration, identity matching and backfill run, re-run and reconcile at cutover volumes within agreed windows. The design documents record matching-key volumes of about 15 million contact aliases, 35 million service-provider keys in the corporate accounting system, 1 million service-provider keys and 8 million contact-matching keys.

A full-volume migration rehearsal that passes the quality gates in DR-012.

Migration is a product with its own quality gates, not a project task (TA §C.2.8).

N01, N14

All users sign in through the provincial single sign-on service using OIDC.

• Staff: the corporate directory, with its multi-factor authentication.
• Citizens: the BC Services Card authentication service, at identity assurance level 3.
• Businesses and providers: BCeID Basic and Business.
• Browser security: each experience has a back end for front end that holds the confidential client. No access token, refresh token or identity assertion reaches storage the browser can read TA-C33.
• Session and re-authentication rules follow the provincial service's policy and are recorded for each experience.

A security architecture review at each module gate, plus an automated check that no token reaches the browser.

Identity is a commodity and is reused as it is (TA §B.6.1; commitment 8).

N11

Program confidentiality rules and API access rules are versioned, tested policy artefacts. A policy engine evaluates them, and they are released through the same pipeline as eligibility rules. Access is checked at every resolver and endpoint, on both the links and the records of the graph. A restricted client record is a separate type, not an empty field on a normal record. Every access decision is logged with who, what, the purpose and the legal basis.

A policy test corpus in CI, where a policy change that reduces coverage fails the build. Graph tests confirm that a restricted record's existence cannot be inferred from empty fields.

In child protection, the fact that a record exists is often the sensitive fact (TA §B.6.2).

N21, N13, N18

Access rights come from role definitions and program assignments held in a system of record, and automation applies them. Manual grant is not a supported operation TA-C34. Every role definition has a named owner and an expiry date. The system publishes a count of accounts holding rights that the access model does not explain, with a target of zero. Access reviews run every quarter for standard roles and every month for elevated and restricted-record access.

Accounts reconciled against the access model and published every cycle.

The predecessor's audit found that more than a third of about 9,400 users had access outside the defined model, and that nobody was checking (TA §C.16.4).

N17, N18

The system watches access patterns for anomalies, such as records outside the assigned caseload, out-of-hours restricted access and unusual volumes. Alerts go to a monitored queue with an SLA. Staff must record a business reason before opening a restricted or active-protection record. Break-glass access exists, is logged, and is reviewed within one business day. Restricted-record access is logged separately and can raise its own alerts.

SLA metrics for the monitoring queue, plus sampled reviews of break-glass events.

In a social-services breach, the people most at risk are those under active protection (TA §C.16.2).

N17, N18

• Data in transit: TLS everywhere, with mutual TLS between exchange participants.
• Data at rest: encrypted in every store, backup and document store. Per-subject payload encryption applies only to fact classes assigned cryptographic erasure.
• One key inventory records, for each key, the custodian role, how it is held, how it is rotated, how it is destroyed, and what becomes unreadable if it is lost.
• Per-subject data keys are wrapped by a master key in a hardware security module or the platform key service. They are never exported in plaintext and never held in escrow. The wrapping key rotates once a year.

The key inventory is reviewed at each gate. Destruction is verified by showing that a known ciphertext can no longer be decrypted.

A key whose loss makes twenty years of determinations unverifiable needs different handling from one whose loss only means reissuing a certificate (TA §C.16.3, §B.7.3).

N12, N08

No secret appears in code, configuration, design documents or logs. Secrets are kept in the platform secrets service. No connection uses clear-text authentication.

Secret scanning in CI and across document repositories, plus a credential inventory.

The platform already provides secrets management, and the system reuses it (TA §C.18).

N11, N18

• SBOM generation, licence scanning and vulnerability scanning block builds in CI, across the whole platform.
• An independent tester runs a penetration test at each module gate. It covers what changed, plus a standing set of identity, access and exchange-edge tests.
• Remediation: critical findings are fixed, or formally risk-accepted by a named executive, before the gate closes. High findings are fixed within 30 days with a tracked plan. Medium findings are fixed within 90 days. Low findings go into the backlog with an expiry date TA-C35. Risk acceptances expire after 90 days.

Gate evidence. An open critical finding means the gate fails.

A finding without a fix date is an open finding (TA §C.16.1).

N18

Each bounded context has a threat model before its first production release. The model is revised whenever trust boundaries, external interfaces or data classification change. An incident response runbook and severity model exist before the first production release, and are exercised at least once a year.

Both are required artefacts at the release gate.

No threat model, no production release (TA §C.16.1).

N18

The decision record store, the event backbone and the access-decision stream are hash-chained. Chain heads are signed and kept separately from the store, under different administrative control. An offline verifier can check integrity without the live systems.

Amended v1.5 (TA §B.5.5 item 6): the covered streams are named, and for money they are: the payment instruction and disbursement streams of Payments & Benefit Issuance; the double-entry event log of Financial Components; and the assessment, agreement and write-off streams of Overpayment & Recovery. None of these is left to a later judgement of where integrity matters.

A job that verifies the chain, plus a tampering simulation in test.

Records examined years later need integrity designed in, not assumed (TA §C.4.4, §B.5.5).

N08, N13

The system reaches four evidence tiers for cross-organisation exchange:

• E1, in place before the first production exchange: every request and response is logged with participant, agreement, legal basis, purpose, correlation identifier, timestamp and hashes of the message bodies.
• E2, at launch: the log is hash-chained, and signed chain heads are kept independently.
• E3, within the first year: chain heads get trusted timestamps.
• E4: each message is signed, for a named class of disclosures agreed with legal counsel.

Exchange log records checked against the schema, plus chain verification.

A message exchanged before E1 is in place leaves no evidence, ever TA-C36.

N18, N21

Aggregates enforce their own rules, and no integration, batch load, migration script or write-back path gets around them. Any write path that skips validation needs a written decision that names each skipped check and what makes up for it.

Tests that send invalid commands through every entry path, plus an inventory of written bypass decisions.

A rule the aggregate enforces cannot be skipped by an integration, a batch load or a migration script (PRIN N04).

N04

Development, test and training environments use synthetic or de-identified data. The shadow-comparison pipeline processes real personal information, so it is classified, retained and disposed of under the same rules as the main store.

Classification scans of non-production stores.

Comparison records must not become an uncontrolled second store of client-affecting evidence (TA §C.2.7, §E.7.2).

N12

Access rules for children and family services are written per service line and tested as code (NFR-SEC-002). A support needs worker delivering a service outside the CFCSA mandate cannot open child protection or other CFCSA records. A child protection worker cannot open a family's support needs record. Information passes between the two only on a recorded basis: consent, or a request under the Act. The Act that governs each record is recorded on it and decides who may see it. Psychological test data is open only to qualified test users. Within an integrated team, a declined consent to share limits reading to the serving member and the people policy names, and a clinical note is never readable through the shared view. During a pending transfer the receiving office has read access, so access follows the state of the transfer and not office membership alone. Every director and delegate, delegated agencies included, can read every community agreement.

An automated test for each pair of service lines attempts to open the other's records and is refused, and each refused attempt appears in the access log (NFR-SEC-004). The test set is run on every release.

Policy bars access across the support needs and child protection lines in both directions and sets the other limits (CL-D6-026, CL-D6-027, CL-D6-028, CL-D1-106, R-RX1-06, CL-D5-157, CL-D5-158, R-IC1-15, CL-D5-109, CL-D7-008, R-MH2-42). An access rule that does not exist before the first record is written leaves earlier records open. Needed by FR-117, FR-118, FR-289, FR-291, FR-377, FR-389, FR-395 and FR-398. The access rule for mental health clinical records is described only in a user manual, so the ministry should state it as policy first (R-MH1-41, AU-MH1-20). The mental health and integrated team parts are conditional on DEP-26 and DEP-27.

N21, N13, N18

Where a staff member is also the subject of a record, the bar follows the person and not the role. An employee who is a foster caregiver cannot open records relating to the children they foster, whatever role they hold, and decisions on their own foster care arrangement go to a director of operations outside their chain of command. An employee does not serve, as an employee, a person recorded as one they have seen in private counselling work. A report of a search, a refusal or a detention of a staff member cannot be read by that person's peers or from a youth's file. People with permission to see information but no authority to act, such as those in a practicum category of delegation, can read and cannot record a director's act. Staff who review records for a prior contact check, an audit or a foster caregiver review are given access limited to the person or the evaluation named, and each access records that purpose.

Tests give one person two roles and show that the bar holds in each. Refused attempts are logged and reviewed (NFR-SEC-004). A sample of review and audit accesses is checked against the consent or the evaluation scope on record.

The ministry's guidance requires these safeguards where it permits an employee to foster or to do private counselling work, and policy scopes access for checks and audits (OB-RF1-40, OB-QA1-22, CL-D2-009, RC-GU1-06, CL-D1-006, CL-D3-169, CL-D3-170, CL-D3-171, CL-D3-172). Needed by FR-107, FR-226, FR-229, FR-345, FR-347 and FR-472. The custody search records are conditional on DEP-28. Practice guidance also restricts staff members' own homestudies further (R-AD4-13), which is to confirm against current policy.

N17, N18, N21

The system sets, for each record class, whether a person without access to the content may learn that a record exists. A person search by a support needs worker shows that a record exists without opening it. A safety alert and its recommended actions are shown to all staff who meet the child, youth or family, including staff who cannot see the clinical record behind it. A safety plan agreement, its copies and its notices are visible only to the parties to that agreement, so that an agreement made with one parent alone need not be made known to the other where domestic violence is a factor. Any record class can be restricted, contact and identity records included, and a restricted record is open only to the limited group policy names.

For each record class a test signs in as a person without content access and compares what the search, the alert view and the notice list show against the rule registered for that class.

Policy sets each of these visibility rules (CL-D6-027, CL-D6-028, OB-MH2-15, CL-D5-007, CL-D1-062, CL-D8-001, CL-D8-006). Needed by FR-164, FR-291, FR-299 and FR-351. The alert rule is conditional on DEP-26.

N21, N18, N15

Freedom of Information and Protection of Privacy Act; the ministry's FOIPPA policy.

• Collection limited to what is necessary (FR-076); disclosure starts from the legal basis (FR-077)
• Access and correction rights supported (FR-079, FR-081)
• Privacy impact assessment complete for each context before its gate, alongside the security assessment (NFR-C-006)
• "Whose personal information was accessed, by whom, and when" answerable with a query, not an investigation
• Correlation identifiers carried across every boundary, so a breach that spans legacy, the layer and a new context can be traced

Canadian data centres, per provincial cloud policy. Protected C storage per NFR-C-004.

The duty to notify runs on a "without unreasonable delay" standard, so the time from detection to assessment is the control that matters (TA §C.16.2).

N13, N21, N06

Each audit event records who (user or service), what, when (UTC), where (component), why (purpose, legal basis, correlation identifier) and the result. Retention follows the records classification and the appeal window, not the platform defaults of two months for system logs and thirteen months for audit logs TA-C37. Retention is set before the first production audit log is written. Log content is treated as personal information.

Hash-chained, per NFR-SEC-009.

Retention that was never applied cannot be applied after the fact (TA §C.17.2).

N12, N18

Before the first production event, the system decides disposition for each fact class (DR-004). That covers the mechanism, the published shred-survivor set, key custody, how destruction is verified, and what replay does with disposed data. Replay substitutes a typed tombstone. It never fails and never skips. Each disposition is certified, and afterwards the financial control totals still reconcile to the same values TA-C38.

The authority for N12 is the Information Management Act and the ARCS/ORCS schedules, and neither has been acquired yet OBLG-C2.

N12, N08

Protected C data is stored only on-premise. It may be processed on the general compute tiers, within the D12 decision on what counts as storage TA-C39. No Protected C data is processed or stored in public cloud. Public cloud workloads, in Canadian regions only, use only de-identified, aggregated, synthetic or differentially-private derivatives (D6). Access by support staff and vendor telemetry from outside Canada count as disclosure.

An inventory of where each store and derived artefact is placed. Node settings in the sensitive pool, with swap and core dumps turned off, are verified.

Legacy data counts as Protected C by inheritance until it is reclassified (commitment 5). A core software-as-a-service product is bound by this requirement; NFR-A-009 does not relax it (ADR-009 Part B).

N12, N13

Every class of automated determination is classified, registered and authorised under FR-003 and FR-093. Every adverse determination gives reasons that trace to a rule and a fact. It also carries a recourse notice stating what may be challenged, by when, how, and what happens to payment in the meantime.

The random-sample reconstruction test in TA §C.8.5, run each cycle.

Every determination that harms a person's interests is an administrative decision, and carries a duty to give reasons and a right of recourse (TA §A.7 risk 6).

N07, N08, N17, N20

A context is not captured until four pieces of evidence are complete: its privacy assessment; its security assessment (threat model, review, penetration test and tested incident runbook); its accessibility conformance evidence, including manual testing; and its records disposition classification (TA §E.10 items 7–9).

The gate checklist.

The architecture holds that a definition of done covering privacy but not security fails (TA §E.10).

N12, N15, N18

The ministry's Indigenous relations function confirms which action-plan commitments apply to this system. Each commitment is traced to the registry features that carry it: the participant class, the legal-basis vocabulary, the custodianship attribute and the transfer outcome (FR-084, FR-085).

A traceability review by the Indigenous relations function.

The architecture has not verified which commitments apply, and they must be recorded (TA §B.8.4).

N13

The corporate financial system remains the book of record. Five items are Comptroller and CFO sign-off points, held as configuration under change control: the delegated authority schedule, run approval thresholds, the month-end position, write-off thresholds and the decision to invoke emergency issuance.

A configuration audit and the sign-off records.

Each is a financial control and belongs in governed configuration, not as a constant written into a deployment (TA §C.6.5).

N17

Each outbound channel checks the kind of content it is asked to carry against the limits policy sets, held as versioned data. A notice emailed to a parent, a care provider or an Indigenous governing body is encrypted and password protected. No channel carries proposal package content by email or fax unless the ministry approves that channel. A message about the mental health waitlist keeps identifying and clinical information out of text messages. No monitoring or reading entry can be made for a youth's communication with a privileged person, and any exception to that privacy is documented with notice to the privileged person.

A test sends each restricted kind of content through each channel and shows that the barred combinations are refused and logged, and that the allowed ones carry the protection policy requires.

Policy sets each limit because of the risk to privacy if the content goes astray (OB-IN1-58, R-AD2-21, OB-AD2-24, R-MH3-76, CL-D3-187, CL-D3-190, CL-D3-191). Needed by FR-136, FR-245, FR-367, FR-476 and FR-477. The waitlist and custody parts are conditional on DEP-26 and DEP-28.

N21, N04, N18

Before each context's gate, the ten most common work item types take no longer, and need no more screens or system switches, than the legacy baseline. This is measured with real workers on realistic data. Workers' confidence in the system's answers and the time a new worker takes to become competent are measured and published.

A baseline captured before the context's build begins TA-C12, then acceptance measurement for each office.

A capture that makes a top task slower is a defect. Only a named executive can override this go-live criterion, in writing (TA §E.9).

N15

The system meets WCAG 2.2 Level AA at first release TA-C40. Conformance evidence follows the clause tables of the harmonised ICT standard. Each component has accessibility acceptance criteria in the repository. Each release has an assistive-technology test matrix with manual test evidence. A published conformance ledger for each component covers cross-element ARIA association and the minimum browser version it relies on.

• Keyboard operation for all functions
• Screen reader compatibility, tested manually
• Cross-element ARIA association checked across component boundaries
• Accessible alternative formats for notices (FR-065)
• Accessibility defects accepted as a valid reason for a breaking change

Automated checks in CI act as a gate but catch only about 30% of issues, so funded manual testing is also required.

Provincial policy commits to WCAG AA. An ICT standard is expected, and evidence built this way can be re-filed rather than re-tested when it arrives (TA §C.5.7).

N15

Client-facing content meets a published readability standard and is available in every language the ministry is obliged to use. The Chief Digital Officer, with legal counsel, confirms those obligations and the standard by the end of the foundation module.

Plain language is a fairness control (TA §C.10.4).

N15, N08

The list of supported browsers and assistive technologies is recorded before the first shared interface component is published. Each component records the minimum version its accessibility fixes rely on.

That list decides whether the basic components can use shadow roots at all (TA §C.5.7).

N15

Screens are built from a tiered component library, with rules enforced in CI. Presentational components are owned centrally and make no network calls. Connected components are owned by the domain that owns their contract. Accessibility-critical logic sits in the lower tiers. The provincial design system is used behind a facade.

A component that carries both presentation and a data contract turns into an enterprise data dictionary by the back door (TA §C.5; decision D4).

N03, N15

One instrumentation standard covers components on and off the platform; OpenTelemetry is the candidate. One correlation identifier travels through every hop: browser, experience back end, contract, layer, legacy, outbox, backbone, context, store and exchange. Naming conventions for domain concepts are owned alongside the published language.

Structured logs; RED metrics (rate, errors, duration); distributed tracing that can be joined across both telemetry systems; dashboards for SLOs, queues and reconciliation.

Without this, "where did this determination's evidence come from" and "who was affected" have to be pieced together by hand (TA §C.17).

N18, N06

Each context publishes SLOs for its contract: availability, p95 and p99 latency, and error rate. They are measured at the contract boundary, with error budgets derived from the tier availability figures.

An SLO measured inside a service only describes the service. An SLO measured at the contract describes what the consumer gets (TA §C.17.1).

N16 [PROPOSED], N18

The human reconciliation, adjudication and write-back exception queues publish their depth, the age of the oldest item, arrival and clearance rates, and SLA breaches. Reconciliation and drift metrics also have a threshold and a named recipient. These cover event capture completeness, financial control totals across systems, drift sampling and the decommission burn-down.

A reconciliation queue with no age metric is an unbounded backlog (TA §C.17.1).

N18

For each of N01–N21, the detection mechanism is named. Where it can be expressed as a lint rule, fitness function or schema-registry compatibility check, it runs as one in CI. Manual checks that could be automated are listed with the reason they are not.

A detection register reviewed at each gate, read alongside the volume of findings.

A control that nobody can see being broken is not a control (PRIN N18).

N18

To understand how any business rule works, a person needs to look in one system. Any other copy of the rule is generated from that one, and the generation is shown.

The N04 test applied to a sample of rules at each gate, including the five entitlement-deciding spreadsheets once they are acquired.

Rules live in six places today (RULES §5). Logic spread across layers cannot be understood or changed with confidence.

N04

Tier-1 components (Open Host Service, layer, backbone, determination service, payment chokepoint) have 24×7 on-call cover. Each rotation has at least six people, and escalation clocks are published. The team that builds a component stays on call until a handover gate: tested runbooks and three months of clean operation. Support runs through the ministry service desk and an application support tier. Staff reach engineering only through tier two. Runbooks cover deployment, rollback, restore, fallback modes and incident response.

In every documented failure in the comparison record, the operations model was written during the incident (TA §E.8).

N16 [PROPOSED]

Deployment blackout windows for payment services follow the corporate financial calendar. The child protection reporting line has its own change window and rollback rehearsal.

Amended v1.5 (TA §E.7):

• Month-end blackout. No production change is made to any payment-path component, any determination component or the anti-corruption layer from three business days before the issuance run until reconciliation is signed off. The only exception is one signed by a named executive, and the exception is published TA-C46.
• Freeze periods are published once a year. They cover month-ends, the fiscal year-end and the seasonal peak. An emergency change follows a separate, audited path.

The change record for each blackout and freeze, checked against the published calendar; every exception has its signature.

The financial calendar governs the release calendar, and the programme cannot choose otherwise (TA §C.6.6).

N17

Published contracts use the words of policy and of the ministry's work, whatever product sits behind them. No legacy row identifier, code list or term reaches a published endpoint. The anti-corruption layer is a private, temporary implementation set up to be retired.

The excision test: remove the product and count the contract changes, with a target of zero. Also a demonstrated swap of the implementation with no change for any consumer.

Once a partner stores one legacy identifier, the contract is tied to the platform it was meant to outlive (TA §A.7 risk 5; decision D1).

N10

Contexts exchange only evidence and determinations. They never exchange rows, table projections, internal identifiers or result sets. No context reads another's tables or depends on a type it does not own. A value type joins the shared published language only by a recorded decision.

Payload inspection and dependency analysis in CI.

A shared model tends to come back as a shared schema, not as a shared database (PRIN N03).

N02, N03

Event and API schemas follow a published compatibility policy for each surface, enforced by the schema registry. Consumer-driven contract tests run in CI. Versions, deprecations and retirement dates are published.

Amended 2026-09-30 (drift B10; TA §B.5.4): the policy has three compatibility classes, enforced at publish:

Coded values. A coded-value field in an event schema is either a string validated at the edge against its reference-data master, or an enumeration with a mandatory default symbol (UNKNOWN) to which unrecognised values resolve. A schema registering a closed enumeration without a default is rejected at publish. The closed-enumeration rule binds API contracts and command validation, not event wire schemas. A consumer that resolves a value to UNKNOWN preserves the raw value and routes the record to its exception path where the field is material.

Upcasters are complementary, not an alternative: every upcaster is a versioned artefact exercised by a replay test against archived events in the owning context's pipeline.

The registry rejects a domain-event schema that is not fully transitively compatible, and a closed enumeration without a default. A replay test from origin runs in each owning context's pipeline.

Breaking replay of an old event is a data-loss incident (TA §B.5.4, §D.1). A "backward compatible" change that breaks replay of a five-year-old event is exactly that, which is why domain events carry the stricter class.

N10, N18, N01

Events are delivered at least once through a transactional outbox. Every consumer is idempotent, so a repeated message has no extra effect. Ordering guarantees are stated for each stream.

Amended 2026-09-30 (drift B10; TA §B.5.2, §B.5.3): every consumer of a domain event meets this contract, checked at release:

• The partition key is aggregate_id. The broker orders only within a partition, so per-aggregate ordering needs per-aggregate partitioning. Repartitioning is a breaking change, governed like a schema break: announced, versioned, with a migration path and a sunset period.
• event_id governs deduplication; aggregate_version governs ordering. Apply is idempotent on event_id, through a naturally idempotent write or a processed-id store whose time-to-live is no shorter than the maximum replay window.
• aggregate_version is used for gap detection and bounded buffering, never for rejection. A consumer that sees a version higher than expected buffers up to a bound and waits for the gap to fill. On timeout it escalates to a named recovery path (replay from offset, or a monitored reconciliation queue with a named owner), never to a dead-letter queue.
• Replay epoch. A replay from origin is published under an incremented replay_epoch. A consumer that sees a new epoch rebuilds its projection from empty instead of applying incrementally.
• The relay reads the outbox in commit order (log-based capture, or a sequence assigned at commit). A polling relay over an identity column is not acceptable where events affect entitlement, payment or debt.

Conformance tests at release: duplicate, reordered and gapped deliveries per aggregate; a full replay under a new epoch; concurrent-commit tests of the relay.

At-least-once delivery on a payment path is safe only if idempotency is designed in (TA §C.6.8). Rejecting an out-of-order event discards data the broker will not re-deliver and turns a normal reordering into permanent divergence (TA §B.5.2).

N06, N05, N18

Decision records, evidence and documents are held in formats the ministry owns. The ministry can export them without a vendor's tools, including a transfer package with its offline verifier.

Open, documented formats for each record class, with published schemas.

Replay must still work after every component that produced the decision has been retired (PRIN N08).

N08, N13

The system uses open standards throughout, and prefers open source for generic needs. It buys, adopts or reuses workflow, notification, identity, secrets, policy evaluation, scheduling, document storage, search and print-and-mail. Any decision to build one of these must name the statutory, policy or program requirement that no commodity option meets. Someone other than the component's owner assesses the claim TA-C41. Each selection records the open alternative that was rejected.

Before procurement, custom build is evaluated against commercial and reusable case management platforms for the platform as a whole, and that evaluation is assessed independently.

The platform-level build-or-buy question is the largest open question in the architecture, and leaving it open breaks the architecture's own rules PRIN-C9.

N11

REST for commands, resources and bulk operations. GraphQL for combined reads during transactions, with persisted operations mandatory. Access control, audit, versioning and idempotency are applied the same way at the Open Host Service.

This is the recommendation of decision D2. Shared caching is not possible for responses about individual people (TA §C.1.4).

N10, N02

Added 2026-09-30 (drift B8; ADR-001).

Case delivery is five domain contexts, one per program family: Case: employment assistance · Case: persons with disabilities · Case: child care subsidy · Case: employment services · Case: child protection. Each has its own persistence, topics, published language, lifecycle and owning team. They share protocols, not a case model: each consumes identity events, records evidence through Evidence & Verification, requests determinations from Eligibility & Entitlement (Determination), requests services, instructs Financial Components, raises work in Work Management, and emits correspondence triggers to Notices & Correspondence. No type, table or lifecycle is shared between them. "Case & Service Delivery" names the family only; it is never the owner of a requirement, obligation, aggregate or event. The owner is always one case context, or "all case contexts (shared protocol)" where an obligation is common to all five.

Dependency analysis in CI shows no case context depending on another's types or store. The traceability file names a specific case context, or the shared protocol, on every case-delivery row. Each case context can be released on its own.

A child protection investigation and a child care subsidy renewal share no meaningful state model. A shared case model is the meta-model the predecessor programme could not change; some duplicated case plumbing is far cheaper (TA §B.2.1). Employment assistance and persons-with-disabilities assistance are governed by one policy manual, but they are still two contexts.

NFR-I-002, FR-032, FR-067

N03, N05