SMART Architecture: Stratified Monotone Action Runtime for TrajectoryOS

SMART Architecture: Stratified Monotone Action Runtime for TrajectoryOS

> Contract Statement: Orbit grants capability, FunctionGemma proposes, RAG++ advises, but only the Kernel can commit.

---

1. Executive Summary

SMART (Stratified Monotone Action Runtime) is the execution architecture for TrajectoryOS that brings Clarity-like guarantees to energetic, always-on workflows. It separates the system into three distinct authority rings:

The local FunctionGemma model acts as a syscall compiler: it translates natural language into structured tool calls but has no authority to execute anything. All execution flows through the Kernel.

---

2. System Philosophy

2.1 Clarity-Like Guarantees for Energetic Workflows

Traditional smart contract languages (like Clarity) achieve safety by making programs fully analyzable before execution: no hidden control flow, no unbounded loops, no runtime surprises. SMART adapts these principles to continuous, always-on systems:

The key insight: time cannot be frozen in energetic workflows, so instead of eliminating time, SMART domesticates it through layer gates and maturation delays.

2.2 The Core Invariant

> "The model can be as creative as you want, because creativity never equals authority. Authority is the Kernel's decidable, bounded transition system, and the Kernel is what touches reality."

Intelligence operates by probing the boundary of what is currently admissible, not by writing scripts. The Kernel continuously evaluates what is possible right now and refuses everything else.

---

3. Authority Model: Three Rings

3.1 Ring 1: Orbit (Governor)

Role: Policy and capability management

Orbit knows:
- What project am I in?
- What session is active?
- What phase am I in?
- What permissions should exist here?

Orbit dynamically generates the tool list that FunctionGemma is allowed to call in the current context:

Key Operations:
- `issue_scope_token(project, session, context) -> ScopeToken`
- `get_allowed_tools(scope) -> Vec<ToolSchema>`
- `revoke_scope_token(scope_id)`

3.2 Ring 2: RAG++ (Library)

Role: Memory substrate and retrieval

RAG++ owns:
- What do we remember?
- How do we retrieve it fast?
- How do we fuse signals across modalities?

RAG++ is powerful but never sovereign. It can:
- Answer queries about past state
- Compute embeddings for new content
- Return context bundles for decision-making
- Score trajectory relevance

RAG++ cannot:
- Mutate files or state
- Execute actions
- Grant permissions

Key Tools (exposed to FunctionGemma via Kernel):
- `rag.search(query, filters) -> candidates`
- `rag.assemble_context(candidate_ids, budget) -> context_bundle`
- `rag.validate_applicability(doc_id, repo_state) -> bool`

3.3 Ring 3: Kernel (Executor)

Role: Execution authority and ledger

The Kernel is the only component that can:
- Accept or reject proposed tool calls
- Execute syscalls that touch reality
- Write to the append-only ledger
- Advance layer frontiers
- Enforce time gates

The Kernel is intentionally boring and decidable. It does not reason, plan, or improvise. It evaluates admissibility and either commits or refuses.

---

4. Tool Layers

Tools are partitioned into layers L0 through L4. The plus-one rule ensures you can only move up one layer at a time. Higher layers require more evidence and longer maturation delays.

4.1 Layer Definitions

4.2 Layer Examples

Layer 0 (Observe):
- `fs.scan(path)` - Walk directory tree
- `fs.hash(path)` - Compute file hash
- `rag.search(query)` - Query memory
- `orbit.get_context()` - Get current project state

Layer 1 (Interpret):
- `embed.compute(text)` - Generate embeddings
- `cluster.duplicates(items)` - Find similar items
- `infer.superseded_docs(docs)` - Detect stale documents

Layer 2 (Structure):
- `propose.patch(file, diff)` - Generate patch artifact
- `propose.move(src, dst)` - Generate move plan
- `propose.redirects(old, new)` - Generate redirect headers

Layer 3 (Apply):
- `apply.patch(proposal_hash)` - Apply verified patch
- `apply.move(proposal_hash)` - Execute move plan
- `db.upsert(record)` - Write to database

Layer 4 (Transform):
- `fs.quarantine(path)` - Archive/remove files
- `fs.compact(dir)` - Compress directory structure
- `rebuild.index()` - Full index reconstruction

4.3 Time Gates

Time gates enforce minimum delays between layer transitions. After executing an L1 tool, you must wait 2 seconds before any L2 tool becomes admissible. This ensures:

1. State stabilization: The world has time to settle
2. Human review opportunity: Escalation isn't instant
3. Evidence freshness: Lower-layer outputs are current

---

5. FunctionGemma: The Syscall Compiler

5.1 Role

FunctionGemma is a 270M parameter model trained specifically for function calling. It:
- Receives user instructions + tool schemas
- Emits structured function calls
- Optionally summarizes tool responses

FunctionGemma is not a general chat assistant. It behaves like a compiler front-end: deterministic, schema-correct, and fast.

5.2 Integration Pattern

User Instruction + Tool Registry
         │
         ▼
   FunctionGemma (local)
         │
         ▼
   ProposedCall (structured)
         │
         ▼
   Kernel (VM)
         │
    ┌────┴────┐
    │ Reject  │ Admissibility check fails
    └────┬────┘
         │
         ▼
   Execute Syscall
         │
         ▼
   Write Ledger
         │
         ▼
   Return Receipt

5.3 Control Token Protocol

FunctionGemma uses strict control tokens:

<start_of_turn>developer
<start_function_declaration>
{tool_schema}
<end_function_declaration>
<end_of_turn>

<start_of_turn>user
Clean up my docs folder
<end_of_turn>

<start_of_turn>model
<start_function_call>
{"name": "fs.scan", "args": {"path": "/docs"}}
<end_function_call>
<end_of_turn>

<start_of_turn>tool
<start_function_response>
{"files": [...], "count": 42}
<end_function_response>
<end_of_turn>

---

6. The Execution Contract

6.1 What Each Component Can Do

6.2 Authority Transitions

Orbit issues ScopeToken
         │
         ▼
ScopeToken binds to FunctionGemma session
         │
         ▼
FunctionGemma proposes calls within scope
         │
         ▼
Kernel validates scope + admissibility
         │
         ▼
Kernel consults RAG++ (read-only)
         │
         ▼
Kernel executes syscall (if admissible)
         │
         ▼
Kernel writes to ledger (append-only)
         │
         ▼
Receipt returned with ledger sequence

6.3 Non-Turn-Complete Execution

SMART is not turn-based. The Kernel is always running, continuously evaluating which tools are admissible given current state. This means:

• No waiting for "turns" to complete
• Actions become possible when conditions are met
• Escalation happens at the pace of state maturation, not model speed

---

7. Safety Properties

7.1 Decidability

Every admissibility check is finite and computable:
1. Is the scope token valid? (expiry check)
2. Is the tool within allowed layers? (frontier check)
3. Has the time gate elapsed? (timestamp check)
4. Is there budget remaining? (cost check)
5. Is the monotone step within bounds? (loop prevention)
6. Does the scope permit mutation? (permission check)
7. Is the snapshot fresh enough? (staleness check)
8. Are the arguments valid? (schema check)

7.2 Bounded Cost

Every syscall declares:
- Worst-case compute cost
- Expected duration
- Resource requirements

The Kernel tracks consumed budget and refuses calls that would exceed limits.

7.3 Reversibility Tracking

Each syscall declares its reversibility:
- `ReadOnly`: No state change
- `ProposeOnly`: Produces artifact, no mutation
- `Reversible`: Can be undone (patch inverse, restore from snapshot)
- `Irreversible`: Requires snapshot/quarantine first

7.4 Ledger Immutability

The ledger is append-only. Every committed call records:
- Call ID and tool ID
- Arguments and scope token
- Input snapshot hash
- Output artifacts
- Timing and cost
- Rollback data (if reversible)

---

8. Relationship to Existing Systems

8.1 TrajectoryOS

SMART is the execution layer of TrajectoryOS. TrajectoryOS provides:
- Sensors and importers (motion, notes, photos)
- Storage and memory fabric
- Trajectory coordinate system
- Session and project management

SMART provides:
- Safe tool execution
- Authority boundaries
- Auditability and rollback

8.2 Echelon

Echelon operates at millisecond timescales for real-time motion. SMART operates at second-to-minute timescales for deliberate actions. They are conjugate:

8.3 CognitiveTwin

CognitiveTwin learns user reasoning patterns and style. SMART doesn't replace CognitiveTwin—it provides a safe execution substrate for actions that CognitiveTwin might recommend.

---

9. Future Directions

9.1 Fine-Tuning FunctionGemma

Google's Mobile Actions benchmark shows 58

9.2 Multi-Agent Coordination

Multiple FunctionGemma instances could operate on different machines, all submitting proposals to a shared Kernel. The ledger provides serialization and conflict resolution.

9.3 Hierarchical Kernels

For distributed deployments, a local Kernel could handle immediate operations while a cloud Kernel handles cross-device coordination, with the ledger providing eventual consistency.

---

10. Summary

SMART brings Clarity-like safety guarantees to energetic, continuous workflows:

1. Stratified: Tools are layered by privilege and reversibility
2. Monotone: State progression prevents loops and cycling
3. Action: Focus on executable primitives, not reasoning
4. Runtime: Always-on, non-turn-complete execution

The result is a system where intelligence can be creative and expansive while execution remains deterministic, auditable, and safe.

> "This is not an AI agent. This is a computable action calculus: finite, auditable, priceable, and safe to run on real machines that touch real data."