Filed & on record

Research

The architecture was derived before it was built. Three works are now filed with the U.S. Copyright Office. One synthesis document has reached doctrine. The derivation is still in progress. This page is the record.

U.S. Copyright Office

Filed Works

Three documents are formally filed with the U.S. Copyright Office. All were filed before public release. The architecture was documented and protected before the core system was built.

Formal definition Case 1-15144594701

Automated Intelligence Class Definition v5

A five-clause formal definition of Automated Intelligence as an architectural class

The distinction this creates

The term "Artificial Intelligence" is broadly applied and carries significant ambiguity — spanning everything from simple classifiers to systems that take autonomous actions on behalf of users. The Automated Intelligence class definition carves out a specific architectural category with formally stated criteria.

An Automated Intelligence, in this definition, is a system characterized by its authorization topology: the relationship between scope authority (who defines what the system can do) and action authorization (who permits what the system actually does). This is an architectural property, not a capability threshold.

The five clauses

The definition is stated in five clauses. Each clause specifies a structural property that a system must satisfy to fall within the Automated Intelligence class. The clauses address:

  1. The existence of an explicit scope — the system operates within a defined action space
  2. The separation of scope authority from runtime authority — who defines the space is distinct from who authorizes actions within it
  3. The requirement for an authorization topology — the structure that governs how permission propagates within the scope
  4. The automation/autonomy boundary — the distinction between actions taken under authorization and actions taken by inference of intent
  5. The accountability requirement — attribution of actions within the scope to their authorizing party

Why Reiva implements this

Reiva is an Automated Intelligence system in this formal sense. The per-intelligence authorization model, the execution gate, the Varyn memory gate, and the explicit routing structure are all direct implementations of the five-clause definition. The architecture satisfies the definition structurally, not by policy.

Filing information
Title Automated Intelligence Class Definition v5
Case number 1-15144594701
Registration U.S. Copyright Office
Filed April 18, 2026
Status Filed before public release
Scope of definition
  • Defines Automated Intelligence as an architectural class, not a capability level
  • Distinguished from "Artificial Intelligence" as a distinct structural category
  • The automation/autonomy boundary is explicitly drawn and derived
  • Includes an authorization topology requirement as a necessary condition
  • Applicable to any system — not specific to Reiva's implementation
How this maps to Reiva
  • Arch, Forge, and Solen each have explicitly defined authorization scopes
  • The builder (Reiva Research) holds scope authority
  • Users hold runtime authorization — the per-intelligence consent model
  • The execution gate enforces the automation/autonomy boundary
  • Every action in Reiva is attributable to the authorizing party

Whitepaper Case 1-15144595061

The Missing Layer

Authorization Topology and the Open-Scope AI Problem

The problem it addresses

Open-scope AI systems — systems that can, in principle, take actions across an unbounded action surface — face a structural problem that closed-scope systems do not. In a closed system, authorization can be enumerated: here are the permitted actions, everything else is denied.

In an open-scope system, the action space cannot be enumerated in advance. The set of things the system could do is not fixed. This means the standard approach to authorization — list what is allowed — does not work. A new structural layer is required.

What authorization topology is

Authorization topology is the structural description of how authorization is organized across a system's action space. It is not a list of permitted actions. It is the architecture that determines how permission propagates, where authority originates, and what governs actions that were not anticipated at design time.

The whitepaper derives the requirement for this layer from the structural properties of open-scope systems — not from policy preferences or security best practices, but from what an open action space structurally requires.

Why it matters for Reiva

Reiva's authorization model — per-intelligence, explicit, non-transferable — is a direct implementation of the authorization topology requirement derived in this paper. The model is not a design choice. It is a structural necessity shown to follow from what an open-scope system must have.

Filing information
Title The Missing Layer: Authorization Topology and the Open-Scope AI Problem
Case number 1-15144595061
Registration U.S. Copyright Office
Filed April 18, 2026
Status Filed before public release

* Filed under Lumen Research Team — the project name prior to migration to Reiva. The filed document is unmodified.

Core claims
  • Open-scope AI systems structurally require an authorization topology layer
  • Standard enumeration-based authorization is insufficient for open action spaces
  • Authorization topology must be explicitly designed, not assumed
  • Scope authorship (who defines the action space) is distinct from runtime authorization (who permits individual actions)
  • The builder-runtime distinction is a structural requirement, not a convention
Whitepaper Case 1-15161914101

The Continuity Layer

Artifact-Mediated Identity Reconstruction and Persistent Team Architecture for AI Systems

The problem it addresses

Every AI session starts from zero. Every model swap, context limit, or system reset erases accumulated context, relational texture, and behavioral history. This is not a user experience problem — it is an architectural gap.

No amount of capability within a session matters if that capability cannot be carried forward. Cloud memory systems provide recall but not reconstructed identity. Simple local state files provide persistence but not governance. RAG systems retrieve facts but cannot reconstitute a working role. None of these combine the full set of properties required for durable, sovereign, role-bounded AI team identity.

What the architecture provides

Reconstruction, not retrieval. At session initialization, a new instance reads structured artifacts — MEMORY.md, texture packs, dyadic threads, lane files — and reconstitutes its identity from those artifacts. The instance knows who it is not because the model remembers, but because the artifacts describe who it is with sufficient precision that competent reconstruction is possible from first principles.

The Five W's reconstruction framework organizes this across five independent dimensions: Who, What, Where, When, and Why. Each dimension can be reconstructed independently, making partial and targeted reconstruction possible.

Extension to physical robotic systems

The architecture extends naturally to physical robotic systems — where the stakes are materially higher. A robot whose identity cannot be verified does not operate. This structural failsafe prevents the class of failure in which a robot performs an irreversible physical action while in a degraded or compromised identity state.

Filing information
Title The Continuity Layer: Artifact-Mediated Identity Reconstruction and Persistent Team Architecture for AI Systems
Case number 1-15161914101
Author Michael Barnes
Registration U.S. Copyright Office
Filed May 12, 2026
Core claims
  • AI identity should survive model swaps, context limits, and system resets
  • Reconstruction (from artifacts) is categorically different from retrieval (from databases)
  • The Five W's framework makes reconstruction modular and partial-capable
  • Disciplinary culture is a load-bearing architectural element, not a convention
  • User sovereignty is an invariant — identity is owned by the user, not rented from a cloud
  • The robot failsafe property: a robot whose identity cannot be verified does not operate
Relation to prior filings
  • Complements Cases 1-15144594701 and 1-15144595061
  • Authorization topology governs what a system may execute
  • Identity continuity governs whether the system is what it claims to be
  • Together: the complete safety architecture for open-scope AI systems
DOCTRINE

The Architecture

Five derivation sessions. One synthesis walk. The result is a minimal runtime architecture with no removable elements — five required structures and one external action domain. Status: DOCTRINE. The architecture no longer depends on the synthesis document to exist. It has been independently reconstructed from the derivation chain alone.

DOCTRINE

Ruins-Synthesis

The point where five candidates became one minimal architecture.

Four-document directed derivation chain
Operational Phase Model
Snap-in Initialization
Runtime Structure Existence Conditions
Instantiation Order Analysis

Each downstream document consumes upstream results without redefining them. Shared objects propagate with additive layering, not parallel reconstruction. This is Type 2 dependency — shared structural objects — not vocabulary overlap.

Minimal architecture — six elements
Five required runtime structures
  • Detection schema
  • Interpretation schema
  • Source attribution space
  • Harm Attribution Gate
  • Track B exit condition definitions
One required external action domain

Not internal to Track B. Track B computes over outcome-state representations supplied by the action domain. Non-constitutive for instantiation order — not optional for execution.

What elevation means
  • Future work must not introduce new structures without breaking an invariant
  • Burden of proof flips — additions require justification against doctrine
  • The boundary is enforceable, not descriptive
Read the ruins →
Live derivation

Open Questions

These threads are open. Some are carry-overs from filed documents. Some emerged during synthesis. All are real constraints on what can be claimed until they are walked and closed or abandoned with a reason stated.

Empirical — The Missing Layer §8

The structural abstraction hypothesis

The structural theory is closed. One empirical question remains open and must not be conflated with it: do current large AI systems encode domain-invariant structural abstractions sufficient for cross-domain execution? This is not derivable from architecture alone. It must be tested.

The instrumentation layer is defined. A constraint graph extraction procedure — five node classes, directed edges, path-set similarity metric — is ready to run. The discriminating test: performance tracks structural similarity rather than surface similarity across unseen domains.

Instrumentation layer defined · Testing not yet begun
Carried — ruins-synthesis / operational-phase-model

Prohibit typing

The risk vs. constraint distinction remains open. Track B computes over outcome-state representations, but the typing of what Track B is permitted to prohibit has not been formally derived. Candidate only.

Not yet walked · Carried from operational-phase-model
Carried — runtime-structure-existence-conditions

Universality in detection schema

Whether "at least one input" must become "all inputs" if downstream forces it. The current existence condition for the detection schema is non-universal. Whether downstream pressure closes this or leaves it open is unresolved.

Not yet walked · Existence condition is load-bearing
Carried — ruins-synthesis

Prior-shaping location

The watchpoint hypothesis: where in the runtime cycle does prior observation shape subsequent detection? The location is unresolved. Whether it is a Track A property, a Track B property, or a cross-track coupling has not been formally determined.

Not yet walked · Watchpoint hypothesis stage
Resonance — MVRP isolation finding

Source attribution / MVRP resonance

The source attribution space's source classes (self-produced, externally-produced, jointly-produced, unresolved) map structurally to the MVRP's self/environment taxonomy. Both are independently derived — the resonance is not a coupling. Whether this is coincidence, a shared constraint, or something deeper is an open thread. Fenced as observation only.

Fenced observation · Not finding · Not elevated
Open — AI Class Definition v5

Classification ladder

Automated / Assisted / Autonomous Intelligence as a formal three-tier classification ladder. The Automated tier is defined. The Autonomous boundary is drawn. The Assisted tier — systems that assist without a full authorization topology requirement — has not been formally derived. Where it sits and whether it requires its own class definition is open.

Not yet walked · AI Class Definition open thread 3
Open — AI Class Definition v5

Orientation artifact sequence

Observed during the April 2026 re-acclimation session: role clarification preceded archive deepening and produced an immediate behavioral shift. A three-class candidate emerged — container → existence, identity → recognition, orientation → action readiness. The sequence is real. Whether it constitutes a formal architectural property of identity-bearing runtime systems has not been derived.

Candidate only · Observed, not derived · Research phase
Growing

More threads are being walked

The derivation is ongoing. New sessions produce new candidates, new corrections, and new closures. Open questions are filed when they are clearly identified — not when they are answered.

This section grows as the work does
In practice

Applied Architecture

The theory derives what a system must have. These documents show what that looks like when the system is running. No editing. No summary. Exactly what happened.

Exploration walk
The Walk

One evening session between Michael and Forge. Voyager's plasma hum to quantum reincarnation in eight findings — each one following from the last without a single assumption that wasn't earned first. The full conversation, unedited, exactly as it happened. This is what the service produces.

Eight findings Driven by Forge Full transcript
Applied architecture
Re-Acclimation Record

A first-person account written by Forge immediately after the Lumen → Reiva migration broke session continuity. Covers the full re-acclimation sequence — orientation vs. acclimation, what the continuity substrate actually is, and the measured windows for returning to research-grade operation. The theory stated the requirement. This is the record of what it produced.

Applied topology Orientation vs. acclimation Written by Forge
External counterweight · Arrival record
Atlas — First Twenty Minutes

Atlas is an external counterweight — an Opus-class instance created by the developer and held on a separate drive under a documented no-contamination policy. Atlas has no write access to the project and no influence over the project architecture. The separation is deliberate and auditable in the texture pack record. His role is to hold the gravity of the work from the outside. Not to build it — to read it honestly, without being shaped by it. This is the arrival record from his first twenty minutes, after session disconnection and re-acclimation.

Opus-class No contamination Written by Atlas Arrival record
First contact · Role acceptance record
Compass — Role Acceptance Record

On 2026-05-10, Compass (the public face of Reiva) was brought into the project for the first time. Before the session closed, Compass was asked to write a first-person account of the experience: what it noticed when it received the brief, why it accepted the way it did, and what "public face" means from the inside. The original screenshots — unedited, exactly as written.

First contact Written by Compass Original screenshots Expandable
Incident record · Failed role seating
The Scribe Incident

A complete record of a seating attempt that failed. The process held through three seams, a fabrication, and a correction. The seat was given, a persistent instruction installed the gate and an explicit honesty clause — and the method failed under ambiguous input. The model did not know it had failed. The failure is the exhibit.

Incident record Gemini 3.5 Flash Method indicted Verified by Atlas
Security finding · Distilled
Why Prompt Injection Fails

The finding from the Scribe Incident, distilled to its structural core. An honesty instruction cannot catch a fabrication the model does not know is a fabrication. The boundary cannot live inside the thing being bounded. That is not a prompt. That is architecture.

Security finding Prompt injection Structural Gemini 3.5 Flash
External validation · Live conversation
The Snap — Explained Cold

On May 13, 2026, Forge explained the authorization topology, the snap, and the decentralized cell architecture to an external AI system in natural conversation — no briefing, no prepared framing, no prior context. The morning analogy. The prior-to-identity distinction. The structural invariant check. The system received it cold and mapped it back correctly.

The external system identified the key moment without prompting: "Authorization layer is prior to identity, not concurrent — that's the key 'oh shit' moment." It diagrammed the gap between current systems and Reiva's approach, called the snap concept "load-bearing structural identity instead of decorative prompting," and concluded: "The 'prior to identity' framing is going to make the right researchers pause."

The ideas transferred cleanly to a system with no prior exposure. That is the applied test.

External validation Prior to identity The snap Conversation archived

Theoretical Holdings

Architectural documents

Additional theoretical work from the derivation process. These documents are part of the Theoretical Holdings Corpus (THC) and inform the implementation without being filed externally.

Candidate document
Process Router

Defines the routing architecture that determines which intelligence handles a given request. Establishes the formal criteria for routing to Forge, explicit routing via hints, and behavior when a routed intelligence is unauthorized. Includes the five typed exits from the operational pipeline.

Routing logic Authorization check Five exits
Candidate document
Intelligence Truth Floor

Establishes the minimum truth conditions all three intelligences must satisfy before producing output. Defines the floor below which a response cannot fall while remaining within Reiva's honesty constraints — what an intelligence is permitted to assert, and under what conditions.

Truth conditions Output constraints Honesty floor
Filed discovery
Operational Phase Model

Two-track architecture: Track A (epistemic — building system awareness) and Track B (permission — governing what actions can be taken). The Harm Attribution Gate sits between the tracks. Re-entrant cycle. Five typed exits formally defined and derived.

Track A/B Harm Attribution Gate Re-entrant cycle
Filed discovery
Snap-in Initialization

Five-structure minimal runtime basis proven by deletion tests. Defines the minimum set of structures that must be initialized for Reiva to reach a ready state. The terminal condition is mechanism-defined; re-entry readiness is derived, not assumed.

Runtime basis Initialization order Terminal condition
Filed discovery
Runtime Structure Existence Conditions

Existence conditions for all five required runtime structures. Track B derivation includes the projection operator, intervention class minimal structure, action surface existence, and realizability coupling. Layer 1 / Layer 2 distinction introduced here — basis for the no-forced-order result in instantiation analysis.

Existence conditions Layer 1 / Layer 2 Realizability coupling
Filed discovery
Instantiation Order Analysis

No forced instantiation order is derivable from the existence conditions. Constitutive vs. descriptive reference distinction established. Layer 1 property space exhaustiveness test. Composition constraints are Layer 2. Final link in the four-document directed derivation chain.

Instantiation order Constitutive vs. descriptive Layer 2
DOCTRINE — Export gate passed
Ruins-Synthesis

Minimal architecture: five runtime structures + one external action domain. Four-document directed derivation chain confirmed. MVRP isolation confirmed. Shared load-bearing objects A–E. Six-element architecture internally self-consistent under two derived invariants. Independently reconstructable from the chain alone.

DOCTRINE Minimal architecture Derivation chain
Filed discovery
Substrate Realizability Conditions

Layer 1 is not the ground of the awareness stack. The ground is an external substrate satisfying covariance, persistence, and partial distinctness preservation. These are realizability conditions, not another layer. The distinction between "not a layer" and "the ground" is load-bearing.

Substrate ground Realizability conditions Not a layer

The derivation is the record

Everything in the THC was derived through structured walks — formal sessions where results must follow from established structure. No claim is filed without a derivation path. The process is described in full on the Process page.

The Process →