The WISP Standard

Identifier: SF-WISP-STD-001 Version: 0.11-wd.1 Date: 2026-08-31 Status: Working Draft — not a ratified standard

Status of This Document

This document is a Working Draft. It is published to invite review, independent implementation, and the implementation experience that informs subsequent revisions. Nothing in it constitutes a present obligation on any party.

This Standard states what must be true for an implementation to claim WISP conformance. It does not describe how the Foundation's implementation works. That description is a separate document — the WISP Specification, SF-WISP-SPEC-001 — and the separation is deliberate. A standard that also documents its author's implementation tends to promote incidental choices into requirements, and every requirement so promoted removes latitude from an implementer for no interoperation benefit.

The rule applied throughout: if two independent implementations could disagree about it and still interoperate, it is not in this document.

Every normative requirement cites the filed disclosure it derives from, so a reader may check this Standard against the public and filed record rather than trusting the document. Two sources are cited: U.S. Patent No. 12,688,267 B1, Systems and methods for multi-modal semantic identity authentication and governance, issued 21 July 2026 from application 19/308,229; and the Kronos provisional, application 63/997,636, filed 5 March 2026.

Requirements follow IETF-style normative conventions per RFC 2119 / RFC 8174, with the maturity-tier extension used throughout Foundation standards.

Abstract

A Wisp is an identity object: a composite of a narrative element and one or more contextual elements, fused with a temporal element computed during fusion, carrying provenance of where its modalities came from and what it descends from.

Identity is expressed as recognition rather than possession. An object is compared with the objects that identity has previously authenticated; the comparison yields coherence, trust and drift; the measurement resolves to one of four states — permit, delay, escalate, deny. On a permit the object carries away a token that a third party verifies without calling anyone.

The consequences follow from the shift. There is nothing to steal, because a captured object is a measurement of a moment and the moment decays. There is no revocation list, because authority expires by arithmetic rather than by announcement. And the answer is not binary, because between yes and no there is not yet and a person should look at this.

This Standard proposes fourteen conformance requirements across three maturity tiers.

1. Introduction

1.1 Motivation

The AGI Standard requirement AGI-4 (Identity-Bound Computation) carries an open question: "What is the minimum acceptable identity primitive? Is a manifold required, or are other identity representations sufficient?" A requirement whose central term is undefined cannot advance from PROPOSED to CORE. This Standard proposes that minimum primitive.

The narrower motivation is that the credential model has no answer for a subject that changes. A token describes a moment and is then presented as though it described a person. Everything downstream — session timeouts, refresh cycles, revocation lists, re-authentication prompts — is an attempt to reintroduce time into a primitive that has none. An identity object carries time in its own arithmetic instead.

1.2 Scope

In scope. The identity object's composition and canonical form; the measurement of one object against another; the resolution of that measurement into a decision; and the token by which a decision travels to a party that did not take it.

Out of scope. How signals are captured. Which embedding model produces a narrative vector. How objects are stored or transported. What thresholds a deployment sets. Which roles exist. These are deployment decisions and this Standard states none of them.

Deliberately not required. A vector database, a graph database, a specific embedding model, a specific hash beyond the one the canonical form names, a network protocol, a key infrastructure, or a particular programming language. An implementation using none of these can be fully conforming.

1.3 Relationship to Other Standards

SF-WISP-SPEC-001, the WISP Specification, gives the complete technical description: the canonical encoding's byte layout, the temporal encoding, the fixed-point determinism profile, conformance vectors, and the test cells. This Standard references the Specification for the definition of the canonical form; it does not restate it. Where the two appear to conflict on a normative point, this Standard governs.

SF-AGI-STD-001, the AGI Standard, is the parent. WISP proposes the identity primitive AGI-4 requires and is intended to satisfy AGI-4, AGI-5 and AGI-8 for a conforming deployment.

2. Definitions

Wisp — a Weighted Identity Semantic Profile: an identity object composed of one narrative element and one or more contextual elements, a temporal element, and provenance for both, together representing the live state of a subject in a high-dimensional semantic space.

Element — a named, comparable structured datum derived from an observed signal. Commonly an embedding vector, and the granted claims recite exactly that; what this Standard requires is that an element be comparable, not that it be a list of numbers. A modality name denotes the role an element plays in the composite, never its representation; the representation is what the declared topology states.

Narrative element — the subject's own account of itself. The dividing line is authorship: narrative is what the subject says about itself, contextual is what the world says about the subject. Embodiments include an utterance, an expressed intent, an accumulated history, and a settled norm. It is the modality that cannot be absent, because a composite assembled purely from observation describes a device rather than a person.

Contextual element — anything the world observes about the subject: role, location, device, behavioural, environmental, biometric.

Temporal element — the time-derived component computed during fusion, carrying at minimum the interval since the last verified interaction.

Prior object — a previously authenticated object that subsequent objects are measured against. An implementation retaining one compares against it; an implementation retaining several compares against the set. The granted claims recite previously authenticated Wisps, and this Standard uses the shorter form for the same thing.

Coherence — semantic proximity between an object and a prior object, under the object's declared topology.

Trust — where a composite's per-modality bearings intersect, decayed over elapsed time. Not a single similarity: a composite offers one bearing per modality, and whether they agree carries information no individual similarity does. The degenerate case, a single bearing after decay, is what a non-composite system is limited to.

Drift — how far the object has moved from what that identity previously authenticated.

Decision — one of permit, delay, escalate, deny.

Provenance token — the artefact issued on a permit, carrying enough of the decision that a third party can re-derive it.

Implementation — software claiming conformance with this Standard.

3. Maturity Tiers and Conformance Levels

3.1 Maturity Tiers

Each requirement is assigned to one of three maturity tiers. The tier reflects the Foundation's current evidence that the requirement is implementable and meaningful, not the requirement's eventual importance. A requirement can be central to the architecture and still sit at FORWARD-LOOKING because no working code demonstrates it yet.

3.1.1 CORE (MUST in v1.0)

Requirements where the Foundation has direct evidence of implementability through working code in the reference Implementation, and the requirement is foundational to the identity-object claim. CORE requirements are written with MUST and form the minimum bar for any WISP conformance claim.

3.1.2 PROPOSED (SHOULD in v1.0; expected to become MUST in v2.0)

Requirements with working implementation evidence where the specific formulation may benefit from community refinement before becoming a strict obligation. Written with SHOULD. Non-conformance MUST be documented in the Implementation's conformance report.

3.1.3 FORWARD-LOOKING (MAY in v1.0; under active investigation)

Requirements where the right approach is genuinely uncertain, or where the Foundation has no implementation evidence. Written with MAY, and included to flag the territory and invite contribution rather than to commit any party.

3.2 Why this tiering matters

A Standard that publishes everything as MUST commits its early implementers to obligations that may not survive operational experience. A Standard that publishes everything as MAY communicates no commitment at all.

For this Standard specifically there is a second reason. WISP derives from a granted patent, and a granted claim is a description of what is covered — not of what is required to interoperate. Those are different sets, and the temptation to treat every claim as a requirement is exactly the failure this tiering exists to prevent. Several claims of the granted patent appear in this document at FORWARD-LOOKING or not at all, because no working code demonstrates them and a requirement without evidence is a guess with a MUST in front of it.

3.3 Tier Migration

• FORWARD-LOOKING → PROPOSED: when at least two independent Implementations demonstrate the requirement is implementable in working code, and the Working Group reaches rough consensus on the formulation.
• PROPOSED → CORE: when at least three independent Implementations have satisfied the requirement in production for at least 12 months, and the formulation has stabilized.
• CORE → DEPRECATED: only through a MAJOR version increment. CORE requirements cannot be weakened, only strengthened or replaced by structurally-equivalent-or-stronger alternatives.

3.4 Reading the Requirements

Each requirement carries a Tier, normative wording using MUST / SHOULD / MAY per the tier, a Rationale, Implementation evidence stating the Foundation's own status honestly, Open questions where the Working Group needs to resolve something, and a Test identifier whose specification lives in the Specification's test catalogue.

3.5 Conformance Levels

WISP Interoperable (proposed) — an Implementation satisfying WISP-2 and reproducing the Specification's conformance vectors. This is the narrowest useful claim and worth stating separately: two Implementations can be interoperable and still reach different verdicts on the same object — that is what configurable thresholds mean — but two that cannot exchange an object have nothing to disagree about.

WISP Compliant (proposed) — an Implementation satisfying all CORE requirements and documenting its handling of PROPOSED and FORWARD-LOOKING requirements in a conformance report.

WISP Certified (proposed) — an Implementation satisfying all CORE and PROPOSED requirements and documenting its handling of FORWARD-LOOKING requirements.

Conformance levels are provisional. No certification mark issues before v1.0 ratification.

4. Proposed Conformance Requirements

WISP-1: Composite Multi-Modal Construction

Tier: CORE

MUST — An Implementation MUST construct the identity object from a narrative element and at least one contextual element, fused into a single composite. An object with no narrative element MUST be refused at construction rather than evaluated.

Rationale: The composite is the primitive. A single modality is a credential by another name — it can be captured, replayed and presented in isolation. The narrative element is mandatory because it is the modality the subject authors; a composite of context alone describes a device, not a person.

Implementation evidence: Implemented. Construction refuses a missing narrative element; a live 768-dimensional embedding model produces the narrative element in the reference workspace.

Open question: Is one additional modality the right floor, or should CORE require two?

Source: '267 cl. 1 · Test: TC-WISP-1

WISP-2: Canonical Encoding and Content-Addressed Identifier

Tier: CORE

MUST — An Implementation MUST serialize an object to the canonical byte sequence defined in the Specification, and MUST derive the object's identifier as the first sixteen bytes of the BLAKE3 hash of that sequence. Decoding a canonical sequence and re-encoding the result MUST reproduce the original bytes exactly.

Rationale: Every other guarantee rests on two parties agreeing what an object is. Without a canonical encoding the narrative hash of WISP-5 is undefined, verification has nothing stable to verify against, and two Implementations cannot exchange a single object. An identifier that differs between Implementations is not an identifier.

Implementation evidence: Implemented. Three frozen conformance vectors round-trip byte-for-byte; a one-byte change to any field moves the identifier.

Source: '267 cl. 1, cl. 12 · Test: TC-WISP-2

WISP-3: Four-State Governance Decision

Tier: CORE

MUST — An Implementation MUST resolve every evaluation to exactly one of permit, delay, escalate, or deny, and MUST be able to reach all four. An Implementation whose evaluation cannot emit one of the four does not satisfy this requirement, whether or not the state is enumerated in its types.

Rationale: The two intermediate states are the uncertainty interval. Collapsing a marginal measurement into a confident yes or no discards precisely the information that made it marginal — delay asks for more evidence, escalate refers to a person, and a system with neither must round every ambiguity to a decision it cannot support.

The reachability clause is not pedantry. A four-state enumeration in which nothing ever emits delay is a three-state machine with an unused variant, and the difference is invisible without a test that reaches all four.

Implementation evidence: Implemented. A frozen decision vector walks a declining trajectory through all four states in order.

Source: '267 cl. 1, cl. 5 · Test: TC-WISP-3

WISP-4: Fail-Closed Default

Tier: CORE

MUST — Every default in an Implementation MUST refuse. An unconfigured role MUST NOT grant; an empty allow-list MUST NOT permit; a measurement that could not be taken MUST NOT be treated as a passing one; a timestamp preceding its own reference point MUST NOT yield full validity. An Implementation MUST NOT provide a mode that silently converts a denial into an approval.

The rule extends to capability: an Implementation MUST NOT present a degraded measurement or matching mode as the full one. A degraded mode MUST be selected explicitly, MUST be identifiable at runtime, and MUST announce itself wherever its results are reported.

Rationale: This is the requirement most often satisfied in principle and violated in practice, because every violation reads as a sensible default at the point it is written. An unconfigured role returning a wildcard looks like convenience; a shadow mode that logs denials instead of enforcing them looks like a safe rollout. Both are the same defect, and both are invisible until they are load-bearing.

The prohibition on a silent shadow mode is deliberate and narrow: an Implementation MAY record what it would have decided, provided the recorded verdict and the enforced verdict are both present and distinguishable.

The capability clause earns its place the same way the rest of this requirement did — by a real failure. An independent evaluation of the reference implementation found its offline default performing exact-string matching where the documentation promised matching by meaning: every refusal path was fail-closed, and the one fail-open surface was a promise the default configuration could not keep, invisible precisely because nothing failed. Degraded operation is legitimate (WISP-12 is built on it); degraded operation that does not say so is a bypass wearing a compliance badge.

Implementation evidence: Implemented. Each named default has a test asserting the closed answer, and a conformance tool checks them against a build the checker did not compile.

Source: '267 cl. 1, cl. 7 · Test: TC-WISP-4

WISP-5: Callback-Free Verification

Tier: CORE

MUST — On a permit, an Implementation MUST attach a provenance token carrying at minimum the trust and drift measured, a hash of the narrative element, the decision, the temporal parameters under which it was taken, and the role context. A verifying party MUST be able to check the token using only the token and its own clock — without contacting the issuer, a key server, a revocation list, or any other authority.

Rationale: This is what makes the object portable rather than merely transferable. A credential that must be checked with its issuer has not left the issuer's perimeter; it has extended it. Carrying the decision's parameters inside the token means the verifier re-derives the decision rather than accepting a claim about it, and it means a verifier may apply a stricter threshold than the issuer did.

An Implementation MAY sign the token. This Standard does not require a digital signature, because a signature imposes a key infrastructure and the callback-free property does not depend on one.

Implementation evidence: Implemented via hash-chain preimage verification against a stored anchor; the verifier is a pure function of the token and a clock.

Open question: Granted claim 9 recites cryptographic signing of token fields. Should signing be required at CORE, or does requiring it import a key-management obligation the callback-free property was meant to avoid?

Note (v0.9): the reference implementation now demonstrates token-as-capability consumption — an execution path that structurally requires a token-backed permit and spends it on use. The Specification's §11.8 describes it as reference material; whether any of it belongs in a future requirement is a Working Group question.

Source: '267 cl. 1, cl. 19, cl. 20 · Test: TC-WISP-5

WISP-6: Geometric Temporal Element

Tier: PROPOSED (expected to become MUST in v2.0)

SHOULD — The temporal element SHOULD carry at minimum the interval since the last verified interaction, a decay parameter, and phase features positioning the moment within its natural cycles. It SHOULD be computed during fusion; applying temporal weighting after fusion is a conforming alternative with lower phase sensitivity and higher overhead, and an Implementation choosing it SHOULD record that choice in its conformance report. Where cyclical phase features are used, each sine/cosine pair SHOULD satisfy sin²θ + cos²θ = 1 to a declared and measured tolerance.

Rationale: Computing the temporal element during fusion makes time a constituent of identity rather than an annotation on it, and an object whose time was applied afterwards is easier to alter without disturbing anything else. The preference is stated as a preference because the alternative produces a usable object; what this requirement fixes is that the temporal element be present and geometric, not the order in which it was assembled. The phase identity is what makes the encoding a phase: without it the components are two numbers with no periodicity, and the temporal element no longer carries what it is claimed to carry.

The tolerance must be measured rather than assumed. A tolerance far above the observed worst case bounds nothing; one below it fails on inputs the encoder will genuinely see.

Implementation evidence: Implemented. The reference encoder's worst-case deviation over a dense sweep of its full domain is 7.6 × 10⁻⁵, which is five units of the storage type's resolution.

Source: '267 cl. 1 · K Pillar 2 · Test: TC-WISP-6

WISP-7: Half-Life Trust Decay

Tier: PROPOSED (expected to become MUST in v2.0)

SHOULD — Trust SHOULD decay from coherence as a function of elapsed time on a configurable half-life, such that trust never exceeds the coherence it derived from and never rises with elapsed time. An elapsed interval that is negative — a timestamp preceding its own reference point — SHOULD yield zero rather than full validity.

Rationale: Decay is what replaces the session timeout, and it does so continuously rather than in one step. Note that what decays is a coefficient, and an Implementation whose composite offers several bearings should establish that coefficient from where they intersect rather than from their average — see the Specification. Averaging discards whether the modalities agree, which is the only thing that distinguishes a consistent subject from an adversary who has captured one channel. The negative-interval clause names a specific and common defect: a saturating subtraction on a backwards clock returns the full remaining validity, so clock skew in the wrong direction reads as perfect freshness.

Implementation evidence: Implemented, with the negative-interval case asserted as zero.

Open question: Granted claim 8 recites a configurable half-life in the range 24 to 720 hours. Should the Standard bound the range, or is bounding it a deployment decision?

Source: '267 cl. 1, cl. 8 · K Pillar 3 · Test: TC-WISP-7

WISP-8: Declared Topology and Refusal on Incommensurability

Tier: PROPOSED (expected to become MUST in v2.0)

SHOULD — An object SHOULD declare the topology under which its elements are to be compared, and an Implementation SHOULD compare only under the declared topology. Where a comparison cannot be taken — differing topologies, differing modality sets, elements of differing dimension, or a degenerate input such as a zero-magnitude element — an Implementation SHOULD report the absence of a measurement and MUST NOT report a numeric score. An absent measurement MUST be distinguishable from a low one and MUST NOT enter any average or threshold comparison.

Rationale: Comparison functions are not interchangeable and the difference is not subtle. Cosine similarity ignores magnitude, which is correct for normalized embeddings and wrong for raw behavioural features — under a spherical comparison an agent working once per second and one working a hundred and forty times per second produce parallel vectors and score as identical. The topology must therefore travel with the object rather than being assumed by whoever compares it.

The refusal clause is the same principle applied to the degenerate case. A zero returned for an incommensurable pair reads as maximal dissimilarity to a distance metric and as orthogonality to a cosine, and either can be averaged with real measurements until it disappears.

Implementation evidence: Implemented. Topology is declared per object and bound into the canonical encoding; incommensurable comparisons return an absent measurement throughout.

Source: '267 cl. 1, cl. 2 · Logos ¶0041 · Test: TC-WISP-8

WISP-9: Deterministic Evaluation

Tier: PROPOSED (expected to become MUST in v2.0)

SHOULD — Governance computations SHOULD be deterministic and reproducible across platforms, such that the same inputs yield identical decisions and identical audit records on differing hardware. An Implementation SHOULD NOT read a system clock inside an evaluation; every timestamp SHOULD be supplied by the caller.

The arithmetic is an implementation choice. The Specification defines one fixed-point profile that satisfies this requirement; an Implementation MAY reach it by other means, and one claiming the Specification's profile MUST follow it.

Rationale: Determinism is what makes a decision independently re-checkable. The clock clause is the part most easily overlooked: a decision record containing a value the evaluation read for itself cannot be reproduced by anyone, and an audit record that changes on every run cannot be cited as evidence of anything.

Mandating fixed-point arithmetic would exclude legitimate approaches that reach the same guarantee, so this requirement states the property and the Specification states one profile.

Implementation evidence: Implemented. A frozen decision vector reproduces across runs; no evaluation path reads a clock.

Source: K Pillar 3 · SIG-V10 · Test: TC-WISP-9

WISP-10: Append-Only Decision Record

Tier: PROPOSED (expected to become MUST in v2.0)

SHOULD — An Implementation SHOULD record every decision — including every refusal — to an append-only, tamper-evident record. Where the Implementation permits its comparison, normalization or composition components to be replaced, each record SHOULD carry the identity of the components active when the decision was taken, together with the operating mode in force.

Rationale: An audit trail containing only successes is not an audit trail; the interesting question after an incident is usually what was refused and why. The configuration clause resolves a tension rather than adding ceremony: replaceable components and a durable record are in conflict unless the record says which components produced each decision, and without that a decision taken while components could still be swapped is indistinguishable from one taken under a sealed configuration.

Implementation evidence: Implemented. Refusals are recorded; the active component set and mode are bound into each record's hash.

Source: '267 cl. 12 · SIG-C10 · Test: TC-WISP-10

WISP-11: Proof-Gated Governance

Tier: PROPOSED (expected to become MUST in v2.0)

SHOULD — An Implementation SHOULD check the scores reaching a decision against the invariants their definitions guarantee — that a coherence computed as a similarity lies within that similarity's range, that a decayed value does not exceed the value it decayed from, that an identifier is the content address of its own bytes — and SHOULD resolve to deny where any such invariant fails, irrespective of the decision the thresholds would otherwise reach. A failed invariant SHOULD be recorded, any token that would have issued SHOULD be withheld, and the failure SHOULD be reported distinguishably from a low score.

Rationale: A Standard permitting replaceable components has admitted numbers computed by code the governance layer has not seen. Threshold comparison cannot distinguish an honest score from a fabricated one; an invariant can. The check is cheap because each invariant is a property of the result rather than a re-derivation of it — recomputing a value and comparing establishes only that two implementations agree, which is worth little when one of them is the component under suspicion.

The distinguishability clause matters operationally: a broken invariant and a drifting identity both produce a denial, and they call for completely different responses.

Implementation evidence: Implemented. A component reporting a similarity outside its range is gated to deny with the policy having reached permit, and the refusal is recorded.

Source: '267 cl. 12 · SIG-X08 · Test: TC-WISP-11

WISP-12: Degraded Temporal Operation

Tier: PROPOSED (expected to become MUST in v2.0)

SHOULD — Where wall-clock position is unavailable, an Implementation SHOULD represent the absence as a distinct state in the canonical encoding — never as a vector a real observation could have produced — and, where it accepts such objects, SHOULD compensate by raising its trust and role-alignment requirements. An Implementation MUST NOT substitute a default or assumed timestamp, and acceptance of degraded objects SHOULD be a deliberate configuration rather than a default.

Rationale: This is the graceful-degradation path for edge deployment — a device with no real-time clock, a cold boot before time synchronisation, a sensor behind an unreliable time source. Without it such a device can never authenticate; with it, it authenticates at a higher bar. The raised thresholds are what keep it honest: the Implementation is not pretending the missing signal was neutral evidence, it is demanding more from the signals it does have.

Two constraints are load-bearing. Neutral must be recognisably neutral — if it is representable as a legitimate encoding, an adversary can claim neutrality to escape temporal scrutiny. And a defaulted timestamp is the wrong mechanism entirely: a stale default decays everything to nothing, while a near-present default confers full freshness on an object with no temporal evidence behind it, which is the same fail-open as a backwards clock.

Note that a monotonic counter, where available, degrades far less: it cannot report wall-clock position but it does report elapsed interval, so decay and replay resistance both survive and only the phase features are lost.

Implementation evidence: Implemented. The phase carries a one-byte presence tag in the canonical encoding (version 3); elapsed time survives the degradation because a monotonic counter supplies it without a wall clock, so decay and replay resistance are retained and only the position-in-cycle features are lost. Acceptance is an opt-in: without a configured policy a degraded object is refused, and with one the permit bar and the role-alignment minimum both rise. The proof layer records a degraded-arm witness on every such evaluation, so a sealed run states how many of its decisions ran without a wall clock.

Open question: By how much should thresholds rise, and is that a normative quantity or a deployment's calibration? The reference raises the permit bar by 0.05 and the role minimum to 0.80, as calibration rather than as a proposal.

Source: '267 cl. 7, cl. 15 · SIG-HC01 · Test: TC-WISP-12

WISP-13: Typed-Graph Persistence

Tier: PROPOSED (expected to become MUST in v2.0)

SHOULD — An Implementation SHOULD store each object as a node in a persistent semantic memory graph, connected by typed edges to its modality-element nodes, with edge types including at least has_narrative, has_role, has_temporal and has_location. The disclosure's own figure carries three further edges — has_modal, has_provenance and has_trust — and makes the provenance metadata and the trust score nodes rather than fields, so both are traversable and versionable alongside the object.

Rationale: Trust as a node rather than a field is the part worth noticing: it makes a subject's trust history a first-class thing the graph can be queried over, which is what supports drift analysis across a population rather than one subject at a time.

The graph makes lineage traversable in both directions — from a composite to its constituents, and from a modality element to every composite that used it. The second direction is what supports drift analysis over a population rather than over one subject.

Note that granted claim 18 recites a vector database as a dependent claim, which narrows: claim 1's graph is deliberately broader, and a file-backed store satisfies it. Where an Implementation persists the graph, the serialization SHOULD use the canonical encoding of WISP-2 rather than a format with no canonical form, so that graph nodes inherit content addressing instead of breaking it at the store boundary.

Implementation evidence: Implemented. All seven edges, with provenance and trust as nodes. Elements are content-addressed and shared, so reverse traversal — from an element to every object carrying it — is available and tested. Trust readings accumulate rather than overwrite, making a subject's trust history traversable.

Open question: Is typed-graph persistence required for conformance, or is any store supporting the comparisons of WISP-8 sufficient? The reverse direction is the part that a non-graph store cannot easily supply, and it is the part population-level drift analysis needs.

Source: '267 cl. 1, cl. 10, cl. 18 · Test: TC-WISP-13

WISP-14: Consent-Bound Retention and Verifiable Erasure

Tier: FORWARD-LOOKING

MAY — An Implementation MAY bind stored objects to a consent scope with a purpose classification and an expiry, apply a retention half-life derived from that classification, and re-evaluate retained objects when consent changes. Where erasure is performed, an Implementation MAY issue an erasure certificate that a third party can verify without disclosing any other retained object.

Rationale: An identity system that measures a subject accumulates a record of that subject, and the record outlives the purpose it was collected for unless something makes it expire. Binding retention to consent puts the expiry in the same arithmetic as the trust decay, rather than in an operational procedure. The erasure certificate is the part that is genuinely hard: proving that a specific object is gone, to someone who cannot be shown what remains.

Implementation evidence: The erasure certificate is implemented. The store commits to its object set as a Merkle accumulator over sorted content addresses; a certificate carries pre-state inclusion, post-state absence by adjacency, and a chain link into an append-only erasure ledger. It verifies with nothing but itself, revealing only the erased identifier and its two post-state neighbours' identifiers — content addresses, never contents. Consent scopes and retention classification remain unimplemented and keep the MAY.

Open question: the adjacency proof reveals two neighbouring identifiers. Is that acceptable disclosure for every deployment, or does a class of store need the zero-knowledge variant?

Source: K Pillar 5, K Pillar 6 · Test: TC-WISP-14

5. Relationship to the Specification

This Standard names four things it does not define. Each is defined in SF-WISP-SPEC-001:

The Specification also contains the eight-dimensional temporal encoding, the semantic header's field set, the token's field layout, and the reference thresholds. None of those are requirements. They are one coherent way to satisfy the requirements above, published so an implementer has something concrete to read against — and marked throughout as reference rather than normative.

6. Open Questions for the Working Group

• Is WISP-1's floor of one additional modality correct, or should CORE require two?
• Should WISP-5 require cryptographic signing of token fields, given that signing imports a key-management obligation the callback-free property was designed to avoid?
• Should WISP-7 bound the half-life range, or is bounding it a deployment decision?
• Should refusal-to-measure (WISP-8) be surfaced as a fifth decision state alongside the four of WISP-3? It is operationally distinct from deny — one says the subject failed, the other says nothing was asked — but a fifth state changes every token, record and audit format carrying a decision tag.
• Is the list of invariants in WISP-11 complete, or are there invariants a replaceable component could violate that it does not cover?
• WISP-2 truncates the identifier to sixteen bytes. Is that the right trade for a content address that also appears in lineage chains, where a collision would silently graft one object's history onto another?
• How are multi-party decisions represented — one object per participant, or a composite with several subjects? Inherited unresolved from AGI-4.
• What interoperation profiles are wanted with existing identity frameworks, and do any of them defeat WISP-5?

7. References

Normative. U.S. Patent No. 12,688,267 B1, Systems and methods for multi-modal semantic identity authentication and governance, issued 21 July 2026 (application 19/308,229). — U.S. Provisional Application 63/997,636, Kronos: governance-native temporal encoding, filed 5 March 2026. — RFC 2119; RFC 8174. — SF-WISP-SPEC-001, the WISP Specification.

Informative. SF-AGI-STD-001, The AGI Standard, requirements AGI-4, AGI-5, AGI-6, AGI-8, AGI-10.