KF-3003 · Service Architecture

The Logical Services Through Which Capabilities Are Exposed and Governed

Reference Architecture · Draft · v0.2 · 29 min read

Reference Architecture (KF-3000)
        ↓
Architectural Rules (KF-3001)
        ↓
Capability Model (KF-3002)
        ↓
▸ Service Architecture (KF-3003)
        ↓
Information & Record Model (KF-3004)
        ↓
Lifecycle & Control (KF-3005)
        ↓
Implementation (KF-4000)

Purpose

KF-3002 defines what a governed knowledge architecture must be able to do. KF-3003 defines through which logical services those abilities are exposed, coordinated and governed — the execution architecture of the Knowledge Foundry.

KF-3003 introduces no new obligations. It does not weaken an invariant, relax an interaction constraint, or select a technology. Its single question is:

Through which logical services are the capabilities exposed, coordinated and governed, without violating any interaction constraint?

A logical service is a stable responsibility exposed to authorised actors and other services through defined operations, information objects and controls. A service may later be realised by software, assigned human work, or a governed combination of both; KF-3003 fixes the responsibility, not the realisation.

Relationship to Upstream Documents

KF-3003 is bounded on three sides and may not exceed any of them.

• From KF-3002, it inherits the twenty-four capabilities and their typed relationships. Every service realises one or more capabilities; no service exists without a capability basis.
• From KF-3001, it inherits the twenty-two interaction constraints. Every constraint must be enforced at a defined service boundary; a service architecture that cannot enforce a constraint is non-conforming.
• From KF-3000, it inherits the intent of the service catalogue. KF-3000 sketched a provisional service list and explicitly deferred the definitive catalogue to KF-3003. This document establishes that definitive catalogue — nineteen logical services — and where it refines KF-3000’s provisional numbering, KF-3003 is authoritative and KF-3000’s §11–12 list and §22–24 crosswalks are read as pointing here.

The direction of authority is strict: a service may choose how to expose a capability, but may never add to, weaken, or reinterpret the capability, invariant or constraint it inherits.

The Distinctive Property — Interaction Governance

A service architecture is not merely a decomposition of capabilities into components. Its distinctive and load-bearing property is interaction governance: it must guarantee that the interaction constraints IC-01–IC-22 hold in execution, not only on paper.

Decomposition alone can satisfy every capability individually while allowing services to bypass one another — a version service that also releases, an application service that also accepts, an assurance service that authorises the transitions it audits. KF-3003 exists to make those bypasses structurally impossible by assigning each constraint to a boundary and each governed record to a single authoritative maintainer. Part VII is therefore the centre of this document, not an appendix to it.

Service Admission Test

A proposed logical service is admitted only where:

1. it realises one or more KF-3002 capabilities;
2. every capability it realises names it as the single accountable service, or names another service and this one as a supporting collaborator;
3. it is the authoritative maintainer of a defined, non-overlapping set of information objects;
4. its operations can be stated without naming a technology or product;
5. it enforces, or participates in enforcing, at least one interaction constraint, or is required by a capability that does;
6. it acquires no authority beyond the capabilities it realises;
7. its conformance can be demonstrated independently.

Design Principles for Service Definition

• SP-1 · Capability-derived services. Every service is justified by the capabilities it realises; none is admitted because a technology category suggests it.
• SP-2 · Single accountable service. Each capability has exactly one accountable service; other services may support it, but accountability is not shared.
• SP-3 · Authoritative information ownership. Each governed information object has exactly one authoritative-maintainer service; other services read it or request changes through a governed interaction.
• SP-4 · Constraint enforcement at a boundary. Every KF-3001 interaction constraint is enforced at a named service boundary, not left to convention.
• SP-5 · No authority accrual. Execution capacity confers no authority. A service that performs an operation does not thereby gain the right to authorise it.
• SP-6 · Coherent coarseness. Capabilities are grouped into one service only where they share information ownership and lifecycle role. Distinct governance obligations remain distinct services even where a single component might implement them. Version, acceptance and release are therefore three services, not one.
• SP-7 · Logical, not physical. Services are logical responsibilities. One may be distributed across components and several combined into one, provided their boundaries and authoritative ownership remain inspectable.
• SP-8 · Assurance independence. The conformance service is read-only with respect to the records it assesses and is never an operational prerequisite of the operations it audits.

Service Specification

Each service is specified through ten fields: Service statement, Purpose, Realised capabilities, Authoritative information objects, Service operations, Collaborations (typed: prerequisite, collaborating, constraining, evidence), Enforced interaction constraints, Authority boundary (what the service must not do), Operating criticality, and Conformance condition.

Part I · Service Taxonomy

1. The Logical Services

KF-3003 defines nineteen logical services, numbered sequentially and grouped by domain. Cross-cutting services are grouped together at the end of the sequence.

Every one of the twenty-four capabilities names exactly one accountable service (§5). The five Domain E services are cross-cutting: Provenance, Access, Operating Condition and Temporal Continuity constrain or supply evidence to the others, and Conformance reads all of them without altering any.

Version, acceptance and release are three services. Version creation (SVC-09) is not acceptance (SVC-06) and neither is release (SVC-10). This three-way separation is the structural expression of IC-06, IC-08 and IC-09, and is the principal refinement of this document over the KF-3000 sketch.

Part II · Domain A Services

SVC-01 · Object Registry Service

Service statement. Assigns and resolves durable object identity and routes intake to the responsible downstream service.

Purpose. Establish identity as the single anchor of governance, distinct from version, representation and record identity.

Realised capabilities. Accountable for A-CAP-01, A-CAP-03. Supports A-CAP-02.

Authoritative information objects. Object Identity Record; Intake Record; Identity Resolution Decision; Resolution Result.

Service operations. Register candidate; assign immutable identifier; resolve identifier to one object; assess intake relation to existing objects; retrieve current and historical governed context; expose unresolved identity conditions.

Collaborations. Constrained by: SVC-16, SVC-17. Evidence from: SVC-15. Triggers: SVC-09 (version or lineage creation). Collaborates with: SVC-02, SVC-05, SVC-08 (context for resolution).

Enforced interaction constraints. IC-05 (Identity Immutability).

Authority boundary. Does not create versions, branches or consolidated successors; does not accept, release or retire; does not alter representation content.

Operating criticality. Governance-critical; fail-closed — no progression without a resolved, unique identity.

Conformance condition. Any registered object resolves to exactly one identity with recoverable origin and intake decision, and no identifier is reused.

SVC-02 · Representation Service

Service statement. Creates and maintains the inspectable representation of an object’s content, type and relationships.

Purpose. Make objects inspectable so that evaluation, justification, governance and explanation can operate on explicit structure.

Realised capabilities. Accountable for A-CAP-02. Supports A-CAP-03.

Authoritative information objects. Structured Representation; Semantic Type Record; Metadata Record; Object Relationship Record; Representation Limitation Record.

Service operations. Assign semantic type; represent constituent elements and relationships; attach metadata; link representation to object version; declare modality limitations.

Collaborations. Prerequisite: SVC-01. Constrained by: SVC-16. Evidence from: SVC-15.

Enforced interaction constraints. Participates in INV-02, INV-03 preservation; no primary IC boundary.

Authority boundary. Does not evaluate, justify or accept; does not assign identity; does not conflate content with warrant.

Operating criticality. Governance-critical — inspectability precedes all downstream governance.

Conformance condition. For any representation, a reviewer can determine what it expresses, which object version it represents, how its elements relate and what modality limitations apply.

Part III · Domain B Services

SVC-03 · Evidence Service

Service statement. Registers evidence and counter-evidence as governed records related to claims and objects.

Purpose. Make evidential support, challenge and origin independently inspectable, distinct from the conclusions drawn from them.

Realised capabilities. Accountable for B-CAP-01.

Authoritative information objects. Evidence RecordEvidence record — the durable record that a material obligation or decision was discharged; wherever possible emitted by the governed act itself (KF-3004 §5.2). Vocabulary →; Counter-Evidence Record; Evidence-to-Claim Link; Evidence Classification; Evidence Availability Status.

Service operations. Register evidence; classify support, challenge or context; relate evidence to claims and objects; record availability; retain conflicting evidence.

Collaborations. Prerequisite: SVC-01, SVC-02. Constrained by: SVC-16. Evidence from: SVC-15.

Enforced interaction constraints. Participates in IC-20 (provenance of evidence).

Authority boundary. Does not evaluate quality, construct justification or determine acceptance; does not delete counter-evidence.

Operating criticality. Governance-critical — warrant depends on inspectable evidence.

Conformance condition. For each material claim, the related evidence and counter-evidence, their origins, roles and availability are recoverable.

SVC-04 · Evaluation Service

Service statement. Assesses quality and fitness against explicit criteria and records the verdict.

Purpose. Determine whether an object is suitable to proceed toward justification, distinct from establishing why it may be believed.

Realised capabilities. Accountable for B-CAP-02.

Authoritative information objects. Evaluation Criteria Record; Quality Assessment; Evaluation Verdict; Evaluation Exception; Confidence Record.

Service operations. Apply criteria; assess quality, consistency, completeness and confidence; record pass, fail, return, pending or indeterminate; retain reasons; route incomplete assessments.

Collaborations. Prerequisite: SVC-02, SVC-03. Constrained by: SVC-17. Evidence to: SVC-18.

Enforced interaction constraints. Participates in INV-24 (no silent pass).

Authority boundary. Does not construct justification or accept; does not define organisational thresholds.

Operating criticality. Governance-critical — the quality gate precedes justification.

Conformance condition. For any evaluation, the criteria, inputs, evaluator, result, confidence, reasons and disposition are recoverable.

SVC-05 · Justification Service

Service statement. Assembles and exposes inspectable warrant, and maintains epistemic status distinct from acceptance.

Purpose. Establish why an object may be believed, and preserve uncertainty and dispute even where reliance is later permitted.

Realised capabilities. Accountable for B-CAP-03, B-CAP-04.

Authoritative information objects. Justification Record; Assumption Record; Rationale Record; Traceability Chain; Challenge Record; Epistemic Status Record; Confidence Record; Contestation Record; Epistemic Status Change Record.

Service operations. Relate claims to evidence and counter-evidence; record assumptions and rationale; construct traceability; represent epistemic status; preserve prior epistemic states; expose warrant for independent inspection.

Collaborations. Prerequisite: SVC-03, SVC-04. Collaborating: SVC-06 (justification–acceptance boundary). Constrained by: SVC-16. Evidence from: SVC-15.

Enforced interaction constraints. IC-09 (Justification–Acceptance Separation), enforced jointly with SVC-06.

Authority boundary. Does not accept, release or apply; does not let acceptance overwrite epistemic status; does not claim justification guarantees truth.

Operating criticality. Governance-critical — justification is the warrant on which reliance rests.

Conformance condition. An independent reviewer can reconstruct the reasons for and against belief, the assumptions, and the object’s epistemic standing separately from its acceptance state.

Part IV · Domain C Services

SVC-06 · Authority and Acceptance Service

Service statement. Records the governed decision by which an identified authority permits reliance upon a justified object.

Purpose. Separate epistemic warrant from institutional permission to rely.

Realised capabilities. Accountable for C-CAP-01.

Authoritative information objects. Acceptance Record; Refusal Record; Scope-of-Reliance Record; Authority Assignment Reference; Acceptance Condition Record.

Service operations. Identify accepting authority; verify mandate, scope and effective period; record acceptance, provisional acceptance or refusal; define reliance scope and conditions; route refusals.

Collaborations. Prerequisite: SVC-05, SVC-16. Collaborating: SVC-08. Triggers: SVC-10 (release), SVC-08 (transition). Evidence from: SVC-15.

Enforced interaction constraints. IC-09 (with SVC-05); IC-13 (Authority Is Not Permission); IC-16 (Automated Authority Boundary).

Authority boundary. Does not construct justification; does not create or release versions itself; does not assign permissions (that is SVC-16); does not become the final accountable authority where a human authority is required.

Operating criticality. Governance-critical; fail-closed — no acceptance without an applicable authority.

Conformance condition. Every accepted object carries a decision attributable to an authority whose mandate, scope and effective period applied, with reliance scope, conditions, date and supporting justification.

SVC-07 · Stewardship and Review Service

Service statement. Maintains ownership and accountability and determines whether standing governance conditions remain satisfied.

Purpose. Preserve sustained human accountability and legitimacy across operational life.

Realised capabilities. Accountable for C-CAP-02, C-CAP-03.

Authoritative information objects. Stewardship Assignment; Responsibility Record; Stewardship History; Accountable Body Record; Review Schedule; Review Record; Compliance Assessment; Compliance Finding; Governance Exception.

Service operations. Assign and transfer stewardship; schedule and record reviews; detect overdue reviews; evaluate compliance; raise triggers for suspension, evolution or retirement.

Collaborations. Prerequisite: SVC-01. Collaborating: SVC-08. Constrained by: SVC-16, SVC-17. Triggers: SVC-08, SVC-09. Evidence from: SVC-15; Evidence to: SVC-18.

Enforced interaction constraints. Participates in INV-10 (standing governance) upkeep; raises IC-03 suspension triggers.

Authority boundary. Does not accept or release; does not execute the transitions it triggers (that is SVC-08); does not assign access permissions.

Operating criticality. Governance-critical; recoverable within a defined period — a late review is bounded and must be visible as overdue.

Conformance condition. Every operational object has a recoverable steward, review status and compliance standing, and no operational object is ownerless.

SVC-08 · Lifecycle and Transition Service

Service statement. Registers lifecycle events, evaluates gates and executes attributable state transitions as one governed operation.

Purpose. Preserve controlled movement between lifecycle states and hold the sole right to change recorded state.

Realised capabilities. Accountable for C-CAP-08.

Authoritative information objects. Event Record; Gate Decision Record; Transition Record; Transition Warrant; Transition Status.

Service operations. Register events; identify applicable gate; evaluate eligibility; bind gate decision and transition transactionally; attribute execution and authority separately; execute forward, return, suspension and retirement transitions.

Collaborations. Collaborating: SVC-06, SVC-07, SVC-09, SVC-10, SVC-11, SVC-14. Constrained by: SVC-16, SVC-17. Evidence from: SVC-15, SVC-19; Evidence to: SVC-18.

Enforced interaction constraints. IC-01 (Lifecycle State Authority); IC-02 (Gate Enforcement); IC-03 (Suspension Ownership).

Authority boundary. Does not make the acceptance decision (that is SVC-06); does not define gate criteria (that is KF-3005); does not disposition dependencies (that is SVC-11). Only SVC-08 may alter recorded lifecycle state.

Operating criticality. Governance-critical; fail-closed — an indeterminate or unavailable gate does not silently pass.

Conformance condition. For every transition, the event, prior and proposed state, gate result, executor, accountable authority and outcome are recoverable under one transition identifier.

SVC-09 · Version and Lineage Service

Service statement. Creates immutable versions and preserves lineage across change, without altering enduring identity and without releasing anything.

Purpose. Preserve every state of content and warrant as an immutable, recoverable version, and preserve predecessor–successor lineage — kept strictly distinct from acceptance and release.

Realised capabilities. Accountable for C-CAP-04 (version), C-CAP-06 (evolution and lineage).

Authoritative information objects. Version Record; Version State; Predecessor–Successor Link; Correction Record; Change Record; Lineage Record; Branch Record; Consolidation Record; Reactivation Proposal.

Service operations. Create candidate and governed versions; preserve prior versions; prevent overwrite; identify predecessor and successor versions; branch, consolidate and supersede with explicit lineage; preserve correction history; route changed states for renewed warrant.

Collaborations. Prerequisite: SVC-01, SVC-02. Collaborating: SVC-08, SVC-11. Constrained by: SVC-16. Evidence from: SVC-15; Evidence with: SVC-19.

Enforced interaction constraints. IC-06 (Version Immutability); IC-07 (Branch and Consolidation Identity); IC-21 (Append-Only Correction, with SVC-19).

Authority boundary. Does not accept, release or apply; does not create or mutate identity; version creation never implies release. A new version is never automatically released.

Operating criticality. Governance-critical; fail-closed — no overwrite of a prior version.

Conformance condition. For any object, its immutable versions, their order, correction and supersession relationships and full lineage are recoverable, distinct from whether any version is accepted or released.

SVC-10 · Release Service

Service statement. Designates an accepted version as eligible for a defined scope and period of operational reliance, and governs withdrawal and supersession of that eligibility.

Purpose. Hold operational release as a distinct governed decision — separate from version creation and from acceptance — so that eligibility can be granted, retained, revalidated and withdrawn without touching version or identity.

Realised capabilities. Accountable for C-CAP-05.

Authoritative information objects. Release Record; Release Scope; Effective Period; Release Status; Withdrawal Record; Supersession Record; Revalidation Record.

Service operations. Verify an existing acceptance; bind release to a specific immutable version; define release scope and effective period; set and change release status; run eligibility checks; withdraw, supersede or revalidate a release; preserve release history.

Collaborations. Prerequisite: SVC-06 (acceptance), SVC-09 (version). Collaborating: SVC-08. Constrained by: SVC-16, SVC-17. Evidence from: SVC-15, SVC-19.

Enforced interaction constraints. IC-08 (Release Separation).

Authority boundary. Does not create versions (that is SVC-09); does not make the acceptance decision (that is SVC-06); does not derive or apply actionable forms. Release requires an existing acceptance and never manufactures one.

Operating criticality. Governance-critical; fail-closed — no release without a bound, accepted version, and no automatic inheritance of release by a new version.

Conformance condition. For every release, the immutable version released, its acceptance basis, scope, effective period, current status and predecessor or successor releases are recoverable, and no version is released without acceptance.

SVC-11 · Dependency Service

Service statement. Represents dependencies and dispositions objects and forms affected by change.

Purpose. Prevent locally correct change from silently invalidating dependent knowledge.

Realised capabilities. Accountable for C-CAP-07.

Authoritative information objects. Dependency Record; Dependency Impact Record; Revalidation Requirement; Dependency Disposition Record; Suspension Recommendation.

Service operations. Represent dependencies; determine impacted dependants; classify impact; disposition as revalidation, evolution, suspension or no-action; preserve impact decisions.

Collaborations. Prerequisite: SVC-01 (resolution). Collaborating: SVC-09. Triggers: SVC-08 (suspension), SVC-09 (evolve dependants). Evidence to: SVC-18.

Enforced interaction constraints. Participates in INV-15 (dependency disposition); raises IC-03 suspension triggers.

Authority boundary. Does not execute change or transition; does not accept or release; does not itself apply forms.

Operating criticality. Governance-critical; fail-closed — a changed object does not return to use with undispositioned dependants.

Conformance condition. For every material change, affected dependants and their recorded disposition are recoverable before the changed object returns to operational use.

Part V · Domain D Services

SVC-12 · Operationalisation Service

Service statement. Derives actionable forms from governed objects and controls their eligibility for use.

Purpose. Convert represented knowledge into usable forms without severing warrant. Form-level release governed here is distinct from object-level release (SVC-10).

Realised capabilities. Accountable for D-CAP-01.

Authoritative information objects. Actionable Form; Derivation Record; Warrant Linkage; Form Release Record; Form Status.

Service operations. Derive forms; distinguish provisional from released; link forms to source version, justification and acceptance; withdraw or replace forms on source change.

Collaborations. Prerequisite: SVC-06, SVC-09. Collaborating: SVC-10 (release alignment). Constrained by: SVC-16. Evidence from: SVC-15.

Enforced interaction constraints. IC-10 (Operationalisation Eligibility); IC-12 (Warrant Link Preservation).

Authority boundary. Does not accept or release the underlying object; does not apply forms; does not permit provisional forms into use.

Operating criticality. Operationally critical; fail-closed for release — a form is not made usable without a warrant linkage.

Conformance condition. Every operationally eligible form traces to an accepted object version and carries an inspectable warrant linkage.

SVC-13 · Application and Outcome Service

Service statement. Governs material use of actionable forms and captures outcomes as governed evidence.

Purpose. Keep use authorised, traceable and explainable, and close the loop back to the lifecycle.

Realised capabilities. Accountable for D-CAP-02, D-CAP-03.

Authoritative information objects. Application Record; Use Context Record; Eligibility Decision; Explanation Record; Application Participant Record; Outcome Record; Interpretation Record; Feedback Record; MaterialityMateriality — the degree to which an object, claim, decision or transition may affect consequential action, reliance, obligation, exposure, representation or preservation (KF-2003). Vocabulary → Assessment; Disposition Record; Lifecycle Trigger.

Service operations. Verify eligibility before use; record context and participants; preserve input-to-result path; produce modality-appropriate explanation; capture outcomes; assess materiality; assign disposition; raise lifecycle triggers.

Collaborations. Prerequisite: SVC-12. Collaborating: SVC-08. Constrained by: SVC-07 (governance status), SVC-16. Triggers: SVC-07, SVC-09, SVC-08. Evidence from: SVC-15.

Enforced interaction constraints. IC-11 (Application Eligibility); IC-12 (Warrant Link Preservation).

Authority boundary. Does not derive forms; does not accept or release; does not execute evolution or retirement, only trigger them.

Operating criticality. Operationally critical; fail-closed for use — an ineligible object is not applied. Outcome capture is recoverable within a defined, visible period.

Conformance condition. For each material application, what was used, why it was eligible, who participated, the result and a proportionate explanation are recoverable, and every material outcome has a recorded disposition.

SVC-14 · Retirement and Preservation Service

Service statement. Concludes operational use of an object while preserving identity, records and lineage.

Purpose. Remove knowledge from active reliance without destroying institutional memory.

Realised capabilities. Accountable for D-CAP-04.

Authoritative information objects. Retirement Record; Historical Object Record; Preservation Record; Reactivation Request; Successor Link.

Service operations. Record retirement reason and authority; remove object and forms from active eligibility; preserve the historical record; maintain successor links; support historical retrieval; route reactivation through evolution.

Collaborations. Prerequisite: SVC-01. Collaborating: SVC-08. Constrained by: SVC-16. Evidence from: SVC-19. Triggers: SVC-09 (reactivation via evolution).

Enforced interaction constraints. IC-04 (Reactivation through Evolution).

Authority boundary. Does not delete governed history; does not accept; does not permit reactivation outside governed evolution.

Operating criticality. Governance-critical — destructive deletion of governed history is prohibited.

Conformance condition. A retired object cannot be used operationally, yet its identity, versions, warrant, governance history and lineage remain recoverable.

Part VI · Domain E Services (Cross-Cutting)

The five Domain E services preserve and evaluate the governed context surrounding substantive knowledge. None authors or alters substantive content, and none independently authorises a lifecycle transition. They are ordered here from the most foundational (provenance) to the most derived (temporal reconstruction).

SVC-15 · Provenance and Traceability Service

Service statement. Preserves origin, derivation, custody, attribution and end-to-end traceability across all objects, records, transitions and applications.

Purpose. Make current states and historical change reconstructable.

Realised capabilities. Accountable for E-CAP-01.

Authoritative information objects. Provenance Record; Custody Record; Derivation Link; Attribution Link; Traceability Path; Provenance Gap Record.

Service operations. Preserve origin and derivation; trace representations, changes, forms, applications and outcomes; carry provenance across modality hand-offs; identify provenance gaps explicitly.

Collaborations. Prerequisite: SVC-01. Constrained by: SVC-16. Evidence to: all services.

Enforced interaction constraints. IC-20 (Provenance Continuity).

Authority boundary. Does not author or alter substantive content; does not authorise transitions; does not evaluate conformance.

Operating criticality. Governance- and conformance-critical; fail-closed at hand-offs — a hand-off that cannot preserve provenance is not silently completed.

Conformance condition. For a representative outcome, the path from source and creation through use and outcome is reconstructable, with any provenance gaps exposed.

SVC-16 · Access and Integrity Service

Service statement. Restricts access and material action by assigned permission while preserving the permission ≠ authority distinction, and protects record integrity.

Purpose. Protect governed records and operations against unauthorised access, alteration or disclosure.

Realised capabilities. Accountable for E-CAP-03.

Authoritative information objects. Access Policy; Permission Assignment; Authority Assignment Reference; Disclosure Constraint; Integrity Status; Administrative Action Record.

Service operations. Identify actors; assign and revoke permissions; enforce action permissions; protect integrity; enforce disclosure and use restrictions; record administrative action.

Collaborations. Collaborating: SVC-07. Constrains: all services performing a material action. Evidence from: SVC-19.

Enforced interaction constraints. IC-13 (Authority Is Not Permission); IC-14 (Least Necessary Alteration); IC-15 (Material Administrative Action); IC-16 (Automated Authority Boundary).

Authority boundary. Does not make governance decisions (acceptance, stewardship, retirement); grants permission, never authority; does not select security technologies.

Operating criticality. Governance-critical; fail-closed — an unauthorised material action is refused by default.

Conformance condition. For every material action, the actor’s required permission and, where applicable, the separate valid authority decision are demonstrable.

SVC-17 · Operating Condition and Exception Service

Service statement. Determines and exposes whether required services, controls and evidence are operational, degraded, failed, pending or indeterminate, and governs the consequences.

Purpose. Prevent absent evidence, failed controls or unavailable services from appearing as success. This responsibility is materially different from provenance or protection: it is the architecture’s fail-safe determinant, and it directly protects INV-24 (No Silent Success).

Realised capabilities. Accountable for E-CAP-04.

Authoritative information objects. Operating Condition Record; Degradation Record; Exception Record; Compensating Control Record; Recovery Record; Failure Disposition Record.

Service operations. Distinguish pass, fail, pending and indeterminate; represent degradation; determine fail-open or fail-closed posture; raise and bound exceptions; preserve compensating controls; trigger suspension or correction.

Collaborations. Collaborating: SVC-08. Constrains: SVC-08, SVC-07, SVC-04, SVC-10 (fail-posture on gates, reviews, evaluations and release). Triggers: SVC-08. Evidence to: SVC-18.

Enforced interaction constraints. IC-19 (Exception Visibility); participates in IC-02 (fail-posture at gates).

Authority boundary. Does not execute the corrective transition (that is SVC-08); does not define organisational risk acceptance.

Operating criticality. Conformance- and governance-critical; its own degradation defaults to fail-closed.

Conformance condition. When a condition cannot be evaluated or a service is degraded, the condition is recorded explicitly and the predefined consequence applied, rather than treated as satisfied.

SVC-18 · Conformance and Audit Service

Service statement. Determines and demonstrates whether required capabilities, invariants, gates, controls and constraints are satisfied.

Purpose. Prevent compliance from resting on structural resemblance or self-assertion.

Realised capabilities. Accountable for E-CAP-02.

Authoritative information objects. Conformance Assessment; Invariant Test Result; Constraint Test Result; Assurance Finding; Non-Conformance Record; Exception Reference.

Service operations. Inspect records and control evidence; test invariants and prohibited paths; reconcile evidence across services; record findings; distinguish conformance, variation, exception and non-conformance; recommend suspension or correction.

Collaborations. Evidence from: all services. Triggers: SVC-08 (via suspension recommendation), SVC-17.

Enforced interaction constraints. IC-17 (Read-Only Assurance Boundary); IC-18 (No Sole Self-Certification).

Authority boundary. Does not alter the records it examines; does not authorise transitions; is never an operational prerequisite of an operation it audits; does not certify its own outputs without independent evidence.

Operating criticality. Conformance-critical but not transaction-blocking — its unavailability renders operations unproven, not halted.

Conformance condition. The architecture can produce independently generated evidence for every required capability and report unmet, indeterminate or violated conditions without modifying the evidence assessed.

SVC-19 · Temporal Continuity Service

Service statement. Owns the governed temporal contract of the architecture: the meaning, sequence and authenticity of governed records and states across time, including as-of reconstruction.

Purpose. Maintain trust where events, records and effective conditions occur at different times. This is a distinct authoritative responsibility, not a timestamp utility: it owns effective dating, event sequencing, as-of reconstruction, retention and correction history, and it alone can answer “what did the governed record say, and hold true, as of a stated time.”

Realised capabilities. Accountable for E-CAP-05.

Authoritative information objects. Temporal Metadata Record; Effective Period; Event-Time Record; Custody History; Retention Condition; Correction History; Historical Reconstruction Result.

Service operations. Preserve recorded, effective and event time as three distinct semantics; sequence transitions and decisions; maintain correction history; preserve authenticity across format and custody change; reconstruct governed state as of a specified time; enforce retention and disposition.

Collaborations. Collaborating: SVC-09 (append-only correction). Evidence from: SVC-15; Evidence to: SVC-18.

Enforced interaction constraints. IC-21 (Append-Only Correction, with SVC-09); IC-22 (Time Semantics Preservation).

Authority boundary. Does not perform version mechanics (that is SVC-09); does not select storage technology; does not alter substantive content. It owns time semantics and reconstruction, not the records’ substantive content.

Operating criticality. Governance-critical; recoverable with bounded manual control, but never by relying on overwritten records.

Conformance condition. The object’s content, warrant, acceptance, governance and operational state can be reconstructed as of a specified historical point — using recorded, effective and event time — without relying on overwritten current records.

Part VII · Interaction Governance

This part is the centre of KF-3003. It fixes how services interact so that the interaction constraints hold in execution.

2. Service Interaction Principles

1. Only the accountable service may alter an information object it authoritatively maintains; others request change through a governed interaction.
2. Only SVC-08 may alter recorded lifecycle state.
3. No transition executes without a gate decision bound to it in the same operation.
4. No object is released (SVC-10) without an existing acceptance recorded by SVC-06 and a version created by SVC-09.
5. No actionable form is derived or applied without a preserved warrant linkage.
6. No governed record is overwritten; corrections append or version.
7. No service acquires authority by holding permission.
8. No automated service is the final accountable authority where human authority is required.
9. SVC-18 reads all services and alters none, and is never a prerequisite of the operation it audits.
10. Every material inter-service action is attributable and carries provenance.
11. When a required condition is unavailable or indeterminate, SVC-17 determines the fail-posture; the default is fail-closed for governance-critical operations.

3. Constraint Enforcement Matrix

Every interaction constraint is enforced at a named service boundary.

4. Prohibited Cross-Service Actions

No service may accept on behalf of another; write another service’s authoritative records directly; change lifecycle state outside SVC-08; release a version without an SVC-06 acceptance and an SVC-09 version; treat a permission from SVC-16 as an authority; present an SVC-18 assessment as an authorisation; or complete a hand-off that SVC-15 cannot make traceable.

Part VIII · Completeness

5. Capability-to-Service Crosswalk

Each capability names exactly one accountable service.

Every capability has exactly one accountable service; no capability is unassigned and no service is without a capability basis.

6. Coverage Test

The service architecture is complete when: every capability names exactly one accountable service; every governed information object has exactly one authoritative-maintainer service; every interaction constraint is enforced at a named boundary (§3); no service holds authority beyond its capabilities; no prohibited cross-service action is structurally possible; and the conformance service is read-only and non-prerequisite.

Part IX · Service Conformance

7. Service Conformance

A service conforms when it realises its accountable capabilities; is the sole authoritative maintainer of its information objects; exposes its operations without technology dependence; enforces its assigned interaction constraints; performs no prohibited action; and can demonstrate its conformance condition. As in KF-3002, conformance is systemic: a service is not conformant where an unmet collaboration prevents a constraint it must enforce.

8. Service Evidence

Evidence includes authoritative-ownership maps; operation traces; constraint-enforcement tests; prohibited-path tests; attribution and provenance checks; and independent assurance from SVC-18. Physical consolidation of services is permitted only where the authoritative-ownership boundary and constraint enforcement remain inspectable.

Part X · Relationship to Subsequent Documents

KF-3004 defines the information objects and record classes named here and fixes their authoritative-maintainer assignments and the recorded/effective/event time semantics owned by SVC-19. KF-3005 defines the gate logic and lifecycle controls that SVC-08 and SVC-17 apply, including the transactional gate–transition binding and the release eligibility checks of SVC-10. KF-3008 defines the human authority and accountability model that SVC-06 and SVC-07 depend upon, kept distinct from the technical permission SVC-16 assigns. KF-3007 defines the tests and evidence for service and constraint conformance. KF-3009 preserves traceability from principle through capability, service, record and control.

Closing Statement

The Service Architecture converts the twenty-four capabilities into nineteen governed logical services and, more importantly, into a set of enforced boundaries. Its contribution is not that the capabilities are exposed, but that they cannot be exercised in a way that bypasses one another: version is not release, release is not acceptance, permission is not authority, and assurance never authorises what it audits. Every interaction constraint is enforced at a named boundary; every governed record has a single authoritative maintainer; and no service holds authority it was not given. That is what makes this an execution architecture for governed knowledge rather than a catalogue of components.