Components

What it is for

The software caseworkers use every day. There are five case contexts, one for each program family: employment assistance, persons with disabilities, child care subsidy, employment services and child protection. Each keeps its own case record and its own lifecycle, from taking an application to scheduling reviews.

How it fits the whole

The five share ways of working, not a case model. Each records evidence through Evidence & Verification, asks Eligibility & Entitlement for decisions, raises work in Work Management and instructs payments through Financial Components. None of them holds payments, overpayments or reconsideration. Those are contexts of their own, described below. A case management product fills one case context. The same product can be used for more than one, but each use keeps its own data. Parameter N11 sets the rule for the rest: buy, adopt or reuse common tools, and build only where no ready-made product meets a legal, policy or programme need.

What any product must do

• Takes applications in stages and keeps a complete case record, so work can carry on when a case changes hands. FR-025FR-032
• Schedules reviews, recertifications and follow-up of missed appointments. FR-024
• Five case contexts share protocols, not a case model. NFR-I-008
• Does not make workers’ tasks slower than they are today. NFR-U-001

What it is for

Issues every payment through one controlled path: issuance runs, direct deposit, cheque and electronic transfer, stop payment, reissue, returned items and the month-end cutoff. It reconciles with the corporate financial system.

How it fits the whole

It takes payment instructions from Financial Components and turns them into disbursements. It decides no entitlement. An entitlement decided twice must not be paid twice, and that guarantee lives here, once, rather than in five case contexts.

What any product must do

• Issues every payment through one issuance service. FR-042
• Runs issuance, with stop, recall, reissue and returns as separate operations. FR-043FR-044
• Works with the corporate accounting system and the banks. INT-001INT-002

What it is for

Keeps the benefit ledger: accounts, accruals, payment schedules and double-entry postings. It creates, cancels and replaces payment instructions. It also holds money paid out now that may have to be repaid, such as interim assistance while a decision is being challenged.

How it fits the whole

It turns financial decisions into the postings that Payments & Benefit Issuance carries out. It is kept apart from issuance because a ledger and a payment run fail in different ways and are audited in different ways. It decides no entitlement.

What any product must do

• Keeps a benefit ledger that reconciles three ways. FR-045
• Holds money paid out now that may have to be repaid, until the awaited decision settles it. FR-041
• Applies deductions and set-off, and protects the minimum a client must keep. FR-048
• Separates working out, approving and releasing a payment, in code. FR-046

What it is for

Raises overpayments, tells the client, and manages repayment agreements, deductions, set-off, write-off and referral to collections.

How it fits the whole

An overpayment always comes from recalculating a past period, and it always carries a classification. The rule that classifies it reads the evidence operation behind the recalculation. A supersession reported late gives a recoverable overpayment. A correction is classified by whose error it was. That rule is a versioned policy artefact, not code inside a case context.

What any product must do

• Calculates and classifies overpayments from the evidence that changed. FR-051
• A person decides every debt. FR-052
• Handles repayment, write-off, collections and disputes. FR-053INT-019

What it is for

Records every reconsideration request, runs the legal time limits, builds the record for reconsideration and appeal, and deals with the tribunal as an outside party.

How it fits the whole

It is built once, not once per program. Whether reconsideration is available is decided by the independent reconsideration unit and recorded as evidence, which this context reads but never writes. A decision put right on appeal becomes a new decision, never a manual adjustment. Interim assistance is instructed from here and held in Financial Components.

What any product must do

• Accepts and records every reconsideration request. FR-055
• Reads, and never makes, the decision on whether reconsideration is available. FR-056
• Builds the record for reconsideration and appeal from the decision record. FR-058
• Treats the tribunal as an outside party, and puts decisions right without manual steps. FR-059FR-060

What it is for

The one place client consent is kept: what was consented to, for how long, and when it was withdrawn. It records every disclosure, and a person’s request to correct their information, with its time limit.

How it fits the whole

Other contexts check consent here rather than keeping their own. The correction itself is made by the context that owns the fact. Agreements between organisations are a different thing: they sit in the agreement registry in Secure Data Exchange.

What any product must do

• Records consents with their scope, time limit and withdrawal. FR-075
• Discloses only with a recorded legal basis. FR-077
• Handles requests for correction, and the annotations that follow. FR-079

What it is for

Works out eligibility and entitlement from the facts, using the rules in force on the relevant dates. It also lets policy staff write, test and release those rules.

How it fits the whole

It sits inside Eligibility & Entitlement. The decision service around it gathers the facts first and passes the engine a snapshot of them. The engine reads nothing else while it runs, and returns determinations with their reasons. The case contexts and workflow ask for decisions, and hold no eligibility rules of their own. Architecture decision D3 covers whether to build or buy the authoring and release tooling.

What any product must do

• Policy staff write rules as versioned artefacts with effective dates. FR-090
• Runs inside the decision service, against a snapshot of the facts passed to it, and reads nothing else while it runs. FR-001
• Each rule carries the policy it comes from and the date that policy took effect. FR-090
• Works out effective dates by rule, for each part of a benefit. FR-005
• Runs several generations of rules side by side. FR-010
• Gives reasons that name the rule applied and the fact behind it. FR-002
• Replays any past decision from stored records. FR-008
• Blocks a release when rules have conflicting dates. FR-091
• Keeps each rule in one authoritative place. NFR-M-005

What it is for

Moves work between people and systems: work items, queues, due dates set by legal time limits, and escalation. It also runs long processes, such as payment runs, that must survive failures and pick up where they stopped.

How it fits the whole

It serves Work Management, one context that all five case contexts use. It moves the work and asks for decisions, but makes no decisions itself. Its due dates come from the register of legal time limits.

What any product must do

• Takes its due dates from one register of legal time limits. FR-061
• Manages work items and queues, with due dates. FR-067
• Supports supervision, escalation and overdue work. FR-068
• Balances caseloads, with a supervisor deciding. FR-069
• Schedules reviews, recertifications and follow-up of missed appointments. FR-024
• Retries safely, and every dependency has a timeout and a fallback. NFR-I-004NFR-A-003

What it is for

Evidence & Verification keeps every fact as an append-only stream of events, with its three dates. The backbone carries events between contexts, and the schema registry checks each one against its registered schema.

How it fits the whole

The backbone carries events. It is not where facts are kept. Facts are held by Evidence & Verification in its own event store, and other contexts read them through its published interface or keep copies built from its events. Four habits make this an architecture rather than a message bus. Every kind of event has a registered schema and one owning context. Each service saves its change and its event together, in one step. Work that crosses contexts is undone step by step if it fails, rather than locked across systems. And tampering shows, so the streams can serve as the audit trail. Architecture decision D9 sets the direction for the event broker and its support model.

What any product must do

• Keeps each fact as a stream of versions, and works out its current state from them. DR-020
• Records the four states of a fact, and corrections, without overwriting. FR-011FR-012
• Fixes three dates on every fact before the first event. DR-001
• Lets only evidence and determinations cross between contexts. NFR-I-002
• Checks schema compatibility, and tests contracts. NFR-I-003
• Shows if any record has been tampered with. NFR-SEC-009
• Holds decades of data within stated limits on consumer lag. NFR-S-002NFR-P-005

What it is for

Finds records that refer to the same person, so Participant Identity can join them. Uncertain matches go to a person to decide. Joining two records, or separating two that were wrongly joined, is recorded as an event that every other context follows.

How it fits the whole

It sits inside Participant Identity, which the ministry builds and keeps small: identifiers, enough detail to match on, and proof-of-identity status. Addresses, income and relationships are evidence, held elsewhere. Every other context refers to a client by the participant identifier. Proof of identity comes from the provincial identity services, not from this component. A matching library does the matching; it does not keep a master copy of each person.

What any product must do

• Joins and separates client records, with people deciding uncertain matches, and records each join or separation as an event. FR-028
• Supports establishing and proving identity. FR-027INT-005
• Reads identity data when it is needed, rather than storing copies. DR-019

What it is for

Builds notices from the decision record, delivers them and records proof of service. It also captures documents from every channel and handles signatures and attestations.

How it fits the whole

It serves two contexts, Documents & Capture and Notices & Correspondence. Notices take their content from determinations and the rules that produced them, so a notice always matches its decision. A captured document supports evidence. It is never a decision.

What any product must do

• Builds notices from the decision record, with the required rights wording. FR-062FR-063
• Records delivery, proof of service and deemed receipt. FR-064
• Produces notices in other languages, in plain language and in accessible formats. FR-065
• Captures documents from every channel, classifies them and scans them for malware. FR-071FR-072
• Treats values read by machine as unverified evidence. FR-073
• Handles signatures and attestations, and severs information within sentences. FR-074FR-078
• Hands mail to the provincial print-and-mail service. INT-003