Home · Work · System design
Platform lifecycle and deliveryPlatform lifecycle and release controlevent spine

Capability-contract onboarding

A new system action may appear technically callable while its authority, side effects, retry behaviour, data handling and evidence obligations remain undefined.

Approach

An onboarding service converts the capability into a typed contract covering inputs, scopes, preconditions, effects, failure states, idempotency, readback and accountable ownership before any agent can discover it.

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

Typed commands, state changes and receipts cross an event spine without surrendering domain ownership.

Capability-contract onboarding: event-spine architecture Twelve independently owned platform services connect through a typed event and evidence spine. The design separates request admission, event ordering, capability execution, systems of record, dead-letter recovery, and an immutable receipt archive. aSystem boundary and decision authoritySchematic architecture · illustrative scenario Request and event admissionCommand-side servicesAuthoritative systemsOperations rail Channel & case eventsHTTPS · batch · streamSchema & identity gateOIDC · event versionPartition & ordering serviceentity key · watermarkBackpressure gatequota · pause envelopeadmittedlag signal Evidence ContextCompilerContext & evidenceParty RelationshipResolverIdentity & relationshipsAuthority Rules EngineAuthority & policyJourney StateCoordinatorWorkflow & custodyTyped Action BrokerIntegration & effectsDecision ReceiptLedgerEvidence & auditReasoning RouteManagerModel executionEffective-DatedKnowledge HubKnowledge & rulesBehaviour EvaluationHarnessEvaluation & releaseOutcome RecoverySupervisorResilience & recoveryOperational Read ModelWorld state & read modelsDecision ReviewWorkbenchHuman decision & operationspublishpublishpublishpublishpublishpublishconsumeconsumeconsumeconsumeconsumeconsume EVENT + STATE SPINErequest.accepted · context.qualified · authority.decided · action.dispatched · effect.readback · custody.changed Source controlsource of recordbuild pipelinesource of recordartefact registrysource of recordpolicy storesource of record Dead-letter & replay queueDecision receipt archiveTrace, lag & cost telemetryIncident & custody queue
Figure 1. Typed events coordinate independently owned services without turning the event spine into a system of record. Ordering, backpressure, readback and replay stay explicit. This is an illustrative system model, not a named deployment.

Permitted workThe delivery platform automates evidence and enforces gates. Named owners approve risk, exceptions and production authority.

Consistency rulePromote signed, immutable manifests and keep runtime registry, deployed artefact and evidence pack on the same version.

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

Deployment

Deployment

Agents, prompts, tools, policies and models must be built, certified, operated, changed and retired as one reachable system.

Capability-contract onboarding: 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 Authority RulesEnginezonal workloadTyped ActionBrokerzonal workloadDecision ReceiptLedgerzonal workloadBehaviourEvaluation…zonal workloadReserved workloadslotdisabledReserved workloadslotdisabledReserved workloadslotdisabledReserved workloadslotdisabled HTTPS · scoped JWT workload token async eventkey lookup IntegrationgatewaymTLSSource controlsystem of recordbuild pipelinesystem of recordartefact registrysystem of recordpolicy storesystem 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

Discovery and invocation remain disabled until the contract passes security, operational, risk and owner approval gates.

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.

Capability-contract onboarding: build, release and retirement lifecycle A controlled lifecycle links registration, design, implementation, evaluation, approval, canary release, operation and retirement. A signed manifest binds dependencies and evidence; failed gates and operating drift return to an owned change route. cRuntime protocol and control pointsProtocol model · illustrative execution Build and releaseOperate, change and retireManifest, evidence and recovery Signed system manifestowner · code · model · knowledge · tools ·… Registerowner · purpose · data boundaryDesigntopology · authority · contractsBuildcode · prompts · rules ·…Evaluatefunction · failure · harm · NFRApprovesigned manifest · evidenceCanarylimited traffic · rollback…Operatebehaviour · cost · incidentsRetirerevoke · archive · prove closure Evaluation evidenceroute · failure · compatibilityRelease registrysignature · canary · rollbackOperating evidencetrace · cost · outcomeIncident & change queueowner · severity · deadlineArchivewithdrawal proof Gate rule: Automate evidence collection before automating approval. Expand self-service only when the paved route proves safer and faster than bespoke delivery.
Figure 3. Design, evaluation, release, operation and retirement remain bound to one signed manifest. A failed gate or operating incident returns to an owned change route. The paths are protocol semantics, not an observed production trace.
S

State model

A signed system manifest links code, prompt, model, knowledge, tools, permissions, policies, tests and owner. Any material dependency change creates a new release candidate.

I

Integration choice

Build and runtime boundaries use the same schemas. Registry metadata drives discovery, policy, telemetry attribution and deprecation.

C

Consistency semantics

The deployed artefact, registry entry and evidence pack share one immutable release identifier; partial promotion is not a valid state.

Services

Services and interfaces

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

  1. 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.
  2. CAG
    Integration and effects

    Typed Action Broker

    Exposes typed, allow-listed capabilities with schema validation, delegated identity, idempotency, timeout semantics and effect readback.

    Degraded routeDisable the affected capability, preserve the prepared action and transfer it to an authorised manual route.
  3. 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.
  4. SEL
    Evaluation and release

    Behaviour Evaluation Harness

    Runs component, route, trajectory, failure, harm and outcome tests against the versioned system manifest.

    Degraded routeReduce or withdraw authority when a dependency changes or a critical suite fails; preserve the last approved route where compatible.
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.

Capability-contract onboarding: 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 QUALIFIEDSource controlsource version · observed atbuild pipelinesource version · observed atartefact registrysource version · observed atpolicy storesource 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

Promote signed, immutable manifests and keep runtime registry, deployed artefact and evidence pack on the same version.

Choices

Trade-offs

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

  1. 01

    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.

  2. 02

    Call a source API directly or mediate through a shared capability boundary

    Selected path

    Use direct calls for narrow same-domain reads; mediate cross-domain, reusable or mutating capabilities.

    Rejected path

    Force every call through one integration pattern.

    Cost acceptedMediation adds a hop and ownership overhead; direct calls increase coupling and duplicate controls.

  3. 03

    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.

  4. 04

    Evaluate model responses alone or certify the complete reachable system

    Selected path

    Test prompts, models, tools, knowledge, policies, state transitions and human paths together.

    Rejected path

    Use a static answer-quality benchmark as the release gate.

    Cost acceptedSystem evaluation takes longer and needs synthetic environments, but detects authority and recovery failures that answer scoring misses.

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.

Capability-contract onboarding: 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 dependencyA technically successful call can create…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…Authority Rules EngineFail closed for effects &restricted data. Read-onlyexplanation may continue only from…Typed Action BrokerDisable the affected capability,preserve the prepared action &transfer it to an authorised…Decision Receipt LedgerBlock a consequential close whenmandatory evidence is missing;keep the case open with an…Behaviour Evaluation HarnessReduce or withdraw authority whena dependency changes or a criticalsuite fails; preserve the last… RECOVERY RECEIPTfault origin · classification basis · owner · retry/compensation key · readback reference · residual risk · resolved at classifier evidencerecovery evidence Pattern rule: Canary, kill switch& rollback restore the lastcompatible manifest…
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
  • deployment lead time
  • critical test coverage
  • rollback time
  • cost and trace attribution
Capacity relationships
  1. 01gate_runtime = test_cases x routes x dependency_versions
  2. 02release_capacity = available_environments / average_gate_duration
  3. 03operating_cost = model + tools + platform + human_review + incidents
Privacy lens

Keep production data and secrets out of build evidence; use synthetic, masked or approved test sources with retained provenance.

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

    scope and owner completeness

  2. 02

    functional, safety and adversarial suites

  3. 03

    NFR and recovery evidence

  4. 04

    canary, rollback and retirement proof

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

Capability manifest, schema tests, threat assessment, failure injects, approval record, issued scopes and activation receipt.

Human authority

The system owner, control owner and operations owner jointly approve activation.

Evolution

Automate evidence collection before automating approval. Expand self-service only when the paved route proves safer and faster than bespoke delivery.

Ownership

Engineering, architecture, security, risk, operations and domain product owners sign the release envelope.

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