The WISP Architecture

The Problem WISP Solves

Every AI system deployed commercially as a trusted layer of real-world information processing, legal interpretation, medical support, infrastructure management, or creative collaboration must answer a question that no current system adequately addresses. This question is not “is this output accurate?” or “does this model behave well in the training distribution?” The question is: “is this the model the user believes they are interacting with — and is that belief warranted?”

The WISP architecture solves this problem. WISP — Weighted Identity Towards People — is a multi-modal composite attestation practice that allows a deployed AI system to continuously prove, to both users and external verifiers, that the system's behavior pattern matches an expected profile. This practice cannot be forged by an adversary who does not have access to the same substrate, and it degrades gracefully when compromised.

The architecture operates on a composite of inputs that span behavioral, contextual, and intentional signal channels:

The Structure of WISP

WISP comprises or integrates the following primary functions:

• Translation Module — A structured TF normalization of incoming effort across substrate vectors — converting raw behavioral signal into a dimensionally consistent representation that can be compared against a trained reference distribution.
• Active Channel — Linguistic normalization of the active channel of communication, including contextual interpretation of register, intent, and interlocutor model — distinct from output accuracy.
• Behavioral Memory — Meaning of the observed behavioral patterns of the current user, distinct from the behavioral patterns seen in training distribution. This is computed over the active session window and weighted against prior session memory.
• Composition Factor — The mathematical result of applying WISP to all three incoming channels — computed as a geometric mean to prevent any single coefficient from dominating or masking degradation in another.

Each module produces one coefficient. The system computes the composite WISP by combining all three, and if any coefficient is artificially raised, the degradation register fires — it cannot be used as a flywheel effect. A system with WISP = {0.7, 0.62, 0.55} does not produce an average of those coefficients; it is computed as a geometric mean to ensure that any anomaly — any collapse in any single coefficient — pulls the composite downward.

Authentication as Similarity

Authentication, in the WISP architecture, is not a positional lookup. It is a geometry: a proximity measure from the internally observed WISP, to the baseline WISP that the system was tuned for during pre-evaluation calibration.

Authentication succeeds if the observed similarity falls within a distance threshold, validated for consistency of both coefficient distribution and temporal coherence across the active session window.

The metric provides rejection of trivial drift from heavy vectors. In systems this architecture has been tested in, un-calibrated distance measures overstated similarity by up to 3× over the calibrated behavior under genuine drift conditions.

Continuous Coherence Evaluation

WISP is not a positional claim. The system's composite attestation is evaluated continuously. This means authentication is not a gate to pass once at session initiation — it is a live signal. A system that was strongly authenticated five minutes ago and has since drifted can be flagged, challenged, or throttled without user interruption.

• FORWARD — reference to strong, well-functioning, authenticated behavior
• BACKCAST — reference to prior-session behavioral baseline
• RENORM — reference to flagging, calibrating, or resetting normalization
• DEMO — reference to marking output for disclosure or attestation review

The continuous evaluation pass runs on a per-output basis for high-trust deployments and on a per-session basis for standard deployments. In both cases, the resulting WISP coefficient is available for external attestation inspection.

Provenance-Bounded Semantic Memory Graphs

A significant attack vector against attestation systems is memory injection: feeding a system prior context that did not originate within the current provenance chain. WISP addresses this through provenance-bounded semantic memory graphs — a structure that tags all memory elements with their origination metadata and prevents cross-chain injection.

Every memory node in the WISP graph carries a provenance tag: source channel, session fingerprint, and attribution weight. When the system constructs its behavioral baseline for coherence evaluation, it evaluates only memory nodes whose provenance falls within an acceptable chain of custody. Orphaned nodes — injected context, adversarially formatted prior sessions, cross-tenant memory bleed — are rejected from the coherence computation.

This structure is not primarily a security feature. It is a honesty feature: a system that cannot distinguish its own memory from injected memory cannot make truthful claims about its own behavioral continuity.

On EI Detection

One of the architecture's strongest functions is the conjoint drift detection capability — it measures the trajectory of the system's observed WISP coefficient defined over time. Rather than detecting point anomalies (one bad output, one unusual token), WISP detects gradient drift: the slow movement of the system away from its authenticated profile under sustained adversarial pressure or gradual distribution shift.

The conjoint drift function computes the rate of change in the WISP coefficient over a rolling window, weighted by the severity of each sub-coefficient movement. Systems being gradually influenced — through adversarial prompting, fine-tuning attacks, or environmental drift — will exhibit characteristic gradient patterns that WISP is designed to detect before they reach threshold.

Cryptographic Proofing-to-Execution

The architecture also involves developing a cryptographic binding between the WISP composite and the execution trace of the system's outputs. This proofing-to-execution layer ensures that the attestation is not separable from the behavior it attests to: a system cannot produce a valid WISP attestation for an output it did not generate, and cannot generate an output without associating it with the running WISP state at time of generation.

This is implemented through a signed execution manifest: a compact representation of the inference trace, the WISP state, and the output hash, signed at generation time by the system's current attestation key. External verifiers can audit this manifest without access to the model weights or the full inference trace.

The manifest is not a transcript. It does not expose the reasoning process or internal state. It exposes only what is necessary for an external party to confirm: that the output was generated by a system operating within its authenticated WISP range.

Verifiable Provenance Without Central Callback

WISP is model-agnostic and layer-agnostic by design. The WISP framework does not assume a central trust authority. Validity is a local computation: the verifier checks the manifest against the public attestation key, the WISP coefficient, and the behavioral baseline published at system initialization. No central callback is required.

This design decision is intentional. Systems that require central callback for attestation verification create architectural dependencies that can be exploited, censored, or manipulated. A provenance system that fails closed when the callback is unavailable provides security but defeats availability. A provenance system that fails open is not a provenance system.

WISP is designed to be verifiable at the edge, by any party with access to the public attestation parameters, without coordinating with any central authority at verification time.

Mathematical Anchoring

The most effective composition of formal anchored instances of basic architecture creates provenance across substrate layers. WISP achieves this through mathematical anchoring: a set of invariant properties that must hold across all valid WISP computations, regardless of the specific substrate, deployment environment, or evaluation context.

These invariants are formal constraints, not heuristics. A system whose WISP computation violates them is not producing WISP attestations — it is producing signatures that claim to be WISP attestations. The distinction is auditable.

The anchoring layer also provides the formal substrate for inter-system attestation: a mechanism by which one WISP-compliant system can attest to the behavioral state of another, within defined scope constraints. This is the foundation for the multi-agent attestation model described in the companion architecture documents.

Value and Disclosure

The WISP architecture has been developed within the Foundation's stewardship framework and is governed by the IP Custody & Licensing Doctrine. The architecture is disclosed here as a transparency commitment — not as a complete technical specification, but as a structural description sufficient for external parties to evaluate the Foundation's claims about continuous behavioral attestation.

Licensing of WISP-based implementations is available through the commercial licensing entity. All licenses are subordinate to the Source Code and STAN. No licensee receives exclusive rights to the architecture.

— Attestation is not a feature. It is the precondition for trust.

References to Companion Documents

• Source Code Declaration
• STAN Ethical Enforcement Logic
• IP Custody & Licensing Doctrine
• Standards Corpus — Working Drafts