Skip to content

Reflexive Layer

Overview

ARVIS provides an explicit Reflexive Layer: a deterministic, read-only system for safe introspection, observability, explanation, and compliance-oriented self-description.

This layer exists after cognition and never participates in decision formation.

It enables ARVIS to inspect, explain, and expose its own structure without compromising determinism.


Core Principle

Reflexive systems observe cognition.
They do not perform cognition.

The Reflexive Layer has:

  • no decision authority
  • no side effects
  • no mutation privileges
  • no hidden execution path
  • no access escalation

It is strictly observational.


Architectural Position

The Reflexive Layer operates after finalized cognitive execution.

Input
→ Kernel / Runtime
→ Cognitive Pipeline
→ CognitiveState
→ IR
→ Trace / Timeline
→ Reflexive Layer
→ Safe External Views

It consumes canonical outputs and produces safe introspection artifacts.


Why It Exists

Most AI systems expose only:

  • raw logs
  • opaque probabilities
  • post-hoc explanations
  • unstructured traces

ARVIS instead exposes structured reflexive artifacts.

This enables:

  • trustworthy introspection
  • deterministic explainability
  • operator visibility
  • compliance evidence
  • replay-aware diagnostics

Main Components

1. Reflexive Snapshots

Canonical read-only snapshots describing the system after execution.

Examples:

  • active architecture profile
  • runtime mode
  • exposed capabilities
  • execution context summary
  • safety posture

Implemented through:

reflexive/snapshot/

Attestation contract (a17, canonicalization 2.0)

The final public payload verifies its own attestation directly: arvis.verify_reflexive_attestation(result.reflexive) recomputes the FULL attestation from the payload exactly as exposed and compares the entire embedded block to the recomputed one: exact key set, exact values for every metadata field (type, scope, authority, flags, mode, exposed_views, canon_version), and a constant-time comparison for the fingerprint. An unknown canon_version is refused before any algorithm is applied, and any malformed input of any type returns False.

Canonicalization 2.0: the attestation key is excluded from its own fingerprint; generated_at, mode, exposed_views and timeline_views are removed from the payload body; timeline views are re-attested filtered to the exposed set; exposed_views is attested sorted; mode and canon_version are attested members of the canonical source, so neither can be rewritten, even consistently across the payload and the block, without changing the fingerprint; the source is hashed as compact sorted-keys JSON with SHA-256. generated_at is the only top-level volatile field and is excluded: deterministic means the fingerprint is a pure function of the canonical source; identity across separate runs is not claimed.

Structural integrity, not authenticity. The fingerprint is an unsigned SHA-256 with no secret: it proves a payload matches its embedded attestation, provided that attestation is already trusted. It does not authenticate the emitter, does not prove ARVIS origin, and does not resist an actor able to rewrite the whole document, checksum included. Proving authenticity requires an external anchor held by the host: a signature, an HMAC, a commitment stored in a durable journal, or a fingerprint obtained through an independent channel.

Serialization contract (a15)

The snapshot serializes the cognitive state structurally: dataclass trees, enums, tuples and datetimes render canonically. A live object with no serialization contract (the in-state signal journal, an observer) surfaces as a deterministic opaque marker (<unserialized:TypeName>), never as an exception: the nominal run path always produces the reflexive payload and its attestation (audit a14, A14-P1-01). The curated timeline exposure goes through the role-filtered timeline_views channel, never through the raw state.

2. Introspection Services

Structured introspection of specific domains.

Available domains include:

  • architecture introspection
  • cognition introspection
  • runtime introspection
  • uncertainty introspection
  • math / stability introspection
  • world-model introspection
  • decision introspection
  • counterfactual introspection

Implemented through:

reflexive/introspection/

3. Capability Registry

ARVIS can expose what it is capable of doing in a deterministic and declarative form.

Examples:

  • supports replay
  • supports IR export
  • supports timeline commitments
  • supports tool execution
  • supports reflexive rendering

Implemented through:

reflexive/capabilities/

This allows external systems to inspect capability posture safely.


4. Timeline Reflexive Views

ARVIS can inspect execution history through safe timeline projections.

Examples:

  • temporal comparisons
  • execution deltas
  • behavioral trends
  • stability evolution
  • historical summaries

Implemented through:

reflexive/timeline/aggregation/
reflexive/timeline/explanation/

5. Compliance & Attestation

The Reflexive Layer can emit compliance-oriented evidence describing system behavior.

Examples:

deterministic execution support traceability support replay support decision boundary guarantees architectural separation guarantees

Implemented through:

reflexive/compliance/

6. Reflexive Rendering

Structured introspection outputs (frozen snapshots, attestations, timeline explanations) are machine-readable by construction; readable views (operator dashboards, audit summaries, explainability reports) are rendered by the host from those payloads. There is no rendering package inside arvis: rendering is host territory by design.


What the Reflexive Layer Reads

The Reflexive Layer may consume:

  • CognitiveState
  • IR
  • DecisionTrace
  • Timeline entries
  • Capability registries
  • Runtime metadata
  • Stability summaries

All inputs are post-execution artifacts.


What It Must Never Do

The Reflexive Layer MUST NOT:

  • change decisions
  • re-run cognition silently
  • mutate memory
  • call tools autonomously
  • inject hidden context
  • override gate verdicts
  • alter IR semantics

Determinism Guarantees

Given identical finalized cognition and identical configuration, reflexive outputs must remain deterministic.

This includes:

  • snapshots
  • explanations
  • capability views
  • rendered summaries
  • compliance attestations

Relation to CognitiveState

Layer Role
CognitiveState internal canonical truth
Reflexive Layer safe self-observation of truth

The Reflexive Layer may read the CognitiveState but does not define it.


Relation to IR

Layer Role
IR portable machine contract
Reflexive Layer introspection and explanation system

IR is the external execution artifact. Reflexive outputs are higher-level structured views derived from canonical artifacts.

This is complementary, not redundant.


Relation to Timeline

The timeline records execution commitments and history.

The Reflexive Layer interprets timeline history into:

  • comparisons
  • trends
  • summaries
  • temporal diagnostics

Security Model

The Reflexive Layer follows strict safety constraints:

  • read-only by design
  • no authority escalation
  • no hidden cognition path
  • no raw memory leakage
  • deterministic outputs only

Why This Matters

ARVIS is not only able to decide under constraints.

It is also able to explain how it decided, what it can do, and how it evolved, without becoming non-deterministic.

That combination is rare.


Example Mental Model

Pipeline computes cognition
State stabilizes cognition
IR exports cognition
Reflexive Layer explains cognition

One-Line Summary

The Reflexive Layer allows ARVIS to observe itself safely, deterministically, and without altering cognition.