| Internet-Draft | ICSD | March 2026 |
| Fisher | Expires 17 September 2026 | [Page] |
Invariant-Closed System Design (ICSD) defines an architectural principle for building systems in which all representable states are valid and compliant by construction. Rather than relying on runtime detection, validation, or remediation of invalid or abusive behaviour, ICSD ensures that invalid states are structurally unrepresentable through constrained state models, invariant-bound transitions, and authority-anchored truth sources.¶
This document introduces the ICSD concept, its core properties, design trade-offs, and applicability to compliance-critical domains such as payroll, taxation, financial reporting, and regulated infrastructure. It defines the current architectural and semantic baseline for the ICSD portion of the suite.¶
This document is part of an experimental, research-oriented Independent Stream suite. It defines the current normative baseline for trust objects, validation rules, and security semantics within its scope. Hard interoperability is expected for shared object semantics and validation rules. Full wire-level, clustering, and proof-family interoperability is not claimed everywhere yet; the remaining details are intentionally profile-defined or deferred where companion work has not yet closed them.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
This Internet-Draft is part of an experimental, research-oriented suite prepared for the Independent Stream. It is published to enable structured technical review, experimentation, and architectural discussion around Invariant-Closed System Design (ICSD).¶
Within that suite, this document defines the current normative baseline for trust objects, validation rules, and security semantics relevant to invariant-bound state transitions, evidence handling, and authority-anchored truth evaluation. Hard interoperability is expected for shared object semantics and validation rules.¶
The material is a research artefact. It does not claim technical completeness, production readiness, or endorsement by the IETF or any other standards body, and it is not presented as a standards-track specification.¶
Full wire-level, clustering, and proof-family interoperability is not claimed everywhere yet; relevant suite-level details remain intentionally profile-defined or deferred. ICSD is therefore presented primarily as an architectural and semantic baseline rather than a complete protocol, and it does not mandate a particular programming language, database technology, exchange format, or deployment model.¶
A reference Python implementation and tooling baseline for ICSD is available as dpa-icsd on PyPI.
As of March 6, 2026, the latest listed release is 1.0.10 and includes the icsd-dpa CLI for
evidence verification and linting.
This implementation is informative only and does not define the normative specification.¶
Many systems attempt to achieve correctness and compliance by accepting broad inputs, then using validation, monitoring, moderation, and repair mechanisms to detect and handle invalid behaviour after it occurs. This reactive approach increases operational complexity, creates ambiguous intermediate states, and expands the attack and abuse surface.¶
Invariant-Closed System Design (ICSD) proposes a different approach: design the system such that only valid states can exist. In an ICSD system, invalid and non-compliant states are not "handled" at runtime because they are not representable in the system's state space.¶
ICSD shifts complexity from runtime policing towards upfront modelling. It improves auditability by ensuring every persisted state is valid, and it reduces abuse opportunities that rely on malformed, partial, or inconsistent internal state.¶
Requirements Language: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and [RFC8174] when, and only when, they appear in all capitals.¶
System State: The complete set of values that determines system behaviour at a given instant, including persisted data and any in-scope in-memory state.¶
Representable State: A state that the system can encode in its data model and reach through its defined transitions.¶
Invariant: A condition that MUST hold for all representable states of the system (e.g., legal constraints, accounting identities, authorisation constraints, or schema requirements).¶
Invariant-Closed: A property of a system where the set of representable states is closed under the invariants; i.e., every representable state satisfies every invariant.¶
Authority-Anchored Truth Source: An external or internal source of truth that is treated as authoritative for specific facts (e.g., statutory registries, regulated rulesets, signed identity assertions, or versioned policy artefacts).¶
Bootstrap Trust Boundary: The admission boundary between a principal that is not yet inside the closed trust domain and one that has completed explicit bootstrap validation under accepted seed material, policy, and authority constraints.¶
No Singular Trust Anchor: A design property in which no single issuer, registry, revocation service, controller, or bootstrap source can unilaterally determine continued legitimacy for the whole system.¶
Recovery / Re-Enrolment: A privileged trust transition by which a previously known principal returns to an admissible state under tighter artefact, supersession, and policy checks than ordinary steady-state operation.¶
Fork Survivability: A property of an invariant-closed system in which independent continuation remains locally verifiable even if previously aligned authorities, registries, or operators diverge.¶
Reactive Enforcement: Any mechanism that detects, mitigates, or remediates invalid behaviour after it has been encoded as a system state (e.g., validation errors on persistence, moderation queues, anomaly scoring, or repair jobs).¶
Contemporary systems often permit a broad range of inputs and states, depending on reactive mechanisms - validation checks, monitoring, moderation, or repair - to handle invalid, non-compliant, or abusive behaviour after it occurs. This reactive approach increases operational complexity, maintenance burden, and exposure to errors or attacks that exploit inconsistent or intermediate states.¶
Invariant-Closed System Design (ICSD) offers an alternative paradigm: systems are structured so that only valid states can exist. Invalid or non-compliant states are not detected and corrected - they are prevented by design, as they have no representation in the system's state space.¶
The core axiom of ICSD is: If a system state can exist, it is already valid. Correctness, regulatory compliance, and legitimacy are embedded directly into the type system, input constraints, transition rules, and data sources.¶
This document outlines the ICSD principle, contrasts it with traditional reactive designs, and explores its benefits in domains where trust assumptions are minimal and authoritative sources define ground truth. Examples draw from production experience in payroll and taxation systems, where invariants are non-negotiable.¶
ICSD is particularly relevant to high-assurance environments, including financial systems, identity management, regulatory reporting, and secure infrastructure protocols.¶
This draft should therefore be read as part of an experimental, research-oriented Independent Stream suite and as the current normative baseline for trust objects, validation rules, and security semantics within its scope. Hard interoperability is expected for shared object semantics and validation rules. Full wire-level, clustering, and proof-family interoperability is not claimed everywhere yet; relevant details remain intentionally profile-defined or deferred in companion work. Multiple authorities or truth sources do not by themselves solve decentralisation, and broader availability properties still depend on explicit profile and deployment choices.¶
The foundational axiom of ICSD is: If a system state can exist, it is already valid.¶
Reactive design (detect+repair) | ICSD design (invalid unrep.)
input | input (constrained)
| | |
v | v
[broad parsing] | [invariant-safe encoding]
| | |
v | v
[state may be invalid] | [state always valid]
| | |
v | v
[detect/moderate/repair] | [audit transition history]
In a reactive design, the system must cope with invalid-but-encoded states and expend effort detecting, triaging, and correcting them. In an invariant-closed design, invalid states are unreachable: the system's representational model does not permit them, and transitions preserve invariants by construction.¶
ICSD does not imply that a system is small or trivial. Rather, it implies that as complexity increases, the modelling discipline increases as well: each additional state and transition is admitted only if it can be expressed in a way that preserves invariants.¶
An ICSD system defines a closed set of invariants: conditions that must always hold true. These invariants define the system's state space. The system MUST ensure that:¶
all representable states satisfy all invariants;¶
all state transitions preserve invariant validity; and¶
no mechanism exists to bypass or temporarily suspend invariants.¶
In practice, this typically requires modelling state as a finite set of well-defined types (or records) whose construction is only possible through invariant-preserving transitions.¶
Examples of non-negotiable invariants in compliance-critical domains include:¶
a payroll run cannot exist without a verified legal entity and an applicable tax context;¶
a regulatory submission artefact cannot exist unless schema and policy validation have passed; and¶
an authorisation grant cannot exist without a verified identity and an explicit scope of authority.¶
In ICSD, invariants are not optional checks; they define what the system can represent.¶
This section defines constitutional invariants for ICSD systems that operate in adversarial, decentralised, or jurisdictionally fragmented environments.¶
An invariant-closed system MUST remain operational if any single administrative, organisational, or jurisdictional entity ceases operation or becomes adversarial.¶
Consequently, an invariant-closed system MUST NOT require any single dependency class as an operational precondition, including any single identity issuer, certificate authority, revocation service, relay operator, directory service, or bootstrap source.¶
No invariant-closed system SHALL depend on a singular trust anchor whose compromise invalidates the system's operational guarantees.¶
This prohibition includes, but is not limited to, central CAs, global revocation lists, authorising bodies, mandatory bootstrap registries, mandatory relay controllers, or singular revocation services when used as unique trust anchors.¶
An invariant-closed system is not self-originating. A brand-new device, node, or principal is not yet within the closed trust domain and must first be admitted through an explicit bootstrap process. Bootstrap trust is therefore a first-class architectural concern rather than an implicit property of the steady-state protocol.¶
Deployments must define which bootstrap sources they accept. Acceptable bootstrap inputs may include manufacturer attestation, owner-installed or operator-installed seed trust, pre-provisioned deployment credentials, local attestation ceremony, physically mediated enrolment, custodial onboarding authority, verified HIL-assisted enrolment, or administrative or MDM-style approval under signed policy. The bootstrap authority MUST be explicit, narrow, auditable, and non-magical.¶
Bootstrap trust does not, by itself, confer unlimited steady-state authority. Once bootstrap is complete, ordinary invariants, scope limits, revocation rules, and policy validation MUST apply, and the bootstrap path MUST NOT silently bypass them.¶
Bootstrap, recovery, and re-enrolment are privileged trust transitions and are especially suitable for invariant-closed modelling because admissible artefacts, bounded authority, supersession rules, and fail-closed outcomes can be made explicit. An ICSD-aligned system should make unauthorised or ambiguous Day Zero and recovery states structurally unrepresentable rather than merely detectable after admission.¶
An invariant-closed system MUST permit independent continuation (fork) without invalidating identity or operational semantics for participating nodes.¶
Post-fork operation MUST remain locally verifiable and MUST NOT depend on continued alignment to a canonical registry for legitimacy.¶
For identity-bound systems, this implies that identities remain usable post-fork, mediator operation remains registry-independent, trust relationships remain independently maintainable, and accountability or transparency artefacts remain locally interpretable even when no single post-fork authority is universally recognised.¶
Closed does not mean centrally controlled.¶
Closure refers to integrity-bound operational constraints and cryptographically sealed state-transition semantics, not administrative centralisation.¶
Invariant-closed systems SHOULD provide cryptographic transparency or accountability mechanisms sufficient to permit independent verification of system behaviour and state transitions.¶
Examples include signed append-only transparency logs, cryptographic reachability evidence, and verifiable misbehaviour proofs.¶
No invariant-closed system SHALL include unilateral global revocation or termination capabilities absent multi-party cryptographic consensus.¶
A defining property of ICSD is the elimination of representable invalid states. In an ICSD system, there are no:¶
invalid-but-saved records;¶
broken intermediate states;¶
speculative or partially complete entities; or¶
privileged objects created before authority has been verified.¶
If a configuration or object cannot be valid, it has no representation in storage or memory. This removes entire classes of bugs and abuse vectors associated with partial, inconsistent, or order-dependent state.¶
Because invalid behaviour cannot be encoded, ICSD systems minimise or eliminate the need for reactive enforcement mechanisms such as:¶
heuristic abuse detection and anomaly scoring;¶
moderation queues and manual review pipelines;¶
background repair jobs for data quality;¶
error-driven state reconciliation; and¶
ad hoc "fix-forward" scripts to correct invalid persistence.¶
Reactive enforcement is replaced by structural impossibility. The system does not monitor for invalid behaviour; it cannot represent it.¶
This does not remove all monitoring needs. Systems may still monitor for availability, performance, and suspicious but valid activities. ICSD specifically targets the class of failures where invalidity arises from representable internal state.¶
In ICSD systems, auditability emerges as a side effect of correct design:¶
every persisted state is valid;¶
audit logs describe state transitions, not error recovery;¶
compliance evidence is implicit in system history; and¶
reconciliation becomes verification rather than investigation.¶
A practical consequence is that auditors and operators can reason over the system using a smaller set of cases: "what valid state did we enter, when, and under what authority?" rather than "what went wrong and how did we patch it?"¶
ICSD is especially valuable where invariants are externally imposed (e.g., law and regulation) and where failure modes have significant cost (e.g., financial penalties, reputational harm, or operational shutdown).¶
High-value control-plane elements are especially strong candidates for invariant-closed modelling. Examples include RN controllers, patch or release manifests, grant ledgers, route-policy objects, and similar authority-bearing artefacts in identity-centric systems. For such objects, the design goal is that unsigned overrides, invalid signer sets, rollback states, policy-ineligible transitions, and partial-write artefacts are not merely detected after the fact but are structurally unrepresentable.¶
As a small informative example, a UZPIF-compatible deployment could model RN controller state acceptance as an invariant-closed transition: a controller update would become admissible only when the signed controller object, the authority set accepted at the bootstrap trust boundary or by later recovery / re-enrolment, epoch or sequence precedence, and applicable policy scope all validate together. This illustrates a compatible design discipline, not a requirement that UZPIF implementations adopt ICSD as a mandatory framework, prerequisite layer, or protocol dependency.¶
ICSD deliberately shifts complexity away from runtime policing and remediation towards upfront modelling and invariant definition. This increases initial design discipline but can reduce long-term maintenance cost, operational overhead, abuse surface area, and regulatory exposure.¶
Common trade-offs include:¶
Reduced flexibility: inputs and workflows may be more constrained than in permissive systems.¶
Upfront modelling cost: invariants must be identified, formalised, and tested early.¶
Migration complexity: legacy datasets containing invalid state may require transformation.¶
Profile management: different jurisdictions or policy regimes may require explicit profiles.¶
ICSD is not a statement that "validation is bad". It is a statement about where validation belongs: as part of constructing representable state, rather than as a recurring operational burden after invalidity has already been encoded.¶
| Traditional design | ICSD design |
|---|---|
| Accepts broad input | Accepts only invariant-safe input |
| Detects invalid behaviour | Cannot represent invalid behaviour |
| Repairs bad states | Prevents bad states |
| Relies on monitoring | Relies on structure and modelling |
| Compliance as process | Compliance as property |
| Security controls often layered on top | Many controls become inherent to the state model |
ICSD does not remove the need for good engineering practices such as testing, change control, or operational security. It changes the baseline: correctness and compliance become properties of what the system can represent.¶
ICSD is particularly well suited to domains where:¶
correctness is mandatory and errors have high cost;¶
authoritative sources define ground truth;¶
trust cannot be assumed; and¶
regulatory exposure is high.¶
Example domains include payroll and taxation, financial systems, identity and access control, regulatory reporting, and secure infrastructure and protocol design.¶
In identity-first architectures, a common failure mode is the existence of "privileged but invalid" objects, such as a grant that exists before identity is verified, or a session that exists before policy checks are applied. ICSD mitigates this by making such objects unrepresentable: the only representable grants and sessions are those that are already bound to verified identity and explicit authority.¶
This principle complements identity-bound frameworks and transports such as [UZPIF], [UZP], and [TLS-DPA], where correctness and authorisation are expected to be intrinsic properties of the connection and its negotiated state. ICSD is therefore best read as a design discipline and implementation approach that fits such systems well, not as a suite-mandatory governance layer, required subsystem, or deployment prerequisite.¶
ICSD can reduce attack surface by eliminating representable invalid states. Many classes of injection, abuse, and privilege escalation rely on malformed, partial, or inconsistent internal state; ICSD systems make such states unreachable by design.¶
However, ICSD is not a complete security model. A representable state being "valid" with respect to invariants does not guarantee that it is desirable. Attackers can still:¶
perform harmful actions that are valid within policy (e.g., authorised but abusive use);¶
target the integrity of truth sources (e.g., poisoning authority data);¶
exploit incorrect invariant definitions (i.e., specification bugs); and¶
attack availability (e.g., denial-of-service) regardless of state validity.¶
Designers should treat invariants and authority sources as security-critical artefacts: they SHOULD be versioned, reviewed, tested, and auditable. Where possible, authority inputs SHOULD be authenticated (e.g., signatures, provenance records) and changes SHOULD be subject to explicit change control.¶
Invariant-Closed System Design reframes correctness from a runtime concern into a structural property. By designing systems where invalid behaviour is not prevented but structurally impossible, ICSD can reduce operational complexity, improve auditability, and strengthen trustworthiness in compliance-critical environments.¶
ICSD is best viewed as a discipline: it rewards rigorous modelling and clear definitions of invariants and authority. Where those conditions hold, it can remove entire classes of failures that otherwise demand continuous monitoring and remediation. It can inform architectures such as UZPIF, UZP, and TLS-DPA without being a prerequisite for deploying or understanding them.¶
Invariant-Closed System Design is the practice of building systems where invalid behaviour is not prevented - it is structurally impossible.¶
This document has no IANA actions.¶