Status

This document defines the current structural architecture of Substrate aligned with the MVP + immediate post-MVP trajectory.

It is intentionally:

• concrete
• minimal
• stage-aware
• non-speculative

It separates:

• what exists
• what is partially implemented
• what is explicitly NOT active yet

This is not a vision document.
This is a system structure map for execution and governance alignment.

0. Architectural Principle

Build only the layers required to prove the mechanism.

Corollaries:

• No layer exists “for future use” unless inert
• No structure is activated before signal exists
• No system is assumed because it is designed

1. System Overview (Layered)

Substrate is composed of four active layers (MVP) and four latent layers (post-MVP).

1.1 Active (MVP / Immediate)

1. Interaction Layer (Chat)
2. Artifact Layer (Persistence)
3. Retrieval Layer
4. Reuse Layer (in progress / validated)

1.2 Latent (Post-MVP, NOT ACTIVE)

5. Reasoning Structure Layer (claims, decomposition)
6. Governance Layer (status, validation, authority)
7. Trace Layer (lineage, provenance, audit)
8. Execution / Harness Layer (enforcement, gating)

Critical rule:

Latent layers must not leak into active implementation.

2. Active Layers (Current System)

2.1 Interaction Layer (Chat)

Purpose

Primary interface for user reasoning.

Responsibilities

• accept user input
• constrain interaction (Aalam behavior)
• produce structured outputs

Constraints

• no implicit memory
• no hidden reuse
• no authority

Failure Modes

• over-generation
• false confidence
• implicit continuity

2.2 Artifact Layer

Definition

Artifact = persistent output derived from interaction

Minimal Schema (Current)

• id
• content
• created_at
• source_reference

Responsibilities

• store outputs
• allow retrieval
• enable reuse

Constraints

• must be human-readable
• must be reusable without reconstruction

Failure Modes

• weak structure (chat fragments)
• loss of interpretability
• misleading completeness

2.3 Retrieval Layer

Purpose

Enable access to stored artifacts.

Responsibilities

• list artifacts
• fetch artifact by id
• preserve fidelity

Constraints

• no transformation
• no mutation
• no implicit reuse

Failure Modes

• mock data
• stale data
• wrong-but-plausible retrieval

2.4 Reuse Layer

Purpose

Enable explicit reuse of artifacts in new interactions.

Responsibilities

• inject artifact into prompt context
• make reuse visible
• preserve original artifact

Constraints

• must be explicit
• must be user-controlled
• must be visible

Failure Modes

• hidden reuse
• no actual influence on output
• mutation of source artifact

3. Data Flow (Current)

User Input
   ↓
Chat (Aalam)
   ↓
Output
   ↓
Artifact Creation
   ↓
Storage (DB)
   ↓
Retrieval
   ↓
Reuse Injection
   ↓
New Chat Output

Critical requirement:

Every transition must be observable.

4. Boundary Conditions

4.1 Execution Boundary

Substrate does NOT execute actions.

It:

• structures reasoning
• produces artifacts

External systems:

• execute decisions

4.2 Authority Boundary

Nothing inside MVP has authority.

Artifacts are:

• outputs
• not decisions

4.3 Memory Boundary

Memory exists ONLY as artifacts.

No:

• hidden session memory
• implicit carryover

5. Latent Layers (Not Active)

These layers are defined but must remain dormant.

5.1 Reasoning Structure Layer

Components:

• claims
• premises
• constraints

Status:

• conceptual only

Activation condition:

• artifacts demonstrate consistent structure

5.2 Governance Layer

Components:

• validation
• status
• authority
• decision events

Status:

• NOT implemented

Activation condition:

• reuse shows measurable value

5.3 Trace Layer

Components:

• lineage
• provenance
• audit trail

Status:

• implicit only (logs)

Activation condition:

• artifacts reused across sessions consistently

5.4 Execution / Harness Layer

Components:

• enforcement engine
• validation gates
• fail-closed controls

Status:

• NOT implemented

Activation condition:

• system begins to influence real decisions/actions

6. Failure Surfaces by Layer

Cross-layer risk:

System appears to work but produces no real improvement.

7. Enforcement Reality (Current)

Most constraints are currently:

• process-enforced
• not system-enforced

Examples:

• explicit reuse → partially enforced
• no hidden memory → enforced by design
• proof requirements → process only

Gap:

Enforcement is not yet embedded in system architecture.

8. Interaction Model (User View)

User experiences:

1. Think through problem (chat)
2. Extract useful output (artifact)
3. Return later (retrieval)
4. Reuse artifact (explicit)
5. Continue reasoning

Key property:

The system externalizes thinking into reusable objects.

9. What This Architecture Enables

If working:

• reduced repetition
• cross-session continuity
• structured thinking
• incremental improvement

If not working:

• artifacts unused
• no improvement vs baseline chat
• system collapses to chat wrapper

10. Immediate Architectural Priorities

1. Artifact quality
2. Reuse visibility
3. Reuse effect on output
4. Cross-session persistence

Not priorities:

• schema expansion
• governance systems
• trace systems
• multi-user features

11. Architectural Anti-Patterns (Must Avoid)

1. Building future layers early
2. Adding structure without signal
3. Hiding system behavior
4. Implicit reuse or memory
5. Treating outputs as authoritative

12. Relationship to Other Documents

• Canon v4 → defines system laws
• Supplemental → defines enforcement, failure, and operational patterns
• System Overview → defines product surface

This document:

defines how the system is actually structured right now

13. Final Principle

The architecture must remain smaller than the uncertainty of the mechanism.

If the mechanism is not proven:

• reduce system
• do not expand

If the mechanism is proven:

• expand one layer at a time