Home · Work · System design
Product knowledge and guidanceSynchronous read and explainfederated

Tax-treatment explanation boundary

General tax information becomes customer-specific when allowance use, residency, product history or timing is introduced, and source rules may change during a tax period.

Approach

The service separates statutory facts, bank-held data, customer assertions and scenario assumptions, then provides only the explanation permitted for that combination.

Organisations, systems and operating conditions are intentionally anonymised and recomposed. The design demonstrates engineering and banking-domain reasoning; it does not represent a named client estate, vendor product or measured production result.

Overview

System overview

A shared authority core coordinates independently owned capability cells, domain systems and operating evidence.

Tax-treatment explanation boundary: federated system architecture A federated architecture separates channels, a shared authority core, independently deployed capability cells, domain systems of record, and an evidence and operations rail. Calls use scoped identity and typed contracts; every decision path emits a receipt. aSystem boundary and decision authoritySchematic architecture · illustrative scenario Channels and operatorsFederated capability cellsDomain systemsEvidence, recovery and operations Customer channelweb · mobile · voice Staff workspacereview · approve Service eventbatch · stream · API Operations consoleincident · replay Scope & authority coreidentity · purpose · policy Domain adapter meshversion · health · readback Evidence ContextCompilerContext & evidenceAuthority Rules EngineAuthority & policyEffective-DatedKnowledge HubKnowledge & rulesDecision ReviewWorkbenchHuman decision & operationsDecision Receipt LedgerEvidence & auditParty RelationshipResolveravailable, not admittedJourney StateCoordinatoravailable, not admittedTyped Action Brokeravailable, not admittedProduct masterauthoritative recordlegal termsauthoritative recordratesauthoritative recordeligibility rulesauthoritative record Decision receipt archiveappend-onlyTrace & cost pipelineredacted telemetryRecovery & custody queueowned exceptionsRelease & rollback registrysigned manifest
Figure 1. Independent capability cells share an authority membrane without sharing domain ownership. Source-specific behaviour remains behind adapters and every decision emits operating evidence. This is an illustrative system model, not a named deployment.

Permitted workThe system explains approved information and calculations. Product eligibility, suitability, tax interpretation and legal effect remain separately governed.

Consistency ruleResolve brand, legal entity, product version, jurisdiction and effective date before using a rule or term.

Hard boundaryThe model is not a system of record, identity provider, policy authority or proof that an external effect occurred.

Deployment

Deployment

A customer or service operator needs a grounded answer from live state and controlled knowledge, without a direct business effect.

Tax-treatment explanation boundary: deployment and trust-zone topology A production topology separates public edge, identity boundary, workload cluster, integration plane, data enclave and operating controls. Connections name transport and identity protocols, and a second region provides controlled failover. bDeployment topology and failure domainsLogical deployment · no measured estate data EDGE AND ACCESS PRIVATE WORKLOAD CLUSTER INTEGRATION AND DATA ENCLAVE OPERATIONS, EVIDENCE AND RECOVERY PLANE Web applicationfirewallTLS · bot · rate API ingressschema · quota Identity brokerOIDC · MFA Purpose gateclaims · consent HTTPStokensubject Regional traffic managerhealth · canary · failover Workload identity issuershort-lived service tokens Event & work queuepartition · DLQ · backpressure Secrets & key serviceenvelope encryption · rotation Evidence ContextCompilerzonal workloadAuthority RulesEnginezonal workloadDecision ReceiptLedgerzonal workloadEffective-DatedKnowledge Hubzonal workloadDecision ReviewWorkbenchzonal workloadReserved workloadslotdisabledReserved workloadslotdisabledReserved workloadslotdisabled HTTPS · scoped JWT workload token async eventkey lookup IntegrationgatewaymTLSProduct mastersystem of recordlegal termssystem of recordratessystem of recordeligibility rulessystem of record Model route enclavepolicy · schema · egress Qualified data storesSQL · graph · object Trace, metric & cost pipelineOpenTelemetry · redaction Decision receipt archiveappend-only · retention Reconciliation workersreadback · replay · DLQ On-call & review queuescustody · SLA · escalation Secondary-region standbycompatible manifest telemetryreceiptsexceptions
Figure 2. Workloads remain isolated from systems of record. Short-lived identity, typed integration contracts, append-only evidence and controlled failover define the deployable boundary; the topology is schematic.
Authority checkpoint

The system may calculate from confirmed inputs but cannot infer tax status, guarantee treatment or optimise across products without the required authority.

Runtime

Runtime flow

A deterministic outer workflow contains model-led work inside typed, observable calls. Dashed messages remain proposals until policy or a human grants authority.

Tax-treatment explanation boundary: runtime sequence and control branches Ten lifelines and eighteen protocol messages show authentication, evidence acquisition, policy authority, bounded reasoning, effect verification, human review and append-only evidence. A shaded branch contains timeout and unknown-outcome handling. cRuntime protocol and control pointsProtocol model · illustrative execution Channelcustomer or staffAccess gateidentity & purposeCoordinatorworkflow ownerContextqualified evidenceAuthoritypolicy decisionReasonerbounded inferenceAction brokertyped capabilitySource estateauthoritative stateReview deskhuman decisionReceiptledgerappend-only proof ALT · timeout, rejection, or unknown business effect No blind retry. Resolve source state, narrow the result, or retain custody. Material evidence missing → review queueUnknown effect → readback and reconciliationAuthority denied or expired → stop before dispatch HTTPS · request envelopeOIDC claims · purpose · deadlinetyped evidence requestREST/gRPC reads at qualified timefacts · validity · source versioncontext manifest · exclusionsauthority decision · conditionsminimal residual · closed schemacited proposal · confidence flagsexact capability and payload hashsigned grant · expiry · limitsidempotent command or readaccepted status · effect referenceindependent state readbackaction/effect receiptcase pack when review is requireddisposition · rationale · custodyqualified response · limitations authoritative callproposal / reviewevidence writePattern: Synchronous read and explain
Figure 3. The protocol separates request acceptance, permission, business effect and independent readback. A timeout first changes the knowledge state; it does not automatically justify another call. The paths are protocol semantics, not an observed production trace.
S

State model

Short-lived turn state references an immutable transcript and context manifest. It does not copy source records or create durable customer memory by default.

I

Integration choice

Use direct read APIs for stable same-domain calls. Use a mediated gateway when the call crosses trust boundaries, needs shared throttling, or exposes reusable capabilities.

C

Consistency semantics

Bind all facts to a snapshot or as-of time. A partial source set remains partial; the system never substitutes a plausible zero or stale value.

Services

Services and interfaces

These roles are deliberately vendor-neutral. Each can be independently owned, versioned and replaced.

  1. CAS
    Context and evidence

    Evidence Context Compiler

    Accepts a typed evidence request and returns the minimum permitted facts with source, event time, observation time, validity and exclusions.

    Degraded routeExclude stale or unauthorised fields, ask a bounded question, or stop the route. Never fill a gap with an inferred fact.
  2. PDS
    Authority and policy

    Authority Rules Engine

    Evaluates identity, purpose, capability, amount, risk tier and policy version; returns allow, deny, step-up or human-review with reasons.

    Degraded routeFail closed for effects and restricted data. Read-only explanation may continue only from approved public or customer-visible sources.
  3. CKR
    Knowledge and rules

    Effective-Dated Knowledge Hub

    Serves owned, audience-qualified and effective-dated content; exposes supersession, withdrawal and dependency metadata.

    Degraded routeServe the last approved version only when policy permits; otherwise surface conflict or unavailability to the owner.
  4. HRC
    Human decision and operations

    Decision Review Workbench

    Presents claims beside evidence, alternatives, uncertainty, missing information, permitted actions and current custody.

    Degraded routeRoute to a trained queue with the original sources and open work. The model summary is never the sole evidence available.
  5. DES
    Evidence and audit

    Decision Receipt Ledger

    Appends request, versions, policy result, model proposal, approval, action receipt, readback, correction and custody events under one correlation key.

    Degraded routeBlock a consequential close when mandatory evidence is missing; keep the case open with an explicit evidence defect.
Figure 4. Each service exposes a typed contract and a defined degraded route. Coordination stays in the control plane while domain ownership remains outside it.
Data

Data and records

Durable records carry provenance, authority, effect and custody without turning a transcript into an uncontrolled memory store.

Tax-treatment explanation boundary: state ownership and evidence lineage Authoritative source observations feed six versioned runtime records. Each record names a single write owner. An append-only event and evidence stream builds a disposable current-state projection and supports audit replay. dState lineage, ownership and temporal validityLogical records · fields are illustrative AUTHORITATIVE INPUTS · POINT-IN-TIME QUALIFIEDProduct mastersource version · observed atlegal termssource version · observed atratessource version · observed ateligibility rulessource version · observed atqualified inputqualified inputqualified inputqualified input WRITE OWNER · Evidence Context CompilerRequest enveloperequest_idpurposeactor_refsubject_refversioned · attributable · retainedWRITE OWNER · Authority Rules EngineContext manifestcontext_idsource_refsource_versionobserved_atversioned · attributable · retainedWRITE OWNER · Typed Action BrokerCase statecase_idstatestate_versioncurrent_custodianversioned · attributable · retainedWRITE OWNER · Reasoning Route ManagerAuthority decisiondecision_idpolicy_versionrequested_capabilityoutcomeversioned · attributable · retainedWRITE OWNER · Behaviour Evaluation HarnessAction and effect receiptaction_ididempotency_keyinput_hashdispatch_statusversioned · attributable · retainedWRITE OWNER · Operational Read ModelCustody eventtransfer_idfrom_ownerto_ownerreasonversioned · attributable · retained APPEND-ONLY CASE EVENTS + DECISION RECEIPTSrequest hash · source versions · policy version · proposal · authority · effect readback · custody Operational current-state viewrebuildable projection
Figure 5. The record chain preserves source version, write ownership, authority and custody. Solid records are required in this scenario; dashed records remain compatible but dormant.
Consistency contractDomain source rule

Resolve brand, legal entity, product version, jurisdiction and effective date before using a rule or term.

Choices

Trade-offs

The selected design is not universally superior. It is the safer fit for this boundary and failure cost.

  1. 01

    Prefetch context or acquire it when needed

    Selected path

    Prefetch stable, purpose-safe facts; acquire volatile facts on demand against a time-qualified snapshot.

    Rejected path

    Load a broad customer profile at session start.

    Cost acceptedThe selected design adds source calls and latency, but reduces stale data, excess exposure and accidental reuse.

  2. 02

    Reason over policy text at runtime or compile executable rules

    Selected path

    Compile stable decision logic and retain retrieval for explanation and residual ambiguity.

    Rejected path

    Ask a model to interpret the source document for every request.

    Cost acceptedRule compilation needs controlled change, but creates repeatable decisions, regression tests and clear exceptions.

  3. 03

    Centralise all content or federate ownership behind a shared contract

    Selected path

    Federate authoring while centralising lifecycle metadata, validation and serving rules.

    Rejected path

    Create one centrally authored knowledge corpus.

    Cost acceptedFederation requires stronger contracts and owner discipline, but preserves domain accountability and release velocity.

  4. 04

    Review every case or apply risk-tiered human checkpoints

    Selected path

    Keep people at irreversible, ambiguous and policy-exception points; sample lower-risk automated outcomes independently.

    Rejected path

    Require the same manual approval at every step.

    Cost acceptedRisk-tiering reduces review load but needs calibrated thresholds, sampling and immediate withdrawal of authority when drift appears.

  5. 05

    Mutable current-state record or append-only decision history

    Selected path

    Use append-only events plus a rebuildable current-state projection.

    Rejected path

    Overwrite the case row with its latest status.

    Cost acceptedReplay and storage are more complex, but point-in-time reconstruction and correction lineage remain possible.

Figure 6. Teal marks the selected route; coral dotted rules preserve the rejected alternative. Each decision states the cost accepted rather than presenting one architecture as universally superior.
Recovery

Failures and recovery

Retries are bounded by knowledge of business effect; unknown outcome remains visible, owned and independently reconciled.

Tax-treatment explanation boundary: failure classification and recovery control flow Five failure sources converge on a classifier that distinguishes known no effect, known failure, unknown outcome, material evidence gaps and control-plane failure. Each state has an explicit recovery route, service degradation and evidence receipt. eFailure classification and recovery policyControl model · thresholds set by owners DETECTION POINTSEFFECT CLASSIFIERRECOVERY DECISIONSERVICE-SPECIFIC DEGRADATION Source dependencyMissing external holdings or a…Authority servicePolicy is unavailable, expired, or returns…Reasoning routeOutput fails schema, citation, grounding…Action pathTransport times out after dispatch & the…Evidence railReceipt or custody append fails after a… Outcome classifierattempt · idempotency · source readback ·… Known no effectSafe bounded retry with the same…Known failureNarrow, queue, compensate, or fail closed…Unknown outcomeRead back authoritative state before retry…Material evidence gapRetain custody & create an owned…Control-plane failureStop promotion or dispatch; restore the…Evidence Context CompilerExclude stale or unauthorisedfields, ask a bounded question, orstop the route. Never fill a gap…Authority Rules EngineFail closed for effects &restricted data. Read-onlyexplanation may continue only from…Effective-Dated Knowledge HubServe the last approved versiononly when policy permits;otherwise surface conflict or…Decision Review WorkbenchRoute to a trained queue with theoriginal sources & open work. Themodel summary is never the sole…Decision Receipt LedgerBlock a consequential close whenmandatory evidence is missing;keep the case open with an… RECOVERY RECEIPTfault origin · classification basis · owner · retry/compensation key · readback reference · residual risk · resolved at classifier evidencerecovery evidence Pattern rule: A failed optionalread narrows the answer. A failedmaterial read stops the claim &…
Figure 7. Recovery follows the known business-effect state, not the transport symptom. Every branch ends in a receipt preserving fault origin, custody and reconciliation basis.
Capacity

Performance and capacity

Actual thresholds belong to accountable service owners. The design exposes the equations and observables that those owners must baseline.

Dependent variablesOperating
envelope
  • End-to-end and per-source latency
  • source freshness and conflict rate
  • citation entailment
  • data exposure per resolved turn
Capacity relationships
  1. 01peak_read_qps = concurrent_sessions x turns_per_minute x source_fanout / 60
  2. 02p95_turn_latency = max(required_source_reads) + policy + model + validation
  3. 03context_cost = admitted_input_tokens x routed_turns
Privacy lens

Use customer holdings only when necessary for the current explanation and keep external or assumed circumstances visibly separate.

Figure 8. The variables define what must be measured before capacity or quality claims can be accepted. Relationships are analytical scaffolds, not invented targets or production results.
Operations

Release and operations

A design is production-ready only when teams can prove what happened, recover it and change it safely.

Minimum release gates
  1. 01

    product and rule applicability

  2. 02

    guidance-versus-advice boundary

  3. 03

    superseded-content withdrawal

  4. 04

    calculation and citation verification

Figure 9. Promotion requires evidence at each gate and a compatible rollback route. No gate is implied to have passed; accountable owners set thresholds and sign the record.
Operating stateReleaseRecover
Evidence

Jurisdiction and period, admitted facts, missing external data, rule version, calculation trace, caveats and route decision.

Human authority

A qualified specialist handles interpretation or recommendation beyond general information.

Evolution

Begin with one read-only journey and explicit fallbacks. Add personalisation only after freshness, source precedence and context-minimisation evidence hold.

Ownership

Product, conduct, legal, tax, knowledge and advisory owners define the permitted answer boundary.

Figure 10. Evidence, human authority, ownership and controlled evolution remain coupled throughout operation. Removing any quadrant breaks the assurance case.