Verified Intent-to-Execution Architecture

Original Corben Sorenson paper published as part of The ASI Stack source and lineage library.

← Corben Papers and Architecture Sources

ImportantOriginal paper, not rewritten book prose

This page publishes Corben Sorenson’s original source manuscript so readers can inspect the ideas that preceded or informed the living book. The text may contain historical terminology, claims, confidence, citations, or implementation status that the book later narrows, revises, tests, or rejects. Publication here establishes provenance and access—not correctness, novelty, replication, or support-state promotion.

Publication and provenance

Field	Record
Source ID	viea
Source class	author paper
Library class	architecture_whitepaper
Manuscript date	Date not normalized
Inventory updated	Not separately recorded
Exact published-source SHA-256	9f49a6d9622c139349cd3c448017e8c17a7a39a525a12019e236969c30c4fc91
Exact published-source bytes	211,471
Exact source text	Download/view the tracked Markdown source
Book’s source note	Read the bounded mining note
Authorship and collaborator credits	Preserved from the exact original manuscript; this library wrapper does not replace or simplify them.
Rights	No new license grant. Corben Sorenson’s rights are reserved; collaborator, quotation, source-title, and third-party rights remain with their holders.

Current publication boundary. Archived author paper; its claims retain the status and limits stated in the paper and do not inherit the living book’s current evidence state.

HTML presentation note. The HTML page normalizes line endings and trailing whitespace, preserves explicit Markdown hard breaks, and demotes manuscript headings beneath the page title. The digest above applies to the linked exact source text, not to this presentation wrapper.

Where this paper enters the living book

ASI Is a Stack, Not a Model, The Efficient ASI Hypothesis, System Boundaries and Authority, Failure Modes of Ungoverned Intelligence, Evidence States and Claim Discipline, Human Intent as a Formal Input, Human Factors and Meaningful Control in Oversight, Stable Capability Fields, Recursive Self-Improvement Boundaries, Command Contracts: From Intent to Executable Work, Planning as a Control Layer: DAGs and Intelligence Arbitrage, Cognitive Compilation and Semantic IR, The Virtual Context ABI: Typed Pages, Cells, and Certificates, Claim Ledgers and Belief Revision, Labor OS and Typed Jobs, Artifact Graphs, Audit Logs, and Replay, Runtime Adapters, Tool Permissions, and Human Approval, Embodied Agency, Real-Time Control, and Physical Safety, Routing Heads and Specialist Cores, Resource Economics and Token Budgets, Executable Specifications and Lean Proof Envelope, Governed Operations, Incident Command, and Graceful Degradation, Adjudicated Persistence and the Adaptive Commit Boundary, Artifact Steward Agents and Living Project Governance, Integrated Reference Architecture, Prototype Roadmap, Living Book Methodology

---

Original manuscript

Tab 1 Verified Intent-to-Execution Architecture A Systems Architecture for Converting Human Goals into Structured Artifacts, Verified Workflows, Runtime Execution, and Feedback White Paper Public Release v1.0 — May 2026 Author: Corben Sorenson Status: Architecture proposal / implementation concept / systems framework ________________

TL;DR / Executive Abstract The central problem this paper addresses is simple: AI systems are good at generating outputs, but weak at turning human intent into durable, verified, executable change. A user can ask an AI for a plan, a document, a code sketch, a design, or a workflow. The system can generate something plausible. But most AI interactions still lack durable artifact memory, explicit verification, specialist routing, workflow compilation, runtime targeting, benchmark-driven improvement, and feedback from deployment. Verified Intent-to-Execution Architecture, or VIEA, is a proposed architecture for closing that gap. The core thesis is: Human intent should be converted into structured command contracts, preserved as artifacts, routed through specialist modules, compiled into the appropriate runtime, verified before execution, and improved through feedback. The basic loop is: human intent ↓ structured command contract ↓ artifact graph ↓ specialist routing ↓ tool / workflow / design / code generation ↓ runtime target ↓ verification gate ↓ deployment / fabrication / execution ↓ feedback ↓ updated artifacts, tools, benchmarks, and specialists

VIEA is not a chatbot. It is not just an agent framework. It is not just a code generator. It is an intent-to-execution system. It has eight primary subsystems: Subsystem Purpose Structured Command Layer Converts vague goals into explicit command contracts. Artifact Graph Stores ideas, claims, critiques, requirements, tools, benchmarks, releases, and feedback as durable artifacts. Claim and Verification Ledger Tracks which claims are verified, speculative, unsupported, contradicted, or requiring experiment. Orchestrator / Router Decomposes tasks and routes work to specialist modules. Specialist Modules Bounded domain subsystems for writing, research, code, CAD, safety, benchmarks, deployment, fabrication, and more. Workflow-to-Tool Compiler Converts repeated successful workflows into verified reusable tools. Evaluation Ratchet Uses benchmarks, regression suites, residual backlogs, and public calibration to guide improvement. Runtime Adapters Compile outputs into digital, hardware, fabrication, robotic, organizational, or spatial/project-workspace runtimes. The architecture’s most important rule is: Nothing important should remain only as a chat response. If it matters, it should become an artifact. If it repeats, it should become a tool. If it claims something, it should receive a support state. If it fails, it should become a residual. If it is mastered, it should become regression coverage. If it is deployed, fabricated, or executed, it should produce feedback. VIEA synthesizes several prior project lines: * The Software Magic Grimoire contributes the structured command contract. Its saved formulation defines a spell as an eight-limb instruction artifact: Role, Objective, Context, Constraints, Procedure, Output Contract, Verification, and Failure Behavior. It also frames strong software words as compressed coordination: terms that carry mechanisms, invariants, failure surfaces, and expected responses. * Compact Generative Systems contributes the idea that small structured cores can reconstruct, predict, generate, control, or govern larger systems through rules, memory, residuals, verification, and governance interfaces. * Cognitive Loop Closure contributes the mechanism for compiling repeated reasoning/action trajectories into verified parameterized tools. * Octopus Router Architecture contributes the modular head/router plus specialist modules model, replacing one undifferentiated monolith with dynamically selected, independently governed specialists. * Capability Ratchet / Ratcheting Modular Intelligence contributes benchmark frontiers, regression preservation, residual escrow, and evaluation-driven system growth. * GenesisCode contributes a stricter philosophy: AI output should be treated as untrusted by default and accepted through evidence, obligations, provenance, replay, and verification. The final system concept is: An operating environment where human intent becomes structured, verifiable, executable, and self-improving across digital, physical, hardware, robotic, organizational, and collaborative runtimes. ________________

Abstract Current AI systems can generate impressive responses, but generation alone does not produce reliable execution. Human goals often require durable artifacts, explicit constraints, verification, specialist coordination, runtime targeting, workflow reuse, benchmark-driven improvement, and feedback from reality. This paper proposes Verified Intent-to-Execution Architecture as a systems framework for bridging that gap. VIEA converts human intent into structured command contracts, stores resulting work in an artifact graph, routes subtasks to bounded specialist modules, verifies claims and outputs, compiles repeated workflows into tools, evaluates capabilities through benchmark ratchets, and executes artifacts through runtime adapters such as digital systems, hardware-specific builds, fabrication pipelines, robotic control, organizational workflows, and spatial project workspaces. The architecture’s purpose is to reduce the distance between intent and verified execution. It is built around five core transformations: intent → artifact artifact → specialist work specialist work → verified tool or output verified output → runtime execution execution feedback → improved system

VIEA is designed for implementation in stages. Its minimum viable version does not require VR, fabrication, robotics, or chip compilation. The initial build should prove one vertical slice: raw intent becomes a structured command, artifact graph, claim ledger, critique log, structured output, release manifest, primitive extraction, and feedback plan. The long-term version extends the same architecture across software, hardware targets, fabrication, physical objects, collaborative spatial workspaces, and organizational systems. The central claim is: The next major AI architecture is not merely a larger model. It is an integrated intent-to-execution system: structured commands, durable artifacts, specialist routing, verified workflow compilation, benchmark ratchets, runtime adapters, and feedback loops. ________________

1. Problem Statement 1.1 AI output is not the same as execution Most current AI workflows look like this: user prompt ↓ model response ↓ user manually interprets, verifies, stores, implements, or discards

This creates several problems. First, the system often generates useful text but does not preserve the underlying work as structured artifacts. Second, claims are mixed with assumptions, guesses, and speculation. Third, repeated workflows are re-performed instead of compiled into tools. Fourth, benchmarks are used as static scores rather than moving capability frontiers. Fifth, different types of execution—writing, coding, fabrication, deployment, robotics, and organizational action—are not unified under a common architecture. The result is a gap between generation and execution. VIEA is designed to close that gap. ________________

1.2 What the system must do A serious intent-to-execution system must: 1. clarify human intent; 2. convert intent into structured commands; 3. preserve work as artifacts; 4. separate facts, claims, assumptions, and speculation; 5. route work to appropriate specialists; 6. verify outputs; 7. compile repeated workflows into tools; 8. track failures and residuals; 9. evaluate progress with benchmarks; 10. preserve mastered capabilities as regression coverage; 11. compile outputs into the correct runtime; 12. capture feedback from execution; 13. improve future execution. The goal is not merely better answers. The goal is a closed-loop system for execution. ________________

2. Core Definition 2.1 Verified Intent-to-Execution Architecture Verified Intent-to-Execution Architecture is a systems architecture that transforms human goals into structured, verifiable, executable artifacts across multiple runtimes. A VIEA system includes: structured command layer artifact graph claim and critique ledger orchestrator/router specialist modules workflow-to-tool compiler benchmark and residual system runtime adapters feedback loop

A minimal formal expression: Intent + Command Contract + Artifact Memory + Specialist Routing + Runtime Adapter + Verification + Feedback → Executable Capability

---

2.2 Core loop The core loop is: 1. User submits intent. 2. System converts intent into a structured command contract. 3. Artifacts are created or updated. 4. Claims are extracted and assigned support states. 5. Orchestrator routes work to specialist modules. 6. Specialists return structured outputs. 7. Outputs are verified. 8. Repeated workflows are compiled into tools. 9. Benchmarks evaluate capability. 10. Residuals are tracked. 11. Output is compiled to selected runtime. 12. Deployment, fabrication, or execution occurs if gates pass. 13. Feedback updates artifacts, tools, benchmarks, and specialists.

This is the architecture’s core operating cycle. ________________

3. Design Principles 3.1 Structured intent before execution Vague goals should be converted into structured command contracts before high-impact execution. A weak request: Make this better.

A structured command: Role: Technical editor and systems reviewer. Objective: Convert the draft into a release-ready architecture paper. Context: The draft describes an AI-assisted intent-to-execution system. Constraints: Do not overclaim. Preserve speculative ideas as speculative. Procedure: Extract claims, improve structure, add failure modes, add implementation roadmap. Output Contract: Return full revised paper. Verification: Check unsupported claims, missing definitions, and safety gaps. Failure Behavior: Label missing evidence rather than inventing support.

The saved Grimoire work already formalizes this principle through the eight-limb structure: Role, Objective, Context, Constraints, Procedure, Output Contract, Verification, and Failure Behavior. In VIEA, this becomes the standard command interface. ________________

3.2 Artifacts over chat history Chat logs are weak memory. Artifacts are strong memory. The system should preserve important work as typed artifacts: * intent; * claim; * critique; * requirement; * decision; * source; * benchmark; * residual; * tool; * code module; * CAD object; * release; * feedback. A conversation may produce artifacts, but the conversation itself should not be the main substrate. ________________

3.3 Specialists over monoliths The system should not force one model or agent to do every task. Instead, it should use an orchestrator and bounded specialist modules. This follows the Octopus Router principle: one coherent system externally, many specialized subsystems internally. The saved Octopus Router paper defines this as a lightweight head/router coordinating dynamically loaded specialist arms, each with tools, memory, benchmarks, permissions, residuals, and lifecycle. In VIEA, the metaphor becomes an engineering pattern: orchestrator → specialist modules → structured outputs → verification → composed result

---

3.4 Repeated work becomes tools If the system repeatedly performs the same workflow, it should compile that workflow into a verified reusable tool. This is the Cognitive Loop Closure principle: repeated reasoning/action trajectories should become verified, parameterized procedural memory. The transformation is: repeated successful workflow → abstract invariant steps → identify parameters → define preconditions → define output contract → verify → register as tool

---

3.5 Benchmarks are curriculum, not trophies Benchmarks should guide development. They should not become static leaderboard targets. The Capability Ratchet and Ratcheting Modular Intelligence papers define the pattern: benchmark frontier, mastery threshold, regression preservation, residual escrow, and harder next frontier. In VIEA: * current benchmarks expose missing capability; * mastered benchmarks become regression coverage; * unsolved cases become residual backlog; * public benchmarks provide external calibration; * live/private benchmarks guide internal progress. ________________

3.6 AI proposes; verification disposes Generated outputs should not be trusted merely because they are fluent. GenesisCode states this strongly: AI output is untrusted by default; reliability comes from deterministic cores, explicit effect boundaries, hardened protocols, obligations, provenance, semantic patches, and evidence artifacts. VIEA generalizes that principle: AI may propose artifacts, tools, patches, designs, and plans. The system accepts them only through verification, provenance, permissions, and feedback. ________________

3.7 Runtime targeting matters An output is incomplete until the target runtime is known. Different runtimes require different artifacts and checks: Runtime Output examples Digital Runtime documents, apps, APIs, agents, dashboards Hardware Runtime firmware, embedded builds, GPU kernels, FPGA bitstreams Fabrication Runtime CAD, DFM checks, BOM, fabrication packet, inspection plan Robotic Runtime controllers, motion plans, reflex policies, telemetry Organizational Runtime SOPs, policies, workflows, operating plans Spatial Workspace Runtime project worlds, diagrams, simulations, collaborative objects A system that cannot target runtimes is mostly a generator. A system that can target runtimes becomes an execution architecture. ________________

4. System Architecture 4.1 High-level architecture User Intent ↓ Structured Command Layer ↓ Artifact Graph ↓ Claim / Critique / Verification Ledger ↓ Orchestrator / Router ↓ Specialist Modules ↓ Workflow-to-Tool Compiler ↓ Benchmark / Residual System ↓ Runtime Adapters ↓ Deployment / Fabrication / Execution ↓ Feedback Loop

---

4.2 Subsystems Subsystem Core responsibility Structured Command Layer Parse or construct command contracts. Artifact Graph Store durable work objects and relationships. Claim Ledger Track epistemic status of claims. Critique Ledger Store challenges, reviews, and resolutions. Orchestrator Select specialists, allocate context, control execution. Specialist Modules Execute bounded domain tasks. Tool Registry Store verified reusable workflows. Benchmark System Evaluate capabilities and preserve regression coverage. Residual Backlog Track unresolved failures and recurring issues. Runtime Adapters Compile artifacts to digital, hardware, fabrication, robotic, organizational, or spatial targets. Feedback System Capture results from execution and update the system. ________________

5. Structured Command Layer 5.1 Purpose The Structured Command Layer converts human intent into explicit command contracts. It should support:

• raw natural language;
• partial structured commands;
• full command contracts;
• saved workflows;
• reusable command templates;
• command stacks. ________________

5.2 Command contract The standard command contract is: Role Objective Context Constraints Procedure Output Contract Verification Failure Behavior

This is inherited from the Grimoire work but expressed here in systems-engineering language. Field Meaning Role What type of expertise or execution mode is being invoked. Objective What result the user wants. Context What is already true about the task. Constraints What must not be violated. Procedure How the system should proceed. Output Contract Required result format. Verification How correctness will be checked. Failure Behavior What the system should do when information is missing, unsafe, or contradictory. ________________

5.3 Command levels Not every task needs a full contract. Level Fields Use case Quick Command Role, Objective, Context, Verification Low-risk bounded work. Working Command Role, Objective, Context, Constraints, Output, Verification Normal work. Full Command All eight fields Public release, deployment, fabrication, security, or high-impact execution. Rule: The more durable or risky the output, the more complete the command contract must be. ________________

6. Artifact Graph 6.1 Purpose The Artifact Graph stores all meaningful units of work. It replaces chat-history dependence with durable structured memory. ________________

6.2 Artifact types Core artifact types: Intent Command Claim Source Critique Requirement Decision Design Diagram CodeModule CADObject Simulation Tool Workflow Benchmark Residual CompileTarget Release Feedback Primitive World

---

6.3 Artifact fields Each artifact should have: id type title content owner version created_at updated_at provenance links permissions verification_state release_state

---

6.4 Artifact relationships Useful relationship types: Relationship Meaning supports Evidence supports a claim. contradicts Evidence or critique challenges a claim. implements Artifact implements requirement. validates Test or benchmark validates artifact. depends_on Artifact depends on another artifact. derives_from Artifact came from another artifact. supersedes Artifact replaces earlier artifact. blocks Artifact blocks release or execution. compiled_to Artifact compiled to runtime target. produced_feedback Execution produced feedback. generalizes_to Pattern became primitive or tool. ________________

7. Claim and Verification Ledger 7.1 Purpose The Claim Ledger prevents the system from mixing fact, inference, speculation, and unsupported assertion. Every important claim should have a support state. ________________

7.2 Claim states State Meaning Verified Proven or directly validated. Empirically supported Supported by experiment or benchmark. Source-backed Supported by cited material. Reasoned inference Plausible but not directly proven. Speculative Hypothesis or conceptual possibility. Unsupported No current support. Contradicted Evidence argues against it. Requires experiment Needs empirical test. Requires expert review Needs domain-specific review. Deprecated No longer active. Rule: Speculation is allowed. Unlabeled speculation is not. ________________

7.3 Critique ledger Critiques are also artifacts. A critique should record: target_artifact critic_type severity summary recommendation status resolution linked_revision

Critic types may include: * claim audit; * source audit; * novelty audit; * engineering review; * safety review; * fabrication review; * benchmark review; * release review. ________________

8. Orchestrator and Specialist Modules 8.1 Orchestrator responsibilities The orchestrator is the central execution coordinator. It should:
9. interpret the command contract;
10. decompose tasks;
11. identify needed specialists;
12. allocate context;
13. allocate permissions;
14. select tools;
15. manage execution order;
16. collect structured outputs;
17. resolve conflicts;
18. route to verification;
19. produce final output or action. ________________

8.2 Specialist module responsibilities A specialist module is a bounded subsystem with a clear scope. Each specialist should have: name scope input_schema output_schema allowed_tools memory_scope permission_level benchmarks residuals runtime_tier lifecycle_status

---

8.3 Example specialist modules Module Scope Writing Module Structure, clarity, tone, final polish. Research Module Sources, related work, evidence gathering. Claim Audit Module Extract and classify claims. Skeptic Module Challenge assumptions and identify weaknesses. Code Module Generate, review, patch, and test software. CAD Module Create or revise geometry and assemblies. Simulation Module Run or specify tests and simulations. Fabrication Module Plan manufacturability and production handoff. Hardware Target Module Adapt software to chip or embedded constraints. Benchmark Module Design evaluations and track capability. Safety Module Identify risk, enforce gates, veto unsafe actions. Deployment Module Release planning, rollout, monitoring, rollback. Memory Module Retrieve relevant artifacts, history, and context. ________________

8.4 Specialist lifecycle Specialists should be: created evaluated used benchmarked updated split if bloated merged if redundant retired if stale

A specialist should not become a hidden monolith. ________________

9. Workflow-to-Tool Compiler 9.1 Purpose The Workflow-to-Tool Compiler detects repeated workflows and converts them into reusable tools. This is the operational form of Cognitive Loop Closure. The saved paper frames loop closure as converting repeated reasoning/action trajectories into verified parameterized tools, with trajectory logging, loop detection, abstraction, active parameter discovery, synthesis, verification, routing, monitoring, and retirement. ________________

9.2 Workflow closure process 1. Log successful trajectories. 2. Cluster similar trajectories. 3. Identify invariant steps. 4. Identify variable parameters. 5. Discover hidden assumptions. 6. Define preconditions. 7. Define postconditions. 8. Synthesize tool. 9. Verify tool. 10. Register tool. 11. Route future tasks to tool. 12. Monitor tool. 13. Revise or retire tool.

---

9.3 Tool fields A tool should store: name task_family parameters preconditions postconditions input_schema output_schema verification_grade runtime_tier risk_tier provenance usage_metrics failure_modes fallback_behavior retirement_criteria

---

9.4 Tool acceptance rule A workflow should become a tool only if: expected recurrence × value × reliability gain > creation cost + maintenance cost + verification cost + risk cost + drift cost

This prevents tool bloat. ________________

10. Evaluation Ratchet 10.1 Purpose The Evaluation Ratchet manages capability growth. It tracks:

• current frontier benchmarks;
• diagnostics;
• regression coverage;
• public calibration;
• live benchmarks;
• retired benchmarks;
• unresolved residuals. ________________

10.2 Benchmark lifecycle Status Meaning Frontier Currently used to expose missing capability. Diagnostic Isolates a specific failure mode. Graduated Mastered enough to move forward. Regression Preserves prior capability. Public calibration Enables apples-to-apples comparison. Live Updated over time. Retired No longer useful. ________________

10.3 Mastery threshold A benchmark should not necessarily require 100%. For ordinary non-safety benchmarks, an initial mastery threshold might be: 90%

If progress stalls, the threshold can decay toward a floor, such as: 70%

But critical failures can still block graduation. ________________

10.4 Critical-failure veto Critical failures override aggregate score. Examples: * unsafe physical action; * security breach; * destructive deployment; * financial harm; * medical harm; * illegal fabrication; * catastrophic data loss. Rule: A system cannot graduate a benchmark if unresolved critical failures remain. ________________

10.5 Residual backlog Unsolved cases become residuals. A residual stores: source failure_type severity cluster recurrence_count reattempt_schedule promotion_status

Residuals are not ignored. They are periodically reattempted. If a residual pattern keeps recurring, it becomes an active diagnostic target. ________________

11. Runtime Adapters 11.1 Purpose Runtime adapters compile artifacts into target environments. The output target determines the required verification. ________________

11.2 Digital Runtime Produces: documents specs code apps agents APIs dashboards datasets workflows deployment bundles

Verification may include: * tests; * review; * output contract checks; * claim support; * regression comparison. ________________

11.3 Hardware / Chip Runtime Produces: firmware embedded builds GPU kernels FPGA bitstreams target-specific binaries hardware-in-loop test plans

A hardware target profile should include: architecture memory limit power budget latency budget runtime constraints peripherals forbidden assumptions verification requirements

---

11.4 Fabrication Runtime Produces: requirements CAD or schematic artifact list simulation plan DFM / DFA checks bill of materials fabrication packet inspection plan assembly plan field-test plan

The fabrication pipeline is: intent → requirements → CAD / schematic → simulation → manufacturability check → bill of materials → fabrication routing → fabrication → inspection → assembly → field test → feedback

The Fabrication Runtime should never treat a plausible design as automatically safe or manufacturable. ________________

11.5 Robotic Runtime Produces: controller motion plan sensor loop reflex/failsafe behavior telemetry plan

Robotic execution requires strong gates because it directly affects physical reality. ________________

11.6 Organizational Runtime Produces: standard operating procedures team workflows policies contracts business plans training programs release processes governance systems

Organizations are runtimes because they execute intent through people, incentives, roles, and processes. ________________

11.7 Spatial Project Workspace Runtime Produces: project worlds visual artifact graphs collaborative workspaces simulation arenas world templates forkable project spaces

This is the VR/AR or spatial interface layer. It is not required for the MVP, but it becomes valuable as complexity grows. Every spatial object must map to a real artifact or state. ________________

12. Safety and Permission Model 12.1 Core distinction The system must separate: exploratory manipulation inside a workspace

from: execution into shared reality

Users can explore freely in private workspaces. Execution requires gates. ________________

12.2 Safety stages Stage Safety posture Exploration Free ideation and reversible manipulation. Simulation Mostly free, logged. Digital compile Verification required. Hardware compile Target constraints and regression required. Fabrication Safety, manufacturability, and inspection required. Deployment Approval, rollback, and monitoring required. High-risk action Strict gate, refusal, or certified process. Rule: Nothing leaves a project workspace into shared reality without the correct gate. ________________

12.3 Permission envelopes Every specialist or tool invocation receives a permission envelope: memory access tool access runtime access side-effect allowance budget risk tier approval requirements

The system should default to least privilege. ________________

13. Spatial Project Workspace 13.1 Purpose The spatial workspace is an interface layer for complex artifact manipulation. It should let users:

• create project worlds;
• see artifacts as objects;
• inspect claim graphs;
• manipulate diagrams and CAD;
• run simulations;
• summon specialists;
• invite collaborators;
• fork project versions;
• import public primitives;
• select compile targets. ________________

13.2 Project world A project world stores: artifact graph active specialists tools benchmarks residuals compile targets collaborators permissions release history

It is essentially a spatial UI over the Artifact Graph and Runtime Adapters. ________________

13.3 Collaboration model Default: private by default collaborative by invitation public by release

Collaborator roles: * owner; * builder; * reviewer; * observer; * operator; * safety reviewer; * fabrication approver. All collaborator changes should be logged as events. ________________

14. Minimal Viable Implementation 14.1 MVP goal The first implementation should prove one vertical loop: raw idea → structured command → artifact graph → claim ledger → critique log → structured paper/spec → release manifest → primitive extraction → feedback plan

---

14.2 MVP components Required: * command contract parser; * artifact store; * claim ledger; * critique ledger; * basic orchestrator; * small set of specialist modules; * release manifest generator; * primitive registry; * feedback record. Not required for MVP: * full VR/AR; * real fabrication; * chip compilation; * robotics; * multiplayer; * full autonomy. ________________

14.3 MVP specialists Start with: Writing Research Claim Audit Skeptic Review Implementation Planning Safety Review

---

14.4 MVP outputs The MVP should produce: whitepaper implementation spec claim ledger critique log release manifest build packet benchmark plan

The first product should make the architecture itself more buildable. ________________

15. Implementation Phases Phase 1 — Artifact Kernel Build:

• artifacts;
• relationships;
• provenance;
• versions;
• releases;
• feedback records. Goal: Preserve work as structured memory. ________________

Phase 2 — Structured Command Layer Build support for: * quick command; * working command; * full command; * command templates; * command stacks. Goal: Reduce ambiguity in intent. ________________

Phase 3 — Claim and Critique Ledger Build: * claim extraction; * support states; * critique artifacts; * release blockers; * resolution tracking. Goal: Make outputs auditable. ________________

Phase 4 — Orchestrator and Specialists Build: * orchestrator; * specialist registry; * specialist input/output contracts; * routing decisions; * structured specialist outputs. Goal: Route tasks to bounded expertise. ________________

Phase 5 — Workflow-to-Tool Compiler Build: * trajectory logs; * loop candidate detection; * tool cards; * verification records; * tool registry. Goal: Turn repeated work into tools. ________________

Phase 6 — Evaluation Ratchet Build: * benchmark ledger; * mastery thresholds; * regression suite; * residual backlog; * public calibration tracking. Goal: Make improvement measurable. ________________

Phase 7 — Runtime Adapter Models Add conceptual adapters for: * digital; * hardware; * fabrication; * robotic; * organizational; * spatial workspace. Goal: Connect artifacts to execution targets. ________________

Phase 8 — Spatial Workspace Add a spatial project workspace when the artifact graph becomes too complex for flat interfaces. Goal: Make complex systems manipulable. ________________

Phase 9 — External Execution Add controlled execution into real runtimes: * deploy code; * route fabrication packets; * run benchmarks; * collect feedback. Goal: Close the loop with reality. ________________

16. Evaluation Metrics 16.1 Command quality

• missing field rate;
• ambiguity reduction;
• verification clarity;
• failure behavior adequacy;
• output contract compliance. 16.2 Artifact quality
• provenance completeness;
• claim support ratio;
• critique resolution rate;
• release blocker count;
• artifact reuse rate. 16.3 Routing quality
• correct specialist selection;
• unnecessary routing rate;
• missed specialist rate;
• conflict resolution quality;
• safety routing accuracy. 16.4 Tool quality
• recurrence frequency;
• verification pass rate;
• cost savings;
• failure rate;
• retirement rate;
• stale tool count. 16.5 Benchmark quality
• frontier improvement;
• regression preservation;
• residual reduction;
• public calibration performance;
• recurring residual detection. 16.6 Runtime quality
• successful compile/deploy/fabricate rate;
• verification pass rate;
• cost estimate accuracy;
• lead-time estimate accuracy;
• failure feedback capture. 16.7 System-level quality
• time from intent to verified artifact;
• time from intent to executable output;
• feedback incorporation rate;
• user correction rate;
• reuse across projects;
• reduction in repeated manual work. ________________

17. Failure Modes 17.1 Output without artifact The system generates a response but does not store durable structure. Mitigation:

• require artifacts for important outputs. ________________

17.2 Unsupported claims The system produces confident but unsupported claims. Mitigation: * claim ledger and support states. ________________

17.3 Over-structured interaction The command layer becomes too heavy for simple tasks. Mitigation: * quick, working, and full command levels. ________________

17.4 Specialist chaos Specialists produce incoherent or conflicting outputs. Mitigation: * structured outputs, orchestrator synthesis, and verifier routing. ________________

17.5 Tool bloat Too many tools accumulate without value. Mitigation: * tool acceptance rule, metrics, merge/retire lifecycle. ________________

17.6 Benchmark gaming The system optimizes scores without improving useful capability. Mitigation: * live benchmarks, private holdouts, residual tracking, and public calibration distinction. ________________

17.7 Residual erasure Failures are forgotten after graduation. Mitigation: * residual backlog with reattempt schedules and recurrence promotion. ________________

17.8 Unsafe execution The system executes beyond safe bounds. Mitigation: * runtime gates, permission envelopes, human approval, and refusal policies. ________________

17.9 Fabrication overreach The system treats plausible physical designs as safe or manufacturable. Mitigation: * simulation, DFM/DFA, inspection plans, compliance checks, and fabrication approval. ________________

17.10 Architecture overreach The system attempts full vision before proving core loop. Mitigation: * vertical MVP first. ________________

18. Claims and Non-Claims 18.1 Claims This paper claims:
19. AI systems need structured intent, not only prompts.
20. Durable artifact graphs are stronger than chat history for long-running work.
21. Claims should have explicit support states.
22. Specialist routing improves modularity and diagnosis.
23. Repeated workflows should become verified tools when valuable and safe.
24. Benchmarks should be treated as moving curriculum.
25. Residual failures should be tracked rather than forgotten.
26. Runtime targeting is necessary for real execution.
27. Fabrication requires simulation, manufacturability checks, inspection, and approval.
28. The first build should prove a narrow vertical loop before expanding to full runtime execution. ________________

18.2 Non-Claims This paper does not claim: 1. The full system already exists. 2. AI should execute all user intent automatically. 3. Verification is absolute. 4. Structured commands eliminate ambiguity completely. 5. Specialist modules always outperform monolithic systems. 6. Every repeated workflow should become a tool. 7. Benchmarks perfectly measure capability. 8. Physical artifacts should be fabricated without safety review. 9. VR/AR is required for all use cases. 10. AI replaces human responsibility. ________________

19. The Final Distillation Everything reduces to this: Intent → Command Contract → Artifact Graph → Specialist Execution → Runtime Target → Verification → Feedback → Improved System

Or in one sentence: VIEA is an operating environment that converts human intent into structured artifacts, routes work to bounded specialists, compiles outputs to the correct runtime, verifies execution, and uses feedback to improve future work. That is the architecture. ________________

Appendix A — One-Paragraph Summary Verified Intent-to-Execution Architecture is a systems framework for converting human goals into verified execution. It turns vague intent into structured command contracts, stores work in an artifact graph, tracks claims and critiques, routes subtasks to specialist modules, compiles repeated workflows into tools, evaluates progress through benchmark ratchets, targets outputs to digital, hardware, fabrication, robotic, organizational, or spatial runtimes, and feeds execution results back into the system. Its purpose is to reduce the distance between human intent and reliable action. ________________

Appendix B — Minimal Object Model World Artifact Command Claim Critique Source Requirement Decision SpecialistModule Tool Workflow Benchmark Residual CompileTarget RuntimeAdapter Release Feedback Primitive

---

Appendix C — Compact Operating Rules 1. If it matters, make it an artifact. 2. If it claims something, assign a support state. 3. If it repeats, consider compiling it into a tool. 4. If it fails, track the residual. 5. If it is mastered, preserve it as regression. 6. If it executes, verify first. 7. If it affects shared reality, apply gates. 8. If it produces feedback, update the system. 9. If it grows too broad, split it. 10. If it becomes stale, retire it. ________________

Appendix D — Codex Conceptual Handoff Build the first version as a vertical slice: raw idea → structured command → artifact graph → claim ledger → critique log → structured output → release manifest → primitive extraction → feedback plan

Do not start with full runtime execution. Do not start with VR. Do not start with fabrication. Start with the artifact and verification core. Once the core preserves, verifies, routes, and releases work reliably, extend it into tools, benchmarks, spatial workspaces, hardware targets, fabrication, deployment, and feedback.

Tab 2 Verified Intent-to-Execution Architecture From prompt → artifact → verified execution: an operating architecture for turning human intent into reliable, auditable, runtime-targeted action Author: Corben Sorenson Public Article v1.0 — May 2026 ________________

How to Read This Paper Start with the Thesis, Core Operating Loop, and Architecture Overview. The middle sections define the subsystems. The final sections—Failure Modes, Claims and Non-Claims, and Compact Operating Rules—serve as the paper’s self-audit. This paper is written as a systems architecture document, not a product pitch. Its goal is to name the right abstractions, identify their failure modes, and define a realistic implementation path. ________________

Thesis AI systems are becoming very good at generating outputs. They can produce text, code, plans, summaries, diagrams, images, prototypes, workflows, and interface drafts. But generation is not execution. A generated response is not necessarily verified, durable, reusable, deployable, safe, or connected to feedback. The next major step is not simply making models larger. The next step is building systems that convert human intent into structured artifacts, route work through the right specialists, execute through the correct runtime, verify the result, preserve failures, and improve from feedback. I call this: Verified Intent-to-Execution Architecture or VIEA. The core loop is: intent → structured command → artifact graph → routed specialist execution → integration → runtime target → verification gate → deployment / fabrication / execution → feedback → improved system

VIEA is not a chatbot architecture. It is an operating architecture for turning human goals into verified execution. ________________

1. The Problem: AI Output Is Not Execution Most AI workflows today still look like this: user prompt ↓ model response ↓ human manually interprets, verifies, stores, implements, or discards

This creates a major gap. A model can generate a useful answer, but the work often remains trapped in the conversation. Claims are not tracked. Assumptions are not labeled. Repeated workflows are not compiled into tools. Failures are forgotten. Benchmarks are treated as static scores instead of moving curricula. Software, fabrication, hardware, robotics, and organizational execution are handled as separate worlds. The problem is not that AI cannot generate. The problem is that AI generation usually lacks a reliable execution architecture around it. A serious intent-to-execution system needs to answer: * What exactly does the user want? * What artifact should be produced? * What claims are being made? * What evidence supports those claims? * What constraints must not be violated? * Which specialist should do which part? * How will specialist outputs be integrated? * What runtime should the output target? * What tests must pass before execution? * What failures remain unresolved? * What feedback came back from reality? * What should change next time? VIEA is designed to answer those questions systematically. ________________

2. Definition Verified Intent-to-Execution Architecture is a systems architecture that transforms human goals into structured, verifiable, executable artifacts across multiple runtimes. A VIEA system contains these major subsystems: intent capture and command drafting structured command contracts artifact graph artifact retention and relevance layer claim and verification ledger provenance and permission model fast router slow conductor specialist modules integration layer workflow-to-tool compiler evaluation ratchet runtime adapters

These subsystems are supported by cross-cutting resource accounting, safety gates, approval policies, operational metrics, threat modeling, and feedback loops. The goal is to reduce the distance between: “I want this”

and: “This has been structured, verified, built, executed, measured, and improved.”

---

3. Core Operating Loop The system operates like this:
4. User submits intent.
5. System drafts or receives a structured command contract.
6. User confirms only the fields that matter for the risk level.
7. Artifacts are created or updated.
8. Claims are extracted and assigned support states.
9. Fast Router selects candidate specialists and permissions.
10. Specialists return structured outputs.
11. Integration Layer checks cross-specialist compatibility.
12. Verification gates check claims, outputs, runtime safety, and residuals.
13. Repeated workflows may be compiled into tools.
14. Benchmarks evaluate capability.
15. Residuals are tracked.
16. Output is compiled to the selected runtime.
17. Deployment, fabrication, or execution occurs only if gates pass.
18. Feedback updates artifacts, tools, benchmarks, routing policy, specialists, and future commands.

The key principle: Nothing important should remain only as a chat response. If it matters, make it an artifact. If it claims something, assign a support state. If it repeats, consider compiling it into a tool. If it fails, track the residual. If routing fails, log a routing residual. If integration fails, log an integration residual. If it executes, verify first. If it produces feedback, update the system. ________________

4. Architecture Overview VIEA has thirteen major subsystems. Subsystem Purpose Intent Capture and Command Drafting Lets users start with natural language, then drafts a structured command contract. Structured Command Layer Converts goals into explicit command contracts when needed. Artifact Graph Stores ideas, claims, critiques, requirements, tools, benchmarks, releases, and feedback as durable artifacts. Artifact Retention and Relevance Layer Prevents artifact graph bloat through summarization, archival, deprecation, and active-context selection. Claim and Verification Ledger Tracks whether claims are verified, source-backed, inferred, speculative, unsupported, contradicted, or requiring experiment. Provenance and Permission Model Tracks origin, dependencies, authorship, authority, and allowed side effects. Fast Router Performs low-latency, policy-driven specialist selection, permission assignment, and budget control. Slow Conductor Asynchronously learns from routing failures, updates routing policy, analyzes residuals, and manages specialist strategy. Specialist Modules Bounded subsystems for writing, research, code, CAD, safety, benchmarking, deployment, fabrication, and more. Integration Layer Detects contextual shattering and checks whether specialist outputs are compatible as a whole. Workflow-to-Tool Compiler Converts repeated successful workflows into verified reusable tools. Evaluation Ratchet Uses benchmarks, regression suites, residual backlogs, and public calibration to guide improvement. Runtime Adapters Compile outputs into digital, hardware, fabrication, robotic, organizational, or spatial/project-workspace runtimes. The high-level flow is: User Intent ↓ Intent Capture / Command Drafting ↓ Structured Command Contract ↓ Artifact Graph + Claim Ledger ↓ Fast Router ↓ Specialist Modules ↓ Integration Layer ↓ Verification Gate ↓ Runtime Adapter ↓ Execution / Deployment / Fabrication ↓ Feedback ↓ Slow Conductor + Evaluation Ratchet

---

5. Intent Capture and Command Drafting A major failure mode for structured systems is user friction. Humans often do not want to fill out a form before they begin. They want to say: Make this better.

VIEA must support that. The system should provide a friction gradient: Level User experience System behavior Raw Intent “Make this better.” System infers likely objective and drafts a command contract. One-Line Command “Make this release-ready and don’t overclaim.” System fills missing fields automatically. Quick Command Role, Objective, Context, Verification Useful for low-risk bounded work. Working Command Role, Objective, Context, Constraints, Output, Verification Useful for normal engineering, writing, and analysis. Full Command All eight fields Required for public release, deployment, fabrication, security, or high-impact execution. The user should be able to start with natural language. The system should draft the structure. The user should only have to approve or correct fields when the stakes justify the overhead. ________________

6. Automation Bias Control Auto-drafted command contracts create a new risk: users may approve a plausible but wrong contract. If the system misinterprets intent and the user rubber-stamps it, the system can execute perfectly against the wrong objective. VIEA therefore needs automation bias controls. 6.1 Intent checksum For any medium- or high-impact task, the system should produce an intent checksum: a short plain-language summary of what it believes the user wants. Example: Intent checksum: You want this draft revised into a public v1.0 architecture article. The priority is defensibility and clarity, not maximum novelty. The system should preserve speculative ideas but label them clearly.

The user does not need to inspect every field. They need to confirm the core intent. 6.2 Assumption diff The system should list material assumptions it inferred. Assumptions inferred: - Target audience: technical AI / systems readers. - Output: public article, not implementation spec. - Tone: systems engineering, not marketing. - Evidence standard: conceptual but non-overclaiming.

If these are wrong, the user can correct them before execution. 6.3 Risk-based confirmation Confirmation should scale with risk. Risk level Confirmation requirement Low Proceed automatically after showing summary. Medium User confirms objective and output contract. High User confirms objective, constraints, verification, and failure behavior. Critical Explicit approval from qualified authority required. 6.4 Misalignment probe For important tasks, the system should ask one adversarial check: Before I proceed: is there anything important this command should NOT optimize for?

This catches cases where the drafted contract is plausible but wrong. 6.5 No silent hardening If a raw request is ambiguous, the system may draft a command, but it should not silently convert the task into a high-impact workflow. Rule: The system may infer structure, but it must not silently infer authority. ________________

7. Structured Command Layer The standard command contract has eight fields: Field Meaning Role What kind of expertise is being invoked. Objective What outcome matters most. Context What is already true. Constraints What must not be violated. Procedure How the system should proceed. Output Contract What shape the result must take. Verification How correctness will be checked. Failure Behavior What to do if context is missing, unsafe, or contradictory. A weak request: Make this better.

A structured command: Role: Technical editor and systems reviewer.

Objective: Convert the draft into a release-ready architecture paper.

Context: The draft describes an AI-assisted intent-to-execution system.

Constraints: Do not overclaim. Preserve speculative ideas as speculative.

Procedure: Extract claims, improve structure, add failure modes, add implementation roadmap.

Output Contract: Return a complete revised paper.

Verification: Check unsupported claims, missing definitions, and safety gaps.

Failure Behavior: Label missing evidence rather than inventing support.

The purpose is not bureaucracy. The purpose is to partially compile intent before execution. ________________

8. Artifact Graph Chat history is weak memory. Artifacts are strong memory. A VIEA system should store work as typed artifacts, not just conversation transcripts. Core artifact types include: Intent Command Claim Source Critique Requirement Decision Design Diagram CodeModule CADObject Simulation Tool Workflow Benchmark Residual CompileTarget RuntimeAdapter Release Feedback Primitive World

Each artifact should have: id type title content owner version created_at updated_at provenance links permissions verification_state release_state retention_class activity_state hash_links

Artifacts should also have relationships: Relationship Meaning supports Evidence supports a claim. contradicts Evidence or critique challenges a claim. implements Artifact implements a requirement. validates Test or benchmark validates artifact. depends_on Artifact depends on another artifact. derives_from Artifact came from another artifact. supersedes Artifact replaces earlier artifact. blocks Artifact blocks release or execution. compiled_to Artifact compiled to a runtime target. produced_feedback Execution produced feedback. generalizes_to Pattern became a primitive or tool. This turns a project from a pile of text into a durable graph of intent, work, evidence, and outcomes. ________________

9. Artifact Retention and Relevance Control A typed artifact graph is better than chat history, but it creates a new problem: If everything becomes an artifact, the graph can become too large to use. VIEA needs concrete retention and relevance policies. 9.1 Artifact classes Artifact class Examples Default behavior Core Commands, claims, decisions, requirements, releases, tools, feedback Preserve indefinitely unless explicitly retired. Support Drafts, intermediate analyses, source summaries, design alternatives Preserve, summarize after inactivity, keep provenance. Transient Scratch work, temporary decompositions, abandoned alternatives Expire or compress after a short TTL unless linked. Archived Old versions, stale branches, inactive project artifacts Searchable but excluded from default context. Deprecated Superseded artifacts and rejected claims Retained for provenance but hidden from normal routing. 9.2 Example retention rules Concrete defaults can be tuned by project, but the system should start with policies like: Transient artifacts: summarize after 48 hours if not hash-linked to a core or support artifact archive after 7 days if inactive and unlinked delete only if no provenance obligation exists

Support artifacts: summarize after 30 days of inactivity archive after 90 days if not referenced preserve source links and decision impact

Core artifacts: never auto-delete may be superseded, deprecated, or archived remain available for audit

Residual artifacts: keep active while recurring archive only after resolution or explicit waiver

9.3 Hash-link rule A transient artifact should survive only if it becomes relevant. Rule: If a transient artifact is not hash-linked to a core artifact, support artifact, residual, decision, tool, or release within 48 hours, it should be summarized and marked for pruning. This prevents scratch output from polluting long-term retrieval. 9.4 Active context selection The system should not load the whole graph into every task. It should select context by: * current command; * artifact type; * dependency distance; * recency; * verification state; * specialist scope; * runtime target; * permission envelope; * residual relevance. Rule: Preserve provenance, but route relevance. The Artifact Graph is not an unbounded memory dump. It is an indexed, typed, versioned, selectively activated memory system. ________________

10. Claim and Verification Ledger AI systems often mix facts, assumptions, predictions, speculation, and confident guesses. That is dangerous. Every important claim should have a support state. State Meaning Verified Proven or directly validated by deterministic check, formal proof, reproducible test, or authoritative record. Empirically supported Supported by experiment, benchmark, or measured result. Source-backed Supported by cited external material. Reasoned inference Plausible but not directly proven. Speculative Hypothesis or conceptual possibility. Unsupported No current support. Contradicted Evidence argues against it. Requires experiment Needs empirical test. Requires expert review Needs domain-specific review. Deprecated No longer active. Waived Claim tracking intentionally waived for a low-risk context. The rule is: Speculation is allowed. Unlabeled speculation is not. ________________

11. Claim Ledger Waivers Not every low-risk artifact needs heavy claim tracking. A quick internal email, brainstorming note, or low-impact draft should not pay the full verification cost of a public release. VIEA therefore supports claim ledger waivers. 11.1 When waivers are allowed Claim tracking may be waived when:

• the output is low-risk;
• the artifact is not public;
• the artifact does not instruct execution;
• the artifact does not make safety, legal, medical, financial, or empirical claims;
• the artifact is not used as evidence for another artifact;
• the user or policy allows lightweight treatment. 11.2 Waiver record A waiver is itself an artifact. It should record: artifact_id waiver_reason risk_tier scope expiration approver_or_policy

11.3 Waiver limits A waived claim cannot support high-impact downstream artifacts without reactivation. Rule: A waiver reduces local overhead; it does not create evidence. If a waived artifact later becomes part of a release, deployment, fabrication packet, or benchmark claim, its claims must be re-extracted and assigned support states. ________________

12. Epistemic Collapse Control A claim ledger is only useful if verification is not just another model agreeing with itself. If the same underlying model powers the generator, researcher, skeptic, and verifier, the system can reach internal consensus on false claims. VIEA therefore requires an evidence hierarchy. 12.1 Evidence hierarchy Evidence level Examples Maximum claim state Internal model agreement Multiple specialists agree without external evidence Reasoned inference at most. Source citation External document, dataset, repository, standard, publication Source-backed. Executable check Test, benchmark, simulation, proof, static analysis, reproducible run Verified or empirically supported depending on check. Independent system check Different model family, independent tool, external validator Raises confidence but still needs evidence. Expert or authority review Qualified human or governing body Reviewed / approved, with scope. Field feedback Deployment, fabrication, user telemetry, real-world result Empirically supported or contradicted. Critical rule: Model consensus alone cannot mark a claim as verified. It can mark a claim as plausible, inferred, or recommended for testing. 12.2 Verification diversity For high-impact claims, verification should include at least one of:

• external source;
• executable test;
• independent tool;
• human expert;
• empirical result;
• formal proof;
• real-world feedback. 12.3 Claim downgrade policy If support expires, sources are challenged, tests fail, or feedback contradicts the claim, the claim state must downgrade automatically. Example: Source-backed → requires review Empirically supported → contradicted Verified → deprecated or blocked

Verification is not a stamp forever. It is a maintained state. ________________

13. Provenance and Permission Model The Artifact Graph and Runtime Adapters will be high-value infrastructure. That makes them high-risk surfaces. VIEA needs a strong provenance and permission model. Every artifact should know: who created it who modified it what generated it what it depends on what evidence supports it what permissions govern it what runtime it may target what release boundary it may cross

Every tool, specialist, and runtime adapter should operate under a permission envelope: memory access tool access runtime access side-effect allowance budget risk tier approval requirements audit requirements

The system should default to least privilege. 13.1 Permission tiers Tier Example Requirements Read-only Summarize artifact, inspect claim graph No mutation. Draft Generate proposal, create candidate artifact No release or execution. Edit Modify artifact or tool candidate Versioning and provenance required. Execute digital Run code, call API, deploy to test environment Verification and sandboxing required. Execute physical Fabricate, actuate, route to robotics Safety gate and approval required. Public release Publish artifact, release primitive, send external communication Release gate required. Critical action Production mutation, financial action, robotics actuation, irreversible execution Strict gate, qualified approval, or refusal. The system must know the difference between drafting, executing, fabricating, deploying, and publishing. ________________

14. Approval Authority and Human Bottleneck Control “Human approval” is not enough as a safety model. The system needs to know:

• who is approving;
• whether they are qualified;
• what authority they have;
• what risk tier they may approve;
• whether approval fatigue is likely;
• what happens when approvers are unavailable. 14.1 Approval roles Role Can approve Owner Low/medium project decisions. Domain reviewer Domain-specific technical claims. Safety reviewer Safety gates, risk classifications, refusals. Release approver Public release boundaries. Fabrication approver Physical production handoffs. Deployment approver Production digital deployment. Critical authority High-risk or irreversible actions. 14.2 Approval fatigue controls The system should reduce approval fatigue by:
• batching low-risk approvals;
• escalating only material changes;
• using pre-approved policies;
• allowing reversible actions under lower gate;
• requiring explicit approval only when crossing risk boundaries;
• showing concise deltas rather than full artifacts;
• blocking critical actions when no qualified approver is available. 14.3 Human review as a resource Human review capacity is a first-class resource. A project should track: available reviewers reviewer qualifications review queue length approval latency approval fatigue index review budget critical approval coverage

A system that requires unlimited human review will not scale. Rule: Human approval must be qualified, scoped, rate-limited, and budgeted. Otherwise it becomes theater. ________________

15. Fast Router and Slow Conductor Routing is one of the hardest parts of VIEA. A single all-powerful Conductor would become the new monolith. Therefore VIEA splits routing into two pieces. 15.1 Fast Router The Fast Router is the low-latency policy layer. It handles:

• initial specialist selection;
• permission envelope assignment;
• context packaging;
• risk-tier routing;
• default tool selection;
• simple fallback decisions;
• token budget enforcement;
• compute budget enforcement;
• latency budget enforcement. It should be deterministic or policy-constrained wherever possible. 15.2 Fast Router budget caps The Fast Router must enforce hard caps before routing. A routing decision should include: max specialist calls max tokens / context budget max compute budget max latency max financial cost max human review requests risk tier fallback behavior

If the request exceeds budget, the system should: * reduce scope; * choose cheaper specialists; * run a quick path; * ask for budget approval; * defer expensive verification; * refuse nonessential execution. The Fast Router must prevent runaway orchestration. 15.3 Slow Conductor The Slow Conductor is the learning and strategy layer. It handles: * routing residual analysis; * specialist performance review; * routing policy updates; * conflict pattern discovery; * specialist split/merge recommendations; * long-term routing improvement; * post-run diagnosis. The Slow Conductor should not sit on the critical execution path. It should operate as an asynchronous, offline analysis pipeline over logs, residuals, metrics, and feedback. A useful implementation model is: runtime events → log batches → residual clustering → routing policy recommendations → human or policy review → updated routing rules

The Fast Router executes known routing policy. The Slow Conductor improves routing policy offline. This prevents the Conductor from becoming a single point of latency or catastrophic failure. ________________

16. Routing Residuals Routing failures are first-class residuals. Examples: Routing residual Meaning Wrong specialist selected The chosen module lacked the needed expertise. Missing specialist No available module fit the task. Context under-allocation Specialist did not receive needed information. Context over-allocation Specialist received irrelevant or unsafe information. Conflict unresolved Specialist outputs disagreed without resolution. Verifier skipped Output needed review but was not routed to verifier. Over-routing Too many specialists were called, increasing cost and incoherence. Under-routing Too few specialists were called, causing shallow output. Permission mismatch Specialist lacked or exceeded necessary authority. Routing residuals should update the Slow Conductor. ________________

17. Specialist Modules Specialist modules are bounded subsystems with defined scopes. Examples: Module Scope Writing Module Structure, clarity, tone, final polish. Research Module Sources, related work, evidence gathering. Claim Audit Module Extract and classify claims. Skeptic Module Challenge assumptions and identify weaknesses. Code Module Generate, review, patch, and test software. CAD Module Create or revise geometry and assemblies. Simulation Module Run or specify tests and simulations. Fabrication Module Plan manufacturability and production handoff. Hardware Target Module Adapt software to chip or embedded constraints. Benchmark Module Design evaluations and track capability. Safety Module Identify risk, enforce gates, veto unsafe actions. Deployment Module Release planning, rollout, monitoring, rollback. Memory Module Retrieve relevant artifacts, history, and context. Each specialist should have: name scope input_schema output_schema allowed_tools memory_scope permission_level benchmarks residuals runtime_tier lifecycle_status cost_profile

Specialists should be created, evaluated, benchmarked, updated, split if they become too broad, merged if redundant, and retired if stale. ________________

18. Specialist Output Contracts Specialists should not return unstructured text by default. They should return structured outputs. A specialist output should include: result confidence assumptions evidence compatibility_requirements risks residuals recommended_next_steps required_verification provenance cost

This helps the orchestrator compose outputs reliably. It also makes disagreement manageable. If the Research Module says a claim is source-backed and the Skeptic Module says it is overclaimed, the system should not flatten both into one vague paragraph. It should preserve the disagreement, route to verification, or expose the uncertainty. ________________

19. Integration Layer Bounded specialists reduce monolithic chaos, but they introduce a new failure mode: Specialists can produce locally valid outputs that are globally incompatible. This is contextual shattering. Example:

• Code Module produces valid memory logic.
• Hardware Target Module produces valid hardware constraints.
• Each is correct locally.
• The integrated system fails because the memory logic violates the hardware constraints. VIEA therefore needs an Integration Layer. 19.1 Integration responsibilities The Integration Layer checks:
• cross-specialist compatibility;
• shared constraints;
• global invariants;
• runtime assumptions;
• dependency compatibility;
• resource budgets;
• interface consistency;
• failure behavior across modules. 19.2 Integration contract Every multi-specialist task should define an integration contract: global objective shared constraints required interfaces runtime target resource budget critical invariants integration tests failure boundaries rollback behavior

19.3 Whole-system pass Before high-impact execution, the system should run a whole-system pass: specialist outputs ↓ integration compatibility check ↓ global invariant check ↓ runtime target check ↓ verification gate

The Integration Layer exists because decomposition is not enough. A system must also recombine correctly. 19.4 Transactional integration and rollback For high-impact tasks, a set of specialist outputs should be treated as a single transaction. If global integration fails, the system should not partially apply the outputs. It should: 1. reject the integrated candidate; 2. preserve the failed integration bundle as an artifact; 3. roll back to the last known valid checkpoint; 4. log an integration residual; 5. route the residual to the Slow Conductor or relevant specialists; 6. require a revised integration candidate before execution.

Rule: Locally valid outputs do not become executable until the integrated state passes. This is especially important for software builds, hardware targets, fabrication packets, deployment plans, and robotics. ________________

20. Workflow-to-Tool Compiler If the system repeats the same workflow many times, it should not keep redoing the workflow from scratch. Repeated work should become a tool. The process is:
21. Log successful trajectories.
22. Cluster similar trajectories.
23. Identify invariant steps.
24. Identify variable parameters.
25. Discover hidden assumptions.
26. Define preconditions.
27. Define postconditions.
28. Synthesize tool candidate.
29. Run in shadow mode.
30. Verify tool candidate.
31. Register tool.
32. Route future tasks to tool under conditions.
33. Monitor tool.
34. Revise or retire tool.

A tool should store: name task_family parameters preconditions postconditions input_schema output_schema verification_grade runtime_tier risk_tier provenance usage_metrics failure_modes fallback_behavior retirement_criteria revalidation_schedule confidence_decay_policy

---

21. Tool Compiler Acceptance Rules The abstract tool acceptance rule is: expected recurrence × value × reliability gain > creation cost + maintenance cost + verification cost + risk cost + drift cost

But an implementation needs concrete thresholds. 21.1 Minimum observed recurrence A tool should not be synthesized until the system observes enough evidence. Example default: At least 5 successful similar trajectories AND at least 2 distinct contexts AND verification pass rate ≥ 90% AND no unresolved critical failures

For high-risk tools, thresholds should be higher. For low-risk text or formatting tools, thresholds can be lower. 21.2 Tool maturity levels Level Meaning Candidate Pattern detected, no execution. Draft Tool Tool spec exists, not used automatically. Shadow Tool Tool runs in parallel, but output is not trusted. Assisted Tool Tool suggests output, human or verifier approves. Active Tool Tool can execute within preconditions. Certified Tool Tool meets stronger verification and monitoring requirements. Retired Tool Tool no longer active. The system should not jump from detected pattern to automatic execution. ________________

22. Tool Rot and Revalidation Tools decay. APIs change. Dependencies break. Physical sensors drift. Environments shift. User preferences change. Lighting changes. Hardware degrades. A previously verified tool should not be trusted indefinitely. 22.1 Confidence decay Every tool should have a confidence decay policy. Example: confidence decays with: time since last successful execution environment drift dependency changes runtime changes failed executions low usage unresolved residuals

22.2 Revalidation triggers A tool should revalidate when: * dependency changes; * runtime target changes; * environment differs from known context; * failure rate rises; * residuals recur; * critical sensor or hardware state changes; * verification suite changes; * tool has not run recently; * tool crosses into a higher risk tier. 22.3 Critical runtime rule For robotics, fabrication, deployment, finance, security, and other high-risk runtimes: No tool remains trusted solely because it passed once. Critical tools require runtime monitoring, canaries, revalidation, and failsafe behavior. ________________

23. Evaluation Ratchet A VIEA system needs a way to improve over time. Benchmarks should function as curriculum. They should not be treated as static trophies. Benchmark statuses: Status Meaning Frontier Currently used to expose missing capability. Diagnostic Isolates a specific failure mode. Graduated Mastered enough to move forward. Regression Preserves prior capability. Public calibration Enables apples-to-apples comparison. Live Updated over time. Retired No longer useful. The system should not require 100% on every ordinary benchmark before moving on. For ordinary non-safety benchmarks, a starting mastery threshold might be 90%. If progress stalls, the threshold can decay toward a floor such as 70%. Critical failures still block graduation. The point is: Do not get stuck chasing the last 10% forever, but do not forget it either. Unsolved cases become residuals. A residual stores: source failure_type severity cluster recurrence_count reattempt_schedule promotion_status

Residuals are periodically reattempted. If a residual pattern keeps recurring, it becomes an active diagnostic target. The rule: Advance at mastery. Preserve the tail. Promote recurring residuals. ________________

24. Operational Metrics A metric is only useful if the system can compute it. VIEA should define metrics operationally. Metric Operational definition Ambiguity reduction Reduction in missing or uncertain command fields after drafting and confirmation. Command correction rate Percentage of auto-drafted command fields modified by the user. Claim support ratio Supported claims divided by total material claims. Critique resolution rate Resolved critiques divided by open critiques. Routing accuracy Specialist selections later validated by successful outputs or human/verifier approval. Routing residual recurrence Number of repeated routing failures by category. Integration failure rate Locally valid specialist outputs that fail whole-system compatibility. Rollback rate Percentage of integrated bundles rejected and rolled back after whole-system checks. Tool ROI Saved time/cost minus creation, maintenance, verification, and drift costs. Tool drift rate Frequency of tool failures caused by changed environment or dependencies. Artifact bloat rate Growth of active artifacts not referenced, reused, or linked to decisions. Runtime pass rate Runtime executions that pass verification and feedback checks. Human review budget usage Consumed review capacity divided by available qualified review capacity. Approval fatigue index Approval requests per approver per time period, weighted by risk tier. These metrics should feed the Evaluation Ratchet. ________________

25. Runtime Adapters The system should not just generate outputs. It should know what runtime the output is for. Different runtimes require different artifacts and verification. 25.1 Digital Runtime Produces: documents specs code apps agents APIs dashboards datasets workflows deployment bundles

Verification may include: * tests; * review; * output contract checks; * claim support; * regression comparison. 25.2 Hardware / Chip Runtime Produces: firmware embedded builds GPU kernels FPGA bitstreams target-specific binaries hardware-in-loop test plans

A hardware target profile should include: architecture memory limit power budget latency budget runtime constraints peripherals forbidden assumptions verification requirements

25.3 Fabrication Runtime Produces: requirements CAD or schematic artifact list simulation plan DFM / DFA checks bill of materials fabrication packet inspection plan assembly plan field-test plan

Fabrication pipeline: intent → requirements → CAD / schematic → simulation → manufacturability check → bill of materials → fabrication routing → fabrication → inspection → assembly → field test → feedback

A plausible physical design is not automatically safe or manufacturable. The fabrication runtime must check safety, tolerances, materials, process constraints, inspection requirements, and intended use. 25.4 Robotic Runtime Produces: controller motion plan sensor loop reflex/failsafe behavior telemetry plan

Robotic execution requires strong gates because it directly affects physical reality. For time-critical physical systems, fallback to slow reasoning may be unsafe. Reflex or failsafe behavior must be available. 25.5 Organizational Runtime Produces: standard operating procedures team workflows policies contracts business plans training programs release processes governance systems

Organizations are runtimes because they execute intent through people, incentives, roles, and processes. 25.6 Spatial Project Workspace Runtime Produces: project worlds visual artifact graphs collaborative workspaces simulation arenas world templates forkable project spaces

This is the VR/AR or spatial interface layer. It is not required for the MVP, but it becomes valuable as complexity grows. Every spatial object must map to a real artifact or state. Otherwise it is only visual decoration. ________________

26. Latency and Compute Control VIEA is structurally heavier than a chat response. That overhead is justified for high-impact execution but not for every small task. The system therefore needs execution tiers. Tier Use case VIEA overhead T0: Ephemeral Brainstorm, scratch note, low-risk drafting Minimal artifacting, optional claim tracking. T1: Draft Reusable text, internal analysis, low-risk code sketch Lightweight artifacts, basic provenance. T2: Work Product Specs, papers, code modules, workflows Full artifacts, claim ledger, critique, specialist routing. T3: Release Public output, shared tools, production-bound code Release gate, verification, provenance, residual tracking. T4: Execution Deployment, fabrication, robotics, finance, security Full command, runtime gates, approval, monitoring. T5: Critical Irreversible or safety-critical action Strict gate, certified process, refusal when appropriate. Rule: Use the cheapest process that is safe for the consequence level. 26.1 Lazy artifacting For low-risk work, the system may create artifact shells and fill details asynchronously. Example: User brainstorms quickly. System stores lightweight intent artifact. If the idea becomes important, the artifact is promoted and expanded.

26.2 Cached and incremental verification Verification should be incremental where possible. If unchanged claims, dependencies, or tests have already passed, the system can reuse prior evidence unless the runtime, dependency, or environment changed. 26.3 Budget-aware routing The Router should know: latency budget compute budget financial budget human review budget risk tier quality target

Not every task deserves every specialist. ________________

27. Resource and Economic Model VIEA needs explicit resource accounting. Without it, the system becomes either too expensive or artificially constrained. Every project should have a resource envelope: compute budget storage budget specialist invocation budget runtime execution budget human review budget latency budget fabrication budget maintenance budget

Human review budget is not secondary. It is one of the most important scarce resources in the system. 27.1 Cost tracking The system should track costs for: * specialist calls; * tool execution; * graph storage; * graph queries; * verification; * benchmark runs; * residual reattempts; * human approvals; * runtime execution; * fabrication; * deployment; * maintenance. 27.2 Tool ROI Every tool should eventually justify itself. Tool ROI = saved execution cost + saved user time + reliability improvement - creation cost - verification cost - maintenance cost - drift cost - failure cost

27.3 Budget gates If a task exceeds its budget envelope, the system should: * ask for approval; * reduce scope; * use cheaper specialists; * delay low-priority verification; * archive nonessential artifacts; * refuse nonessential execution. The system should not pretend computation, storage, human attention, and fabrication are free. ________________

28. Safety and Permission Model The system must distinguish between exploration and execution. Inside a private workspace, users should be able to explore freely. At the boundary to shared reality, gates apply. Stage Safety posture Exploration Free ideation and reversible manipulation. Simulation Mostly free, logged. Digital compile Verification required. Hardware compile Target constraints and regression required. Fabrication Safety, manufacturability, and inspection required. Deployment Approval, rollback, and monitoring required. High-risk action Strict gate, refusal, or certified process. Core rule: Nothing leaves a project workspace into shared reality without the correct gate. ________________

29. Spatial Project Workspace A spatial workspace is an interface layer for complex artifact manipulation. It should let users:

• create project worlds;
• see artifacts as objects;
• inspect claim graphs;
• manipulate diagrams and CAD;
• run simulations;
• summon specialists;
• invite collaborators;
• fork project versions;
• import public primitives;
• select compile targets. A project world stores: artifact graph active specialists tools benchmarks residuals compile targets collaborators permissions release history

The collaboration model should be: private by default collaborative by invitation public by release

Collaborator roles: * owner; * builder; * reviewer; * observer; * operator; * safety reviewer; * fabrication approver. All collaborator changes should be logged as events. ________________

30. Threat Model VIEA systems will be attacked because they connect intent to execution. Threats include: Threat Description Controls Prompt injection Malicious content tries to alter commands or tools. Command isolation, source labeling, permission envelopes. Artifact poisoning Bad artifacts inserted into graph to influence future work. Provenance, trust scores, review gates. Verifier capture Same model family verifies its own false outputs. Evidence hierarchy, external checks, model diversity. Permission escalation Tool or specialist gains more authority than intended. Least privilege, permission envelopes, audit logs. Tool rot Old verified tool fails under changed environment. Revalidation, confidence decay, monitoring. Routing sabotage Malicious or bad routing sends tasks to wrong specialists. Routing residuals, policy review, Conductor audit. Approval fatigue Humans approve too many requests and stop reviewing. Risk-based batching, qualified approval, fatigue metrics. Graph exfiltration Sensitive project artifacts are exposed. Access control, private-by-default worlds, audit logs. Fabrication misuse Unsafe physical designs are produced. Fabrication runtime gates, compliance review, refusal policies. Benchmark gaming System optimizes metric while losing real utility. Live benchmarks, residual tracking, public calibration. A VIEA system should be designed as infrastructure, not a toy assistant. ________________

31. Minimal Viable Implementation The first implementation should not attempt the entire vision. Do not start with full VR. Do not start with fabrication. Do not start with robotics. Do not start with chip compilation. Start with the core vertical loop: raw idea → auto-drafted command → artifact graph → claim ledger → critique log → structured paper/spec → release manifest → primitive extraction → feedback plan

Minimum components: artifact store command drafter claim ledger critique generator fast router small specialist registry release manifest generator primitive registry feedback record basic resource accounting

Basic resource accounting is non-negotiable in the MVP. If the MVP does not track compute, storage, specialist calls, and human review budget from the start, the system will appear cheaper and simpler than it really is. Minimum specialists: writing research claim audit skeptic review implementation planning safety review

Minimum outputs: whitepaper implementation spec claim ledger critique log release manifest build packet benchmark plan

The MVP should prove that the system can preserve, verify, route, and release work better than a chat log. ________________

32. Implementation Workstreams The implementation plan should not be treated as a strict waterfall. Several workstreams can evolve in parallel. Workstream 1 — Artifact Kernel Build:

• artifacts;
• relationships;
• provenance;
• versions;
• releases;
• feedback records;
• retention classes. Goal: Preserve work as structured memory. Workstream 2 — Structured Command Layer Build support for:
• raw intent;
• auto-drafted command contracts;
• quick command;
• working command;
• full command;
• command templates;
• command stacks;
• intent checksum;
• assumption diff. Goal: Reduce ambiguity without creating unnecessary user friction. Workstream 3 — Claim and Critique Ledger Build:
• claim extraction;
• support states;
• critique artifacts;
• release blockers;
• resolution tracking;
• evidence hierarchy;
• low-risk waiver records. Goal: Make outputs auditable without overburdening low-risk work. Workstream 4 — Router, Conductor, and Specialists Build:
• Fast Router;
• Slow Conductor;
• specialist registry;
• specialist input/output contracts;
• routing decisions;
• routing residuals;
• structured specialist outputs. Goal: Route tasks to bounded expertise and learn from routing failures. Workstream 5 — Integration Layer Build:
• integration contracts;
• global invariant checks;
• cross-specialist compatibility checks;
• whole-system pass;
• transactional rollback. Goal: Prevent contextual shattering. Workstream 6 — Workflow-to-Tool Compiler Build:
• trajectory logs;
• loop candidate detection;
• tool cards;
• shadow mode;
• verification records;
• tool registry;
• confidence decay. Goal: Turn repeated work into tools without creating tool rot. Workstream 7 — Evaluation Ratchet Build:
• benchmark ledger;
• mastery thresholds;
• regression suite;
• residual backlog;
• public calibration tracking;
• operational metrics. Goal: Make improvement measurable. Workstream 8 — Runtime Adapter Models Add conceptual adapters for:
• digital;
• hardware;
• fabrication;
• robotic;
• organizational;
• spatial workspace. Goal: Connect artifacts to execution targets. Workstream 9 — External Execution Add controlled execution into real runtimes:
• deploy code;
• route fabrication packets;
• run benchmarks;
• collect feedback. Goal: Close the loop with reality. ________________

33. Failure Modes 33.1 Output without artifact The system generates a response but does not store durable structure. Mitigation: Require artifacts for important outputs. 33.2 Unsupported claims The system produces confident but unsupported claims. Mitigation: Use claim ledger, support states, and evidence hierarchy. 33.3 Automation bias Users rubber-stamp incorrect auto-drafted commands. Mitigation: Use intent checksum, assumption diff, risk-based confirmation, and misalignment probes. 33.4 User friction The command layer becomes too heavy and users avoid it. Mitigation: Support raw intent, auto-drafted command contracts, quick commands, working commands, and full commands. 33.5 Artifact graph bloat The graph becomes too large, noisy, or expensive to traverse. Mitigation: Use retention classes, TTLs, hash-link rules, active context selection, summarization, archival states, and relevance scoring. 33.6 Epistemic collapse Specialists internally agree on false claims. Mitigation: Model consensus alone cannot verify. Require external evidence, tests, independent tools, expert review, or field feedback. 33.7 Specialist chaos Specialists produce incoherent or conflicting outputs. Mitigation: Use structured outputs, integration contracts, whole-system passes, and verifier routing. 33.8 Routing bottleneck The orchestrator becomes the weakest link. Mitigation: Split Fast Router and Slow Conductor. Track routing residuals. 33.9 Conductor bloat The Slow Conductor becomes a new monolithic reasoning system. Mitigation: Keep the Slow Conductor asynchronous, offline, log-driven, and policy-updating rather than runtime-blocking. 33.10 Contextual shattering Local specialist outputs fail when combined. Mitigation: Use Integration Layer, global invariants, compatibility checks, and transactional rollback. 33.11 Tool bloat Too many tools accumulate without value. Mitigation: Use observed recurrence thresholds, shadow mode, tool ROI, merge, and retirement lifecycle. 33.12 Tool rot Old tools fail under changed conditions. Mitigation: Use revalidation schedules, confidence decay, drift detection, canaries, and runtime monitoring. 33.13 Benchmark gaming The system optimizes scores without improving useful capability. Mitigation: Use live benchmarks, private holdouts, residual tracking, and public calibration distinction. 33.14 Residual erasure Failures are forgotten after graduation. Mitigation: Use residual backlog with reattempt schedules and recurrence promotion. 33.15 Approval fatigue Human reviewers become bottlenecks or rubber-stamp decisions. Mitigation: Use qualified approval roles, batching, fatigue metrics, and risk-tier gates. 33.16 Unsafe execution The system executes beyond safe bounds. Mitigation: Use runtime gates, permission envelopes, human approval, and refusal policies. 33.17 Fabrication overreach The system treats plausible physical designs as safe or manufacturable. Mitigation: Use simulation, manufacturability checks, inspection plans, compliance checks, and fabrication approval. 33.18 Cost explosion The system spends too much compute, storage, human review, or runtime budget. Mitigation: Use resource envelopes, cost tracking, budget gates, and tool ROI. 33.19 Architecture overreach The system attempts the full vision before proving the core loop. Mitigation: Build the vertical MVP first. ________________

34. Claims and Non-Claims Claims This paper claims:

35. AI systems need structured intent, not only prompts.

36. Durable artifact graphs are stronger than chat history for long-running work.

37. Claims should have explicit support states.

38. Model consensus alone should not count as verification.

39. Low-risk claim tracking can be waived, but waivers do not create evidence.

40. Specialist routing improves modularity and diagnosis when implemented with clear contracts and metrics.

41. Routing itself must be treated as a first-class problem with its own residuals.

42. The Slow Conductor should be asynchronous, log-driven, and policy-updating rather than runtime-blocking.

43. Integration must be treated as a first-class problem, not assumed after decomposition.

44. Failed high-impact integrations should roll back to the last known valid checkpoint.

45. Repeated workflows should become verified tools when valuable and safe.

46. Tools require revalidation because environments drift.

47. Benchmarks should be treated as moving curriculum.

48. Residual failures should be tracked rather than forgotten.

49. Runtime targeting is necessary for real execution.

50. Fabrication requires simulation, manufacturability checks, inspection, and approval.

51. Resource accounting is necessary for practical deployment.

52. Human review budget must be treated as a first-class resource.

53. The first build should prove a narrow vertical loop before expanding to full runtime execution. Non-Claims This paper does not claim:

54. The full system already exists.

55. AI should execute all user intent automatically.

56. Verification is absolute.

57. Structured commands eliminate ambiguity completely.

58. Users will carefully review every auto-drafted command.

59. Specialist modules always outperform monolithic systems.

60. Routing is easy.

61. Integration after decomposition is automatic.

62. Every repeated workflow should become a tool.

63. Benchmarks perfectly measure capability.

64. Physical artifacts should be fabricated without safety review.

65. VR/AR is required for all use cases.

66. Human approval alone solves safety.

67. AI replaces human responsibility.

68. The architecture can ignore compute, storage, financial, or human-review costs. ________________

69. Final Distillation Everything reduces to this: Intent → Command Contract → Artifact Graph → Routed Specialist Execution → Integration → Runtime Target → Verification Gate → Feedback → Improved System

Or in one sentence: VIEA is an operating environment that converts human intent into structured artifacts, routes work to bounded specialists, integrates their outputs, compiles results to the correct runtime, verifies execution, and uses feedback to improve future work. That is the architecture. ________________

36. One-Paragraph Summary Verified Intent-to-Execution Architecture is a systems framework for converting human goals into verified execution. It turns vague intent into structured command contracts, stores work in an artifact graph, tracks claims and critiques, routes subtasks to specialist modules, integrates specialist outputs, compiles repeated workflows into tools, evaluates progress through benchmark ratchets, targets outputs to digital, hardware, fabrication, robotic, organizational, or spatial runtimes, and feeds execution results back into the system. Its purpose is to reduce the distance between human intent and reliable action while preserving provenance, controlling permissions, tracking failures, accounting for cost, and preventing unsafe execution. ________________

37. Compact Operating Rules

38. If it matters, make it an artifact.

39. If it claims something, assign a support state.

40. If claim tracking is waived, record the waiver.

41. If the command is auto-drafted, show the intent checksum.

42. If the task is high-impact, require explicit confirmation of constraints and failure behavior.

43. If specialists disagree, preserve the disagreement.

44. If routing fails, log a routing residual.

45. If integration fails, log an integration residual.

46. If integration fails before execution, roll back to the last known valid checkpoint.

47. If it repeats, consider compiling it into a tool.

48. If a tool is old, revalidate it.

49. If it fails, track the residual.

50. If it is mastered, preserve it as regression.

51. If it executes, verify first.

52. If it affects shared reality, apply gates.

53. If it costs resources, account for them.

54. If it consumes human review, budget it.

55. If it produces feedback, update the system.

56. If it grows too broad, split it.

57. If it becomes stale, retire it. ________________

58. Closing The next major AI architecture may not be a single larger model. It may be an execution environment around models: structured commands artifact memory claim ledgers permission envelopes specialist routing integration contracts workflow compilation benchmark ratchets runtime adapters verification gates resource accounting feedback loops

That is the shift. From prompt to artifact. From response to execution. From chat history to provenance. From one-off generation to reusable tools. From static benchmarks to capability ratchets. From monolithic agents to routed specialists. From local outputs to integrated systems. From unpriced automation to resource-accounted execution. From output to verified action. The goal is not merely for AI to answer. The goal is for AI systems to help humans execute intent reliably. That is Verified Intent-to-Execution Architecture.

Tab 3 I treated the newest reviews as asking for a narrower, more honest, more buildable v1, not a larger one. The main changes are: the Slow Conductor is removed as a core subsystem, the paper now explicitly applies the M0–M5 maturity ladder to its own primitives, the Integration Layer is bounded rather than presented as omnipotent, adjacent work is positioned more clearly, and the implementation path is reduced to a one-month kernel prototype. ________________

Verified Intent-to-Execution Architecture From prompt → artifact → verified execution Author: Corben Sorenson Public Article v1.0 — May 2026 ________________

How to Read This Paper This paper is a reference architecture, not a claim that every subsystem already exists or is solved. The central proposal is narrow: AI systems should not stop at generating responses. They should convert intent into structured artifacts, verify those artifacts, execute through appropriate runtimes when warranted, and preserve feedback for future work. The full architecture is intentionally broader than the first implementation. The first implementation should be small. First build: intent → command contract → artifact graph → claim ledger → release manifest → feedback record

Everything else—specialist routing, tool compilation, benchmark ratchets, runtime adapters, fabrication, robotics, spatial workspaces—is expansion. ________________

Thesis AI systems are becoming very good at generating outputs. They can produce text, code, plans, summaries, diagrams, prototypes, workflows, and interface drafts. But generation is not execution. A generated response is not necessarily verified, durable, reusable, deployable, safe, or connected to feedback. The next major step is not simply making models larger. The next step is building systems that convert human intent into structured artifacts, preserve provenance, verify claims, execute through the correct runtime when appropriate, and learn from the result. I call this: Verified Intent-to-Execution Architecture or VIEA. The core loop is: intent → structured command → artifact graph → verification → runtime target → execution or release → feedback → improved system

VIEA is not a chatbot architecture. It is an operating architecture for moving from human intent to reliable execution. ________________

1. The Problem: AI Output Is Not Execution Most AI workflows today still look like this: user prompt ↓ model response ↓ human manually interprets, verifies, stores, implements, or discards

This creates a gap. A model can generate a useful response, but the work often remains trapped in the conversation. Claims are not tracked. Assumptions are not labeled. Repeated workflows are not compiled into tools. Failures are forgotten. Benchmarks are treated as static scores instead of moving curricula. Software, fabrication, hardware, robotics, and organizational execution are handled as separate worlds. The problem is not that AI cannot generate. The problem is that generation usually lacks a reliable execution architecture around it. A serious intent-to-execution system needs to answer: * What does the user actually want? * What artifact should be produced? * What claims are being made? * What evidence supports those claims? * What constraints must not be violated? * What runtime should this target? * What must be verified before execution? * What failures remain unresolved? * What feedback came back from use? * What should change next time? VIEA is designed to answer those questions systematically. ________________

2. Definition Verified Intent-to-Execution Architecture is a systems architecture that transforms human goals into structured, verifiable, executable artifacts. A VIEA system has three layers: VIEA Kernel VIEA Control Layer VIEA Expansion Layer

---

2.1 VIEA Kernel The smallest useful system: intent capture structured command contract artifact graph claim ledger critique log release manifest feedback record basic resource accounting

The kernel is the first thing to build. ________________

2.2 VIEA Control Layer The governance and coordination layer: provenance model permission model artifact retention rules fast router integration layer operational metrics routing policy review

The control layer makes the kernel scalable, auditable, and safer. ________________

2.3 VIEA Expansion Layer The long-term capability layer: specialist modules workflow-to-tool compiler evaluation ratchet runtime adapters spatial project workspace hardware target profiles fabrication handoff robotic control organizational workflow execution

The expansion layer should not be built until the kernel works. ________________

3. Final Distillation Everything reduces to this: Intent → Command Contract → Artifact Graph → Verification → Runtime Target → Feedback → Improved System

A more complete system adds routing, specialists, integration, tools, benchmarks, and runtime adapters. But the foundation is simple: Make intent explicit. Preserve work as artifacts. Track claims. Verify before execution. Record feedback. Improve the next run. ________________

4. Relationship to Adjacent Work VIEA is not claiming that each individual component is novel in isolation. Many ideas already exist in nearby fields: Adjacent field What VIEA borrows What VIEA adds Agent frameworks Tool use, routing, workflows, multi-step execution Durable artifact graph, claim ledger, integration contracts, runtime gates. Workflow systems / BPM / RPA Process modeling, repeatable workflows, task automation AI-native command contracts, claim states, residual tracking, tool compilation. Knowledge graphs / provenance systems Typed nodes, relationships, lineage Intent-to-execution framing and release/verification lifecycle. CI/CD and software release systems Gates, regression, rollback, deployment discipline Applies release thinking to AI-generated artifacts and multi-runtime outputs. Formal verification / testing Proofs, tests, invariants, executable checks Evidence hierarchy that prevents model consensus from being treated as verification. Data lineage / audit systems Provenance, permissions, compliance Extends lineage to AI-generated claims, decisions, tools, and feedback. Human-in-the-loop systems Review, approval, escalation Human review budget, approval fatigue, qualified authority model. The contribution is the synthesis: VIEA frames AI work as a pipeline from intent to verified execution, with artifacts, claims, permissions, integration, runtimes, and feedback as first-class objects. ________________

5. Maturity Levels for Named Primitives Architecture papers often name primitives before they are implemented. Naming is useful, but it can create the illusion that the mechanism is solved. VIEA explicitly distinguishes maturity levels. Level Meaning Example M0 — Named concept Useful term, not operationalized. “Workflow-to-tool compiler” before implementation. M1 — Schema Fields and data model defined. Claim object with support state and evidence links. M2 — Policy Rules exist for how state changes. Claim downgrade policy. M3 — Instrumented mechanism System can compute or track it. Artifact bloat rate. M4 — Validated mechanism Shown useful in real workflows. Claim ledger improving release quality. M5 — Governed infrastructure Deployed, monitored, permissioned, maintained. Runtime adapter with gates and audit logs. No named primitive should be assumed solved merely because it has a name. ________________

6. Maturity Audit of VIEA Primitives This table applies the maturity ladder to VIEA itself. Primitive Initial maturity Notes Command Contract M1–M2 Schema is defined; risk-based confirmation policies are defined. Intent Checksum M1 Schema is clear; usefulness needs testing. Assumption Diff M1 Schema is clear; extraction remains model-dependent. Artifact Graph M1–M2 Artifact types, fields, and relationships are defined. Artifact Retention Rules M2 TTL and hash-link rules are specified. Claim Ledger M1–M2 States are defined; extraction is assisted, not solved. Claim Ledger Waiver M2 Conditions, limits, and waiver record are specified. Evidence Hierarchy M2 Policy is specified: model consensus alone cannot verify. Critique Log M1–M2 Critique states can be defined; critique quality remains model/human-dependent. Release Manifest M1 Schema can be built immediately. Feedback Record M1 Schema can be built immediately. Permission Envelope M1–M2 Fields and tiers are defined; enforcement depends on implementation. Fast Router M1–M2 Inputs, outputs, and budget caps are specified; quality requires measurement. Routing Policy Review M1 Human-led or offline review process; not autonomous learning. Routing Residuals M1–M2 Categories are defined; instrumentation required. Specialist Output Contract M1 Schema is defined; compliance depends on module implementation. Integration Contract M1–M2 Schema and bounded check types are defined. Transactional Rollback M2 Policy is clear for high-impact integrated bundles. Workflow-to-Tool Compiler M0–M1 Lifecycle is defined; synthesis from trajectories remains research-heavy. Tool Confidence Decay M1–M2 Triggers are defined; decay functions need tuning. Evaluation Ratchet M2 Benchmark lifecycle and residual handling are specified. Operational Metrics M1–M2 Numerators and denominators can be defined; instrumentation required. Digital Runtime Adapter R1–R2 Planning and sandboxed execution are realistic early targets. Hardware / Chip Runtime Adapter R0–R1 Target profile and planning adapter first. Fabrication Runtime Adapter R0–R1 Handoff package first, not autonomous fabrication. Robotic Runtime Adapter R0 Specification target only in MVP. Organizational Runtime Adapter R1 Planning and reviewed workflow generation first. Spatial Workspace Runtime R0–R1 Interface concept; not needed for kernel. This table is deliberately conservative. The VIEA Kernel can be built while many advanced primitives remain at M0 or M1. ________________

7. Where the Model Fits VIEA is architecture around models, not a replacement for models. The model participates in several roles: Role Function Command drafter Converts raw intent into structured command candidates. Extractor Proposes claims, requirements, critiques, residuals, and artifacts. Synthesizer Produces candidate outputs from structured context. Specialist engine Powers writing, research, code, design, critique, or planning modules. Router assistant Helps classify tasks and select specialists. Verifier assistant Proposes checks, but cannot verify by model agreement alone. VIEA does not assume the model is reliable by default. The model proposes. The architecture records. The ledger classifies. The router scopes. The integration layer checks. The runtime gate verifies. Feedback corrects. 7.1 Model capability assumptions VIEA requires only modest model capability for the MVP:

• draft a command contract from natural language;
• extract candidate claims;
• produce structured outputs;
• summarize artifacts;
• suggest critiques;
• assist with release manifests. The MVP does not require the model to:
• perfectly understand user intent;
• perfectly verify claims;
• autonomously synthesize safe tools;
• coordinate complex multi-agent execution;
• fabricate physical objects;
• control robots;
• solve all routing problems. 7.2 Model limitation policy When model capability is uncertain, VIEA should: lower claim state ask for confirmation route to human review run external checks create residual avoid execution

A VIEA system should never hide model uncertainty behind architectural ceremony. ________________

8. Intent Capture and Command Drafting A major failure mode for structured systems is user friction. Humans often do not want to fill out a form before they begin. They want to say: Make this better.

VIEA must support that. The system should provide a friction gradient: Level User experience System behavior Raw Intent “Make this better.” System infers likely objective and drafts a command contract. One-Line Command “Make this release-ready and don’t overclaim.” System fills missing fields automatically. Quick Command Role, Objective, Context, Verification Useful for low-risk bounded work. Working Command Role, Objective, Context, Constraints, Output, Verification Useful for normal engineering, writing, and analysis. Full Command All eight fields Required for public release, deployment, fabrication, security, or high-impact execution. The user should be able to start with natural language. The system should draft the structure. The user should only have to approve or correct fields when the stakes justify the overhead. ________________

9. Automation Bias Control Auto-drafted command contracts create a new risk: users may approve a plausible but wrong contract. If the system misinterprets intent and the user rubber-stamps it, the system can execute perfectly against the wrong objective. VIEA therefore needs automation bias controls. 9.1 Intent checksum For any medium- or high-impact task, the system should produce an intent checksum: a short plain-language summary of what it believes the user wants. Example: Intent checksum: You want this draft revised into a public v1.0 architecture article. The priority is defensibility and clarity, not maximum novelty. The system should preserve speculative ideas but label them clearly.

The user does not need to inspect every field. They need to confirm the core intent. 9.2 Assumption diff The system should list material assumptions it inferred. Assumptions inferred: - Target audience: technical AI / systems readers. - Output: public article, not implementation spec. - Tone: systems engineering, not marketing. - Evidence standard: conceptual but non-overclaiming.

If these are wrong, the user can correct them before execution. 9.3 Risk-based confirmation Confirmation should scale with risk. Risk level Confirmation requirement Low Proceed automatically after showing summary. Medium User confirms objective and output contract. High User confirms objective, constraints, verification, and failure behavior. Critical Explicit approval from qualified authority required. 9.4 Misalignment probe For important tasks, the system should ask one adversarial check: Before I proceed: is there anything important this command should NOT optimize for?

This catches cases where the drafted contract is plausible but wrong. 9.5 No silent hardening If a raw request is ambiguous, the system may draft a command, but it should not silently convert the task into a high-impact workflow. Rule: The system may infer structure, but it must not silently infer authority. ________________

10. Structured Command Layer The standard command contract has eight fields: Field Meaning Role What kind of expertise is being invoked. Objective What outcome matters most. Context What is already true. Constraints What must not be violated. Procedure How the system should proceed. Output Contract What shape the result must take. Verification How correctness will be checked. Failure Behavior What to do if context is missing, unsafe, or contradictory. Example: Role: Technical editor and systems reviewer.

Objective: Convert the draft into a release-ready architecture paper.

Context: The draft describes an AI-assisted intent-to-execution system.

Constraints: Do not overclaim. Preserve speculative ideas as speculative.

Procedure: Extract claims, improve structure, add failure modes, add implementation roadmap.

Output Contract: Return a complete revised paper.

Verification: Check unsupported claims, missing definitions, and safety gaps.

Failure Behavior: Label missing evidence rather than inventing support.

The purpose is not bureaucracy. The purpose is to partially compile intent before execution. ________________

11. Artifact Graph Chat history is weak memory. Artifacts are strong memory. A VIEA system should store work as typed artifacts, not just conversation transcripts. Core artifact types include: Intent Command Claim Source Critique Requirement Decision Design Diagram CodeModule CADObject Simulation Tool Workflow Benchmark Residual CompileTarget RuntimeAdapter Release Feedback Primitive World

Each artifact should have: id type title content owner version created_at updated_at provenance links permissions verification_state release_state retention_class activity_state hash_links

Artifacts should also have relationships: Relationship Meaning supports Evidence supports a claim. contradicts Evidence or critique challenges a claim. implements Artifact implements a requirement. validates Test or benchmark validates artifact. depends_on Artifact depends on another artifact. derives_from Artifact came from another artifact. supersedes Artifact replaces earlier artifact. blocks Artifact blocks release or execution. compiled_to Artifact compiled to a runtime target. produced_feedback Execution produced feedback. generalizes_to Pattern became a primitive or tool. This turns a project from a pile of text into a durable graph of intent, work, evidence, and outcomes. ________________

12. Artifact Retention and Relevance Control A typed artifact graph is better than chat history, but it creates a new problem: If everything becomes an artifact, the graph can become too large to use. VIEA needs concrete retention and relevance policies. 12.1 Artifact classes Artifact class Examples Default behavior Core Commands, claims, decisions, requirements, releases, tools, feedback Preserve indefinitely unless explicitly retired. Support Drafts, intermediate analyses, source summaries, design alternatives Preserve, summarize after inactivity, keep provenance. Transient Scratch work, temporary decompositions, abandoned alternatives Expire or compress after a short TTL unless linked. Archived Old versions, stale branches, inactive project artifacts Searchable but excluded from default context. Deprecated Superseded artifacts and rejected claims Retained for provenance but hidden from normal routing. 12.2 Example retention rules Transient artifacts: summarize after 48 hours if not hash-linked to a core or support artifact archive after 7 days if inactive and unlinked delete only if no provenance obligation exists

Support artifacts: summarize after 30 days of inactivity archive after 90 days if not referenced preserve source links and decision impact

Core artifacts: never auto-delete may be superseded, deprecated, or archived remain available for audit

Residual artifacts: keep active while recurring archive only after resolution or explicit waiver

12.3 Hash-link rule A transient artifact should survive only if it becomes relevant. Rule: If a transient artifact is not hash-linked to a core artifact, support artifact, residual, decision, tool, or release within 48 hours, it should be summarized and marked for pruning. This prevents scratch output from polluting long-term retrieval. 12.4 Active context selection The system should not load the whole graph into every task. It should select context by: * current command; * artifact type; * dependency distance; * recency; * verification state; * specialist scope; * runtime target; * permission envelope; * residual relevance. Rule: Preserve provenance, but route relevance. The Artifact Graph is not an unbounded memory dump. It is an indexed, typed, versioned, selectively activated memory system. ________________

13. Claim and Verification Ledger AI systems often mix facts, assumptions, predictions, speculation, and confident guesses. Every important claim should have a support state. State Meaning Verified Proven or directly validated by deterministic check, formal proof, reproducible test, or authoritative record. Empirically supported Supported by experiment, benchmark, or measured result. Source-backed Supported by cited external material. Reasoned inference Plausible but not directly proven. Speculative Hypothesis or conceptual possibility. Unsupported No current support. Contradicted Evidence argues against it. Requires experiment Needs empirical test. Requires expert review Needs domain-specific review. Deprecated No longer active. Waived Claim tracking intentionally waived for a low-risk context. The rule is: Speculation is allowed. Unlabeled speculation is not. ________________

14. Claim Ledger Waivers Not every low-risk artifact needs heavy claim tracking. A quick internal email, brainstorming note, or low-impact draft should not pay the full verification cost of a public release. VIEA therefore supports claim ledger waivers. 14.1 When waivers are allowed Claim tracking may be waived when:

• the output is low-risk;
• the artifact is not public;
• the artifact does not instruct execution;
• the artifact does not make safety, legal, medical, financial, or empirical claims;
• the artifact is not used as evidence for another artifact;
• the user or policy allows lightweight treatment. 14.2 Waiver record A waiver is itself an artifact. It should record: artifact_id waiver_reason risk_tier scope expiration approver_or_policy

14.3 Waiver limits A waived claim cannot support high-impact downstream artifacts without reactivation. Rule: A waiver reduces local overhead; it does not create evidence. If a waived artifact later becomes part of a release, deployment, fabrication packet, or benchmark claim, its claims must be re-extracted and assigned support states. ________________

15. Epistemic Collapse Control A claim ledger is only useful if verification is not just another model agreeing with itself. If the same underlying model powers the generator, researcher, skeptic, and verifier, the system can reach internal consensus on false claims. VIEA therefore requires an evidence hierarchy. 15.1 Evidence hierarchy Evidence level Examples Maximum claim state Internal model agreement Multiple specialists agree without external evidence Reasoned inference at most. Source citation External document, dataset, repository, standard, publication Source-backed. Executable check Test, benchmark, simulation, proof, static analysis, reproducible run Verified or empirically supported depending on check. Independent system check Different model family, independent tool, external validator Raises confidence but still needs evidence. Expert or authority review Qualified human or governing body Reviewed / approved, with scope. Field feedback Deployment, fabrication, user telemetry, real-world result Empirically supported or contradicted. Critical rule: Model consensus alone cannot mark a claim as verified. It can mark a claim as plausible, inferred, or recommended for testing. 15.2 Claim downgrade policy If support expires, sources are challenged, tests fail, or feedback contradicts the claim, the claim state must downgrade automatically. Example: Source-backed → requires review Empirically supported → contradicted Verified → deprecated or blocked

Verification is not a stamp forever. It is a maintained state. ________________

16. Provenance and Permission Model Every artifact should know: who created it who modified it what generated it what it depends on what evidence supports it what permissions govern it what runtime it may target what release boundary it may cross

Every tool, specialist, and runtime adapter should operate under a permission envelope: memory access tool access runtime access side-effect allowance budget risk tier approval requirements audit requirements

The system should default to least privilege. 16.1 Permission tiers Tier Example Requirements Read-only Summarize artifact, inspect claim graph No mutation. Draft Generate proposal, create candidate artifact No release or execution. Edit Modify artifact or tool candidate Versioning and provenance required. Execute digital Run code, call API, deploy to test environment Verification and sandboxing required. Execute physical Fabricate, actuate, route to robotics Safety gate and approval required. Public release Publish artifact, release primitive, send external communication Release gate required. Critical action Production mutation, financial action, robotics actuation, irreversible execution Strict gate, qualified approval, or refusal. The system must know the difference between drafting, executing, fabricating, deploying, and publishing. ________________

17. Approval Authority and Human Bottleneck Control “Human approval” is not enough as a safety model. The system needs to know:

• who is approving;
• whether they are qualified;
• what authority they have;
• what risk tier they may approve;
• whether approval fatigue is likely;
• what happens when approvers are unavailable. 17.1 Approval roles Role Can approve Owner Low/medium project decisions. Domain reviewer Domain-specific technical claims. Safety reviewer Safety gates, risk classifications, refusals. Release approver Public release boundaries. Fabrication approver Physical production handoffs. Deployment approver Production digital deployment. Critical authority High-risk or irreversible actions. 17.2 Human review as a resource Human review capacity is a first-class resource. A project should track: available reviewers reviewer qualifications review queue length approval latency approval fatigue index review budget critical approval coverage

Rule: Human approval must be qualified, scoped, rate-limited, and budgeted. Otherwise it becomes theater. ________________

18. Fast Router and Routing Policy Review Earlier versions of this architecture included a Slow Conductor as a major subsystem. That was too broad. The production-minded version replaces it with a narrower concept: Fast Router = runtime routing policy execution Routing Policy Review = periodic human/offline review of routing residuals

18.1 Fast Router The Fast Router is the low-latency policy layer. It handles: * initial specialist selection; * permission envelope assignment; * context packaging; * risk-tier routing; * default tool selection; * simple fallback decisions; * token budget enforcement; * compute budget enforcement; * latency budget enforcement. It should be deterministic or policy-constrained wherever possible. 18.2 Fast Router budget caps A routing decision should include: max specialist calls max tokens / context budget max compute budget max latency max financial cost max human review requests risk tier fallback behavior

If the request exceeds budget, the system should: * reduce scope; * choose cheaper specialists; * run a quick path; * ask for budget approval; * defer expensive verification; * refuse nonessential execution. 18.3 Routing Policy Review Routing policy should improve through periodic review, not by assuming an autonomous meta-agent can solve routing. Inputs: routing residuals specialist performance metrics integration failures cost reports user corrections approval delays runtime failures feedback records

Outputs: updated routing rules specialist scope changes new routing tests permission policy updates budget policy updates recommendations for split/merge/retire

This can initially be human-led. The architecture does not require autonomous routing-policy learning. ________________

19. Routing Residuals Routing failures are first-class residuals. Examples: Routing residual Meaning Wrong specialist selected The chosen module lacked needed expertise. Missing specialist No available module fit the task. Context under-allocation Specialist lacked needed information. Context over-allocation Specialist received irrelevant or unsafe information. Conflict unresolved Specialist outputs disagreed without resolution. Verifier skipped Output needed review but was not routed to verifier. Over-routing Too many specialists were called. Under-routing Too few specialists were called. Permission mismatch Specialist lacked or exceeded necessary authority. Routing residuals should feed Routing Policy Review. ________________

20. Specialist Modules Specialist modules are bounded subsystems with defined scopes. Examples: Module Scope Writing Module Structure, clarity, tone, final polish. Research Module Sources, related work, evidence gathering. Claim Audit Module Extract and classify claims. Skeptic Module Challenge assumptions and identify weaknesses. Code Module Generate, review, patch, and test software. CAD Module Create or revise geometry and assemblies. Simulation Module Run or specify tests and simulations. Fabrication Module Plan manufacturability and production handoff. Hardware Target Module Adapt software to chip or embedded constraints. Benchmark Module Design evaluations and track capability. Safety Module Identify risk, enforce gates, veto unsafe actions. Deployment Module Release planning, rollout, monitoring, rollback. Memory Module Retrieve relevant artifacts, history, and context. Each specialist should have: name scope input_schema output_schema allowed_tools memory_scope permission_level benchmarks residuals runtime_tier lifecycle_status cost_profile

Specialists should be created, evaluated, benchmarked, updated, split if they become too broad, merged if redundant, and retired if stale. ________________

21. Specialist Output Contracts Specialists should not return unstructured text by default. They should return structured outputs. A specialist output should include: result confidence assumptions evidence compatibility_requirements risks residuals recommended_next_steps required_verification provenance cost

This helps the system compose outputs reliably. It also makes disagreement manageable. If the Research Module says a claim is source-backed and the Skeptic Module says it is overclaimed, the system should not flatten both into one vague paragraph. It should preserve the disagreement, route to verification, or expose the uncertainty. ________________

22. Integration Layer Bounded specialists reduce monolithic chaos, but they introduce a new failure mode: Specialists can produce locally valid outputs that are globally incompatible. This is contextual shattering. Example:

• Code Module produces valid memory logic.
• Hardware Target Module produces valid hardware constraints.
• Each is correct locally.
• The integrated system fails because the memory logic violates the hardware constraints. VIEA therefore needs an Integration Layer. 22.1 Integration is bounded A whole-system pass is not magic. Integration checks fall into three categories. Check type Examples Strength Directly checkable Schemas, interfaces, permissions, resource budgets, runtime targets, dependency versions Strong. Testable with effort Build tests, integration tests, simulations, canaries, hardware-in-loop plans Medium to strong depending on coverage. Not fully checkable before execution Conceptual fit, long-term effects, human usefulness, real-world robustness Must remain assumptions or residuals. The Integration Layer should not pretend to prove what it cannot prove. It should classify checks by strength. 22.2 Integration contract Every multi-specialist task should define an integration contract: global objective shared constraints required interfaces runtime target resource budget critical invariants integration tests failure boundaries rollback behavior

22.3 Transactional integration and rollback For high-impact tasks, a set of specialist outputs should be treated as a single transaction. If global integration fails, the system should not partially apply the outputs. It should: 1. reject the integrated candidate; 2. preserve the failed integration bundle as an artifact; 3. roll back to the last known valid checkpoint; 4. log an integration residual; 5. route the residual to review or relevant specialists; 6. require a revised integration candidate before execution.

Rule: Locally valid outputs do not become executable until the integrated state passes bounded checks. ________________

23. Workflow-to-Tool Compiler If the system repeats the same workflow many times, it should not keep redoing the workflow from scratch. Repeated work should become a tool. The process is:
24. Log successful trajectories.
25. Cluster similar trajectories.
26. Identify invariant steps.
27. Identify variable parameters.
28. Discover hidden assumptions.
29. Define preconditions.
30. Define postconditions.
31. Synthesize tool candidate.
32. Run in shadow mode.
33. Verify tool candidate.
34. Register tool.
35. Route future tasks to tool under conditions.
36. Monitor tool.
37. Revise or retire tool.

This subsystem is M0–M1 in the current architecture. It is important, but it should not be part of the first build. ________________

24. Tool Compiler Acceptance Rules A workflow should not become a tool merely because it repeats. Example default threshold: At least 5 successful similar trajectories AND at least 2 distinct contexts AND verification pass rate ≥ 90% AND no unresolved critical failures

24.1 Tool maturity levels Level Meaning Candidate Pattern detected, no execution. Draft Tool Tool spec exists, not used automatically. Shadow Tool Tool runs in parallel, output is not trusted. Assisted Tool Tool suggests output, human or verifier approves. Active Tool Tool can execute within preconditions. Certified Tool Tool meets stronger verification and monitoring requirements. Retired Tool Tool no longer active. The system should not jump from detected pattern to automatic execution. ________________

25. Tool Rot and Revalidation Tools decay. APIs change. Dependencies break. Physical sensors drift. Environments shift. User preferences change. Lighting changes. Hardware degrades. A previously verified tool should not be trusted indefinitely. Revalidation should trigger when:

• dependency changes;
• runtime target changes;
• environment differs from known context;
• failure rate rises;
• residuals recur;
• verification suite changes;
• tool has not run recently;
• tool crosses into a higher risk tier. Critical rule: No tool remains trusted solely because it passed once. ________________

26. Evaluation Ratchet A VIEA system needs a way to improve over time. Benchmarks should function as curriculum. Benchmark statuses: Status Meaning Frontier Exposes missing capability. Diagnostic Isolates a failure mode. Graduated Mastered enough to move forward. Regression Preserves prior capability. Public calibration Enables apples-to-apples comparison. Live Updated over time. Retired No longer useful. The system should not require 100% on every ordinary benchmark before moving on. For ordinary non-safety benchmarks, a starting mastery threshold might be 90%. If progress stalls, the threshold can decay toward a floor such as 70%. Critical failures still block graduation. The point is: Do not get stuck chasing the last 10% forever, but do not forget it either. Unsolved cases become residuals. The rule: Advance at mastery. Preserve the tail. Promote recurring residuals. ________________

27. Runtime Adapter Scope The runtime adapters are not equally mature. They should not be treated as equally solved. 27.1 Runtime maturity ladder Level Meaning R0 — Contract only Output contract defined, no execution. R1 — Planning adapter Produces plans, specs, or checklists. R2 — Sandboxed execution Executes in controlled digital environment. R3 — Verified execution Executes with tests, gates, and rollback. R4 — External handoff Produces packages for external fabrication, deployment, or review. R5 — Closed-loop runtime Executes, monitors, and feeds results back automatically. The MVP should mostly target R0–R2. Physical, robotic, and organizational runtimes should begin as planning or handoff adapters, not autonomous execution systems. ________________

28. Runtime Adapters Different runtimes require different artifacts and verification. 28.1 Digital Runtime Produces: documents specs code apps agents APIs dashboards datasets workflows deployment bundles

This is the first runtime VIEA should implement. 28.2 Hardware / Chip Runtime Produces: firmware embedded builds GPU kernels FPGA bitstreams target-specific binaries hardware-in-loop test plans

In the early system, this should be a profile and planning adapter, not necessarily an automatic compiler. 28.3 Fabrication Runtime Produces: requirements CAD or schematic artifact list simulation plan DFM / DFA checks bill of materials fabrication packet inspection plan assembly plan field-test plan

In the MVP, fabrication should remain a handoff package, not autonomous fabrication. 28.4 Robotic Runtime Produces: controller motion plan sensor loop reflex/failsafe behavior telemetry plan

Robotic runtime is out of scope for the MVP except as a specification target. 28.5 Organizational Runtime Produces: standard operating procedures team workflows policies contracts business plans training programs release processes governance systems

In early VIEA, organizational runtime should produce reviewed plans, not automatically impose policies. 28.6 Spatial Project Workspace Runtime Produces: project worlds visual artifact graphs collaborative workspaces simulation arenas world templates forkable project spaces

This is not required for the MVP. Every spatial object must map to a real artifact or state. Otherwise it is only visual decoration. ________________

29. Latency and Compute Control VIEA is heavier than a chat response. That overhead is justified for high-impact execution but not for every small task. The system therefore needs execution tiers. Tier Use case VIEA overhead T0: Ephemeral Brainstorm, scratch note, low-risk drafting Minimal artifacting, optional claim tracking. T1: Draft Reusable text, internal analysis, low-risk code sketch Lightweight artifacts, basic provenance. T2: Work Product Specs, papers, code modules, workflows Full artifacts, claim ledger, critique, specialist routing. T3: Release Public output, shared tools, production-bound code Release gate, verification, provenance, residual tracking. T4: Execution Deployment, fabrication, robotics, finance, security Full command, runtime gates, approval, monitoring. T5: Critical Irreversible or safety-critical action Strict gate, certified process, refusal when appropriate. Rule: Use the cheapest process that is safe for the consequence level. ________________

30. Resource and Economic Model VIEA needs explicit resource accounting. Every project should have a resource envelope: compute budget storage budget specialist invocation budget runtime execution budget human review budget latency budget fabrication budget maintenance budget

Human review budget is one of the most important scarce resources in the system. The system should track costs for: * specialist calls; * tool execution; * graph storage; * graph queries; * verification; * benchmark runs; * residual reattempts; * human approvals; * runtime execution; * fabrication; * deployment; * maintenance. The system should not pretend computation, storage, human attention, and fabrication are free. ________________

31. Reduction to Practice The most important practical question is: What should be built first? The answer is the VIEA Kernel. 31.1 The one-month build A realistic one-month prototype should build: artifact store structured command drafter claim ledger critique log release manifest feedback record basic resource accounting

It should support one workflow: raw idea or draft → auto-drafted command → artifact graph → candidate claims → user-correctable claim states → critique log → revised artifact → release manifest → feedback plan

This is enough to test whether VIEA is useful. 31.2 MVP claim extraction is assisted, not solved The MVP should not claim to solve reliable claim extraction. It should: extract candidate claims; label confidence; ask the user to confirm material claims; allow low-risk waivers; route uncertain claims to review; track unresolved claims as artifacts.

31.3 MVP critique generation is advisory, not authoritative The critique generator should propose critiques. It should not be treated as final truth. Critiques should have states: proposed accepted rejected resolved waived requires review

31.4 MVP success condition The MVP succeeds if it can take a serious idea or draft and produce: structured command artifact graph claim ledger critique log revised artifact release manifest feedback plan

better than a normal chat workflow. That is the first proof. ________________

32. Operational Metrics A metric is only useful if the system can compute it. VIEA should define metrics with explicit numerator and denominator. Metric Numerator Denominator Command correction rate Auto-drafted fields changed by user Auto-drafted fields shown to user Claim support ratio Claims with verified, empirical, source-backed, or accepted inference state Material claims in artifact Critique resolution rate Critiques resolved, accepted, or waived Open critiques created Artifact bloat rate Active artifacts unlinked to core/support artifacts after TTL Total active artifacts Routing residual rate Routing residuals logged Routed tasks Integration failure rate Integrated bundles rejected Integration attempts Rollback rate Bundles rolled back High-impact integration attempts Tool drift rate Tool failures caused by environment/dependency drift Tool executions Human review budget usage Review minutes consumed Review minutes budgeted Runtime pass rate Runtime executions passing verification Runtime executions attempted These metrics should feed improvement decisions. ________________

33. Safety and Permission Model The system must distinguish between exploration and execution. Inside a private workspace, users can explore freely. At the boundary to shared reality, gates apply. Stage Safety posture Exploration Free ideation and reversible manipulation. Simulation Mostly free, logged. Digital compile Verification required. Hardware compile Target constraints and regression required. Fabrication Safety, manufacturability, and inspection required. Deployment Approval, rollback, and monitoring required. High-risk action Strict gate, refusal, or certified process. Core rule: Nothing leaves a project workspace into shared reality without the correct gate. ________________

34. Threat Model VIEA systems will be attacked because they connect intent to execution. Threat Description Controls Prompt injection Malicious content tries to alter commands or tools. Command isolation, source labeling, permission envelopes. Artifact poisoning Bad artifacts inserted into graph to influence future work. Provenance, trust scores, review gates. Verifier capture Same model family verifies its own false outputs. Evidence hierarchy, external checks, model diversity. Permission escalation Tool or specialist gains more authority than intended. Least privilege, permission envelopes, audit logs. Tool rot Old verified tool fails under changed environment. Revalidation, confidence decay, monitoring. Routing sabotage Bad routing sends tasks to wrong specialists. Routing residuals, policy review. Approval fatigue Humans approve too many requests and stop reviewing. Risk-based batching, qualified approval, fatigue metrics. Graph exfiltration Sensitive project artifacts are exposed. Access control, private-by-default workspaces, audit logs. Fabrication misuse Unsafe physical designs are produced. Fabrication runtime gates, compliance review, refusal policies. Benchmark gaming System optimizes metric while losing real utility. Live benchmarks, residual tracking, public calibration. A VIEA system should be designed as infrastructure, not a toy assistant. ________________

35. Failure Modes 35.1 Output without artifact The system generates a response but does not store durable structure. Mitigation: Require artifacts for important outputs. 35.2 Unsupported claims The system produces confident but unsupported claims. Mitigation: Use claim ledger, support states, and evidence hierarchy. 35.3 Vocabulary outpaces mechanism The paper or implementation names a primitive before making it operational. Mitigation: Assign maturity levels to primitives. Distinguish concepts, schemas, policies, metrics, and implemented mechanisms. 35.4 Automation bias Users rubber-stamp incorrect auto-drafted commands. Mitigation: Use intent checksum, assumption diff, risk-based confirmation, and misalignment probes. 35.5 User friction The command layer becomes too heavy and users avoid it. Mitigation: Support raw intent, auto-drafted command contracts, quick commands, working commands, and full commands. 35.6 Artifact graph bloat The graph becomes too large, noisy, or expensive to traverse. Mitigation: Use retention classes, TTLs, hash-link rules, active context selection, summarization, archival states, and relevance scoring. 35.7 Epistemic collapse Specialists internally agree on false claims. Mitigation: Model consensus alone cannot verify. Require external evidence, tests, independent tools, expert review, or field feedback. 35.8 Model capability mismatch The architecture assumes a model can perform tasks it cannot reliably perform. Mitigation: Treat model outputs as proposals. Lower claim states, require confirmation, and use human-assisted extraction where needed. 35.9 Contextual shattering Local specialist outputs fail when combined. Mitigation: Use Integration Layer, bounded checks, global invariants, compatibility tests, and transactional rollback. 35.10 Runtime abstraction overreach The paper treats all runtimes as equally mature or equally solvable. Mitigation: Use runtime maturity levels. Start with digital and planning adapters before physical or robotic execution. 35.11 Tool bloat Too many tools accumulate without value. Mitigation: Use observed recurrence thresholds, shadow mode, tool ROI, merge, and retirement lifecycle. 35.12 Tool rot Old tools fail under changed conditions. Mitigation: Use revalidation schedules, confidence decay, drift detection, canaries, and runtime monitoring. 35.13 Benchmark gaming The system optimizes scores without improving useful capability. Mitigation: Use live benchmarks, private holdouts, residual tracking, and public calibration distinction. 35.14 Approval fatigue Human reviewers become bottlenecks or rubber-stamp decisions. Mitigation: Use qualified approval roles, batching, fatigue metrics, and risk-tier gates. 35.15 Unsafe execution The system executes beyond safe bounds. Mitigation: Use runtime gates, permission envelopes, human approval, and refusal policies. 35.16 Cost explosion The system spends too much compute, storage, human review, or runtime budget. Mitigation: Use resource envelopes, cost tracking, budget gates, and tool ROI. 35.17 Architecture overreach The system attempts the full vision before proving the core loop. Mitigation: Build the VIEA Kernel first. ________________

36. Claims and Non-Claims Claims This paper claims:

37. AI systems need structured intent, not only prompts.

38. Durable artifact graphs are stronger than chat history for long-running work.

39. Claims should have explicit support states.

40. Model consensus alone should not count as verification.

41. Low-risk claim tracking can be waived, but waivers do not create evidence.

42. VIEA primitives should be labeled by maturity level.

43. The first implementation should build the kernel, not the full architecture.

44. Integration must be treated as a first-class problem, not assumed after decomposition.

45. Integration checks are bounded and vary in strength.

46. Repeated workflows should become verified tools only when valuable and safe.

47. Tools require revalidation because environments drift.

48. Benchmarks should be treated as moving curriculum.

49. Residual failures should be tracked rather than forgotten.

50. Runtime targeting is necessary for real execution.

51. Runtime adapters should have maturity levels rather than being treated as equally solved.

52. Fabrication requires simulation, manufacturability checks, inspection, and approval.

53. Resource accounting is necessary for practical deployment.

54. Human review budget must be treated as a first-class resource. Non-Claims This paper does not claim:

55. The full system already exists.

56. AI should execute all user intent automatically.

57. Verification is absolute.

58. Structured commands eliminate ambiguity completely.

59. Users will carefully review every auto-drafted command.

60. Specialist modules always outperform monolithic systems.

61. Routing is easy.

62. Autonomous routing-policy learning is solved.

63. Integration after decomposition is automatic.

64. Every named primitive is already implemented.

65. Every repeated workflow should become a tool.

66. Benchmarks perfectly measure capability.

67. Runtime adapters are equally mature.

68. Physical artifacts should be fabricated without safety review.

69. VR/AR is required for all use cases.

70. Human approval alone solves safety.

71. AI replaces human responsibility.

72. The architecture can ignore compute, storage, financial, or human-review costs. ________________

73. Compact Operating Rules

74. If it matters, make it an artifact.

75. If it claims something, assign a support state.

76. If claim tracking is waived, record the waiver.

77. If the command is auto-drafted, show the intent checksum.

78. If the task is high-impact, require explicit confirmation of constraints and failure behavior.

79. If a named primitive is not implemented, label its maturity level.

80. If specialists disagree, preserve the disagreement.

81. If routing fails, log a routing residual.

82. If integration fails, log an integration residual.

83. If integration fails before execution, roll back to the last known valid checkpoint.

84. If it repeats, consider compiling it into a tool.

85. If a tool is old, revalidate it.

86. If it fails, track the residual.

87. If it is mastered, preserve it as regression.

88. If it executes, verify first.

89. If it affects shared reality, apply gates.

90. If it costs resources, account for them.

91. If it consumes human review, budget it.

92. If it produces feedback, update the system.

93. If it grows too broad, split it.

94. If it becomes stale, retire it.

95. If the runtime is immature, keep it as a contract or handoff until evidence supports execution. ________________

96. One-Paragraph Summary Verified Intent-to-Execution Architecture is a systems framework for converting human goals into verified execution. It turns vague intent into structured command contracts, stores work in an artifact graph, tracks claims and critiques, applies bounded integration checks, targets outputs to appropriate runtimes, and records feedback from use. Its first implementation should be small: an artifact store, command drafter, claim ledger, critique log, release manifest, and feedback record. The larger vision includes specialist modules, workflow-to-tool compilation, evaluation ratchets, and runtime adapters, but those should be added only after the kernel proves useful. ________________

97. Closing The next major AI architecture may not be a single larger model. It may be an execution environment around models: structured commands artifact memory claim ledgers permission envelopes bounded integration workflow compilation benchmark ratchets runtime adapters verification gates resource accounting feedback loops

That is the shift. From prompt to artifact. From response to execution. From chat history to provenance. From one-off generation to reusable tools. From static benchmarks to capability ratchets. From local outputs to integrated systems. From unpriced automation to resource-accounted execution. From output to verified action. The goal is not merely for AI to answer. The goal is for AI systems to help humans execute intent reliably. That is Verified Intent-to-Execution Architecture.

Tab 4 ________________

Verified Intent-to-Execution Architecture From prompt → artifact → verified execution Author: Corben Sorenson Public Article v1.0 — May 2026 ________________

Current Status This is a reference architecture and implementation roadmap. It is not a claim that every subsystem already exists or is solved. The next deliverable is not another expanded paper. The next deliverable is the two-week v0 kernel defined in Section 29. The first useful build is intentionally narrow: artifact store + claim ledger + critique log + release manifest + feedback record + resource log

Everything beyond that—command drafting, specialist routing, workflow-to-tool compilation, benchmark ratchets, runtime adapters, fabrication, robotics, and spatial workspaces—is expansion. ________________

How to Read This Paper Start with the Thesis, Definition, Maturity Audit, and Reduction to Practice. The middle sections define the architecture. The ending sections—Failure Modes, Claims and Non-Claims, and Compact Operating Rules—serve as the self-audit. This paper is written to name the abstractions clearly enough that a small implementation can begin immediately. ________________

Thesis AI systems are becoming very good at generating outputs. They can produce text, code, plans, summaries, diagrams, prototypes, workflows, and interface drafts. But generation is not execution. A generated response is not necessarily verified, durable, reusable, deployable, safe, or connected to feedback. The next major step is not simply making models larger. The next step is building systems that convert human intent into structured artifacts, preserve provenance, verify claims, execute through the correct runtime when appropriate, and learn from the result. I call this: Verified Intent-to-Execution Architecture or VIEA. The kernel loop is: intent → artifact → claim states → release manifest → feedback → improved artifact process

The full architecture extends that loop: intent → structured command → artifact graph → routed specialist execution → integration → runtime target → verification gate → execution or release → feedback → improved system

Specialist routing, integration, workflow compilation, and advanced runtime adapters belong to the Control and Expansion layers. They are intentionally deferred until the kernel proves useful. VIEA is not a chatbot architecture. It is an operating architecture for moving from human intent to reliable execution. ________________

1. The Problem: AI Output Is Not Execution Most AI workflows today still look like this: user prompt ↓ model response ↓ human manually interprets, verifies, stores, implements, or discards

This creates a gap. A model can generate a useful response, but the work often remains trapped in the conversation. Claims are not tracked. Assumptions are not labeled. Failures are forgotten. Benchmarks are treated as static scores instead of moving curricula. Software, fabrication, hardware, robotics, and organizational execution are handled as separate worlds. The problem is not that AI cannot generate. The problem is that generation usually lacks a reliable execution architecture around it. A serious intent-to-execution system needs to answer: * What does the user actually want? * What artifact should be produced? * What claims are being made? * What evidence supports those claims? * What constraints must not be violated? * What runtime should this target? * What must be verified before execution? * What failures remain unresolved? * What feedback came back from use? * What should change next time? VIEA is designed to answer those questions systematically. ________________

2. Definition Verified Intent-to-Execution Architecture is a systems architecture that transforms human goals into structured, verifiable, executable artifacts. The architecture has three layers: VIEA Kernel VIEA Control Layer VIEA Expansion Layer

These layers are not equally mature. The kernel is the first build. The control layer hardens the kernel. The expansion layer extends VIEA into specialists, tools, benchmarks, and runtimes. VIEA deliberately starts narrow so the first build can be completed in weeks, not months. ________________

2.1 VIEA Kernel The smallest useful system: artifact store claim ledger critique log release manifest feedback record resource log

The kernel is the part that should be built first. Its job is to prove that important AI-assisted work can be preserved, inspected, verified, released, and improved better than it can inside a chat log. ________________

2.2 VIEA Control Layer The governance and coordination layer: structured command contracts artifact retention rules provenance model permission model claim waiver policy evidence hierarchy routing policy integration checks operational metrics side-effect controls

The control layer makes the kernel safer, more scalable, and more auditable. ________________

2.3 VIEA Expansion Layer The long-term capability layer: specialist modules workflow-to-tool compiler evaluation ratchet runtime adapters spatial project workspace hardware target profiles fabrication handoff robotic control organizational workflow execution

The expansion layer should not be built until the kernel proves useful. ________________

3. Relationship to Adjacent Work VIEA is not claiming that each individual component is novel in isolation. Many ideas already exist in nearby fields. Adjacent field What VIEA borrows What VIEA adds Agent frameworks Tool use, routing, workflows, multi-step execution Durable artifact graph, explicit claim states, evidence hierarchy, integration contracts, runtime gates. Workflow systems / BPM / RPA Process modeling, task automation, repeatable workflows AI-native command contracts, claim states, residual tracking, and artifact provenance for generated work. Knowledge graphs / provenance systems Typed nodes, relationships, lineage Intent-to-execution lifecycle with claims, critiques, releases, runtime targets, and feedback. CI/CD and release systems Gates, regression, rollback, deployment discipline Applies release thinking to AI-generated artifacts, claims, tools, and multi-runtime outputs. Formal verification / testing Proofs, tests, invariants, executable checks Evidence hierarchy that prevents model consensus from being treated as verification. Data lineage / audit systems Provenance, permissions, compliance Extends lineage to AI-generated claims, decisions, workflows, and feedback. Human-in-the-loop systems Review, approval, escalation Human review budget, approval fatigue, qualified authority model. The closest existing systems are agent/workflow frameworks combined with knowledge or provenance stores. The gap is that these systems usually do not treat claims, evidence, integration, runtime maturity, and execution gates as one coherent lifecycle. The specific synthesis VIEA proposes is: structured intent

• artifact graph
• claim ledger
• evidence hierarchy
• bounded integration
• runtime maturity
• feedback

Each piece exists somewhere. The lifecycle framing is the contribution. VIEA argues that AI work should move from prompt to artifact to verification to runtime execution to feedback, rather than stopping at response generation. ________________

4. Maturity Levels for Named Primitives Architecture papers often name primitives before they are implemented. Naming is useful, but it can create the illusion that the mechanism is solved. VIEA explicitly distinguishes maturity levels. Level Meaning Example M0 — Named concept Useful term, not operationalized. “Workflow-to-tool compiler” before implementation. M1 — Schema Fields and data model defined. Claim object with support state and evidence links. M2 — Policy Rules exist for how state changes. Claim downgrade policy. M3 — Instrumented mechanism System can compute or track it. Artifact bloat rate. M4 — Validated mechanism Shown useful in real workflows. Claim ledger improving release quality. M5 — Governed infrastructure Deployed, monitored, permissioned, maintained. Runtime adapter with gates and audit logs. No named primitive should be assumed solved merely because it has a name. This maturity table is a snapshot. It should be updated when implementation evidence changes. After v0 is built and used, primitives such as Artifact Store, Claim Ledger, Release Manifest, Feedback Record, and Resource Log should move from M1/M2 toward M3 or M4 only if they are instrumented and shown useful in real work. ________________

5. Maturity Audit of VIEA Primitives This table applies the maturity ladder to VIEA itself. Primitive Maturity v1.0 snapshot Notes Artifact Store M1–M2 Schema and basic lifecycle are straightforward. First build target. Claim Ledger M1–M2 States are defined; extraction is assisted or manual at first. First build target. Critique Log M1–M2 Critique states are simple; critique quality remains model/human-dependent. First build target. Release Manifest M1 Schema can be built immediately. First build target. Feedback Record M1 Schema can be built immediately. First build target. Resource Log M1 Track confirmations, edits, storage, model calls, review events, and time estimates. First build target. v0 Interface M1 Low-friction markdown sidecar or local workbench. First build target. Command Contract M1–M2 Canonical eight-field schema and risk-based variants are defined. Quick / Working / Full Command Gradient M2 Subsets of the canonical eight-field contract. Intent Checksum M0–M1 Useful concept; policy and validation remain open. Assumption Diff M0–M1 Useful concept; extraction and validation remain open. Artifact Retention Rules M2 TTL and hash-link policies specified. High-Bandwidth Artifact Policy M1–M2 Stream manifest and chunking policy specified; implementation not yet tested. Claim Ledger Waiver M2 Conditions, limits, and waiver record specified. Evidence Hierarchy M2 Policy specified: model consensus alone cannot verify. Permission Envelope M1–M2 Fields and tiers defined; enforcement depends on implementation. Side-Effect Classifier M1–M2 Reversibility fields and side-effect classes defined. Fast Router M1 Input/output contract and budget caps defined; routing quality requires testing. Routing Residuals M1 Categories defined; automatic detection policy not yet mature. Routing Policy Review M1 Human/offline review process; not autonomous learning. Specialist Output Contract M1 Schema defined; compliance depends on module implementation. Integration Contract M1–M2 Schema and bounded check categories defined. Transactional Rollback M1–M2 Policy is clear only for reversible or pre-commit states; irreversible side effects require compensation or gates. Workflow-to-Tool Compiler M0–M1 Lifecycle defined; synthesis from trajectories remains research-heavy. Tool Confidence Decay M1 Triggers defined; decay functions need tuning. Evaluation Ratchet M1–M2 Benchmark lifecycle defined; threshold decay remains heuristic. Operational Metrics M1–M2 Numerators and denominators can be defined; instrumentation required. Digital Runtime Adapter R1–R2 Planning and sandboxed execution are realistic early targets. Hardware / Chip Runtime Adapter R0–R1 Target profile and planning adapter first. Fabrication Runtime Adapter R0–R1 Handoff package first, not autonomous fabrication. Robotic Runtime Adapter R0 Specification target only in MVP. Organizational Runtime Adapter R1 Planning and reviewed workflow generation first. Spatial Workspace Runtime R0–R1 Interface concept; not needed for kernel. This table is deliberately conservative. The VIEA Kernel can be built while many advanced primitives remain at M0 or M1. ________________

6. Where the Model Fits VIEA is architecture around models, not a replacement for models. The model participates in several roles. Role Function Command drafter Converts raw intent into structured command candidates. Extractor Proposes claims, requirements, critiques, residuals, and artifacts. Synthesizer Produces candidate outputs from structured context. Specialist engine Powers writing, research, code, design, critique, or planning modules. Router assistant Helps classify tasks and select specialists. Verifier assistant Proposes checks, but cannot verify by model agreement alone. VIEA does not assume the model is reliable by default. The model proposes. The architecture records. The ledger classifies. The router scopes. The integration layer checks. The runtime gate verifies. Feedback corrects. ________________

6.1 Model Capability Assumptions VIEA requires only modest model capability for the kernel: * draft a command contract from natural language; * extract candidate claims; * produce structured outputs; * summarize artifacts; * suggest critiques; * assist with release manifests. The kernel does not require the model to: * perfectly understand user intent; * perfectly verify claims; * autonomously synthesize safe tools; * coordinate complex multi-agent execution; * fabricate physical objects; * control robots; * solve all routing problems. When model capability is uncertain, VIEA should: lower claim state ask for confirmation route to human review run external checks create residual avoid execution

A VIEA system should never hide model uncertainty behind architectural ceremony. ________________

7. Structured Command Layer The canonical command contract has eight fields. Field Meaning Role What kind of expertise is being invoked. Objective What outcome matters most. Context What is already true. Constraints What must not be violated. Procedure How the system should proceed. Output Contract What shape the result must take. Verification How correctness will be checked. Failure Behavior What to do if context is missing, unsafe, or contradictory. The command gradient is made of subsets of the canonical eight. Command level Fields Raw Intent User provides natural language; system drafts a contract. Quick Command Role, Objective, Context, Verification. Working Command Role, Objective, Context, Constraints, Output Contract, Verification. Full Command All eight fields. The eight-field contract is canonical. Quick and working commands are lighter projections of it. The purpose is not bureaucracy. The purpose is to partially compile intent before execution. ________________

8. Automation Bias Control Auto-drafted command contracts create a risk: users may approve a plausible but wrong contract. If the system misinterprets intent and the user rubber-stamps it, the system can execute perfectly against the wrong objective. VIEA therefore needs automation bias controls. 8.1 Intent Checksum For any medium- or high-impact task, the system should produce a short plain-language summary of what it believes the user wants. Example: Intent checksum: You want this draft revised into a public v1.0 architecture article. The priority is defensibility and clarity, not maximum novelty. The system should preserve speculative ideas but label them clearly.

The user does not need to inspect every field. They need to confirm the core intent. ________________

8.2 Assumption Diff The system should list material assumptions it inferred. Assumptions inferred: - Target audience: technical AI / systems readers. - Output: public article, not implementation spec. - Tone: systems engineering, not marketing. - Evidence standard: conceptual but non-overclaiming.

---

8.3 Risk-Based Confirmation Risk level Confirmation requirement Low Proceed automatically after showing summary. Medium User confirms objective and output contract. High User confirms objective, constraints, verification, and failure behavior. Critical Explicit approval from qualified authority required. Rule: The system may infer structure, but it must not silently infer authority. ________________

9. v0 Interface Requirement The v0 must not feel like a project-management system. If the user has to interrupt flow state to tag 20 claims manually in a heavy interface, the kernel will fail before it proves its value. The v0 interface should be sidecar-first. Acceptable v0 interfaces: markdown sidecar local CLI editor / IDE panel simple local web view CSV / JSONL claim ledger beside the draft

Unacceptable v0 interfaces: heavy ticketing system multi-screen enterprise workflow form-first capture mandatory graph visualization complex dashboard before daily use

The v0 should let the user write normally, then expose claim/artifact controls beside the work. Example local folder: viea_project/ draft.md artifacts.jsonl claims.jsonl critiques.jsonl release_manifest.json feedback.jsonl resources.jsonl

The interface principle: The artifact system should wrap the writing/building workflow, not interrupt it. ________________

10. Artifact Graph Chat history is weak memory. Artifacts are strong memory. A full VIEA system may eventually support many artifact types: Intent Command Claim Source Critique Requirement Decision Design Diagram CodeModule CADObject Simulation Tool Workflow Benchmark Residual CompileTarget RuntimeAdapter Release Feedback Primitive World

But the v0 schema should be much smaller. ________________

10.1 v0 Record Schema The two-week v0 only needs six record types: Artifact Claim Critique ReleaseManifest Feedback ResourceEvent

And three relationship types: supports contradicts derives_from

This is enough to begin using the system on real writing and design work. The v0 folder from Section 9 maps directly onto these records: File Record type artifacts.jsonl Artifact claims.jsonl Claim critiques.jsonl Critique release_manifest.json ReleaseManifest feedback.jsonl Feedback resources.jsonl ResourceEvent ResourceEvent is a resource-accounting record, not a truth-bearing artifact. ________________

10.2 Target Artifact Schema As the system matures, artifacts should have: id type title content owner version created_at updated_at provenance links permissions verification_state release_state retention_class activity_state hash_links

A hash-link is a content-addressed link to another artifact or artifact chunk. It records a stable content hash of the target, so the system can detect whether referenced content changed after linkage. In v0, a simple stable file hash is enough. Target relationships may include: Relationship Meaning supports Evidence supports a claim. contradicts Evidence or critique challenges a claim. implements Artifact implements a requirement. validates Test or benchmark validates artifact. depends_on Artifact depends on another artifact. derives_from Artifact came from another artifact. supersedes Artifact replaces earlier artifact. blocks Artifact blocks release or execution. compiled_to Artifact compiled to a runtime target. produced_feedback Execution produced feedback. generalizes_to Pattern became a primitive or tool. The target schema is a roadmap. The v0 schema is the first build. ________________

11. Artifact Retention and Relevance Control A typed artifact graph is better than chat history, but it creates a new problem: If everything becomes an artifact, the graph can become too large to use. VIEA needs concrete retention and relevance policies. ________________

11.1 Artifact Classes Artifact class Examples Default behavior Core Commands, claims, decisions, requirements, releases, tools, feedback Preserve indefinitely unless explicitly retired. Support Drafts, intermediate analyses, source summaries, design alternatives Preserve, summarize after inactivity, keep provenance. Transient Scratch work, temporary decompositions, abandoned alternatives Expire or compress after a short TTL unless linked. Stream Video, telemetry, audio, logs, sensor traces Stored as chunked cold data with manifest artifacts. Archived Old versions, stale branches, inactive project artifacts Searchable but excluded from default context. Deprecated Superseded artifacts and rejected claims Retained for provenance but hidden from normal routing. ________________

11.2 Example Retention Rules Transient artifacts: summarize after 48 hours if not hash-linked to a core or support artifact archive after 7 days if inactive and unlinked delete only if no provenance obligation exists

Support artifacts: summarize after 30 days of inactivity archive after 90 days if not referenced preserve source links and decision impact

Core artifacts: never auto-delete may be superseded, deprecated, or archived remain available for audit

Residual artifacts: keep active while recurring archive only after resolution or explicit waiver

Stream artifacts: store raw stream data outside the active artifact graph represent streams with lightweight manifest artifacts chunk by time, event, or run retain anomaly windows, failure windows, and benchmark-linked segments archive or downsample non-event segments according to domain policy

---

11.3 Hash-Link Rule A transient artifact should survive only if it becomes relevant. Rule: If a transient artifact is not hash-linked to a core artifact, support artifact, residual, decision, tool, or release within 48 hours, it should be summarized and marked for pruning. This prevents scratch output from polluting long-term retrieval. ________________

11.4 High-Bandwidth Artifact Policy High-bandwidth continuous data should not be treated as ordinary transient text. A 20-minute drone camera feed, raw robot telemetry stream, or multi-sensor field test should not become one giant artifact in the active graph. Instead: raw stream → cold storage object → stream manifest artifact → chunk index → event links → residual / benchmark / test links

A stream manifest should record: stream_id source device time range runtime context storage location chunk hashes event markers linked benchmark or field test linked residuals retention policy privacy/safety flags

Rule: The graph stores the manifest and links. The cold store holds the bytes. The 48-hour transient rule applies to the manifest if unlinked, not blindly to raw safety-relevant data. Domain policy determines raw-data retention, especially for physical tests, safety incidents, and regulated environments. ________________

12. Claim and Verification Ledger AI systems often mix facts, assumptions, predictions, speculation, and confident guesses. Every important claim should have a support state. State Meaning Verified Proven or directly validated by deterministic check, formal proof, reproducible test, or authoritative record. Empirically supported Supported by experiment, benchmark, or measured result. Source-backed Supported by cited external material. Reasoned inference Plausible but not directly proven. Speculative Hypothesis or conceptual possibility. Unsupported No current support. Contradicted Evidence argues against it. Requires experiment Needs empirical test. Requires expert review Needs domain-specific review. Deprecated No longer active. Waived Claim tracking intentionally waived for a low-risk context. The rule is: Speculation is allowed. Unlabeled speculation is not. ________________

13. Claim Ledger Waivers Not every low-risk artifact needs heavy claim tracking. A quick internal email, brainstorming note, or low-impact draft should not pay the full verification cost of a public release. Claim tracking may be waived when:

• the output is low-risk;
• the artifact is not public;
• the artifact does not instruct execution;
• the artifact does not make safety, legal, medical, financial, or empirical claims;
• the artifact is not used as evidence for another artifact;
• the user or policy allows lightweight treatment. A waiver is itself an artifact. artifact_id waiver_reason risk_tier scope expiration approver_or_policy

Rule: A waiver reduces local overhead; it does not create evidence. If a waived artifact later becomes part of a release, deployment, fabrication packet, or benchmark claim, its claims must be re-extracted and assigned support states. ________________

14. Evidence Hierarchy A claim ledger is only useful if verification is not just another model agreeing with itself. If the same underlying model powers the generator, researcher, skeptic, and verifier, the system can reach internal consensus on false claims. VIEA therefore requires an evidence hierarchy. Evidence level Examples Maximum claim state Internal model agreement Multiple specialists agree without external evidence Reasoned inference at most. Source citation External document, dataset, repository, standard, publication Source-backed. Executable check Test, benchmark, simulation, proof, static analysis, reproducible run Verified or empirically supported depending on check. Independent system check Different model family, independent tool, external validator Raises confidence but still needs evidence. Expert or authority review Qualified human or governing body Reviewed / approved, with scope. Field feedback Deployment, fabrication, user telemetry, real-world result Empirically supported or contradicted. Critical rule: Model consensus alone cannot mark a claim as verified. It can mark a claim as plausible, inferred, or recommended for testing. Verification is not a stamp forever. It is a maintained state. ________________

15. Provenance and Permission Model Every artifact should know: who created it who modified it what generated it what it depends on what evidence supports it what permissions govern it what runtime it may target what release boundary it may cross

Every tool, specialist, and runtime adapter should operate under a permission envelope: memory access tool access runtime access side-effect allowance budget risk tier approval requirements audit requirements

The system should default to least privilege. ________________

16. Approval Authority and Human Bottleneck Control “Human approval” is not enough as a safety model. The system needs to know who is approving, whether they are qualified, what authority they have, what risk tier they may approve, and whether approval fatigue is likely. ________________

16.1 Approval Roles Role Can approve Owner Low/medium project decisions. Domain reviewer Domain-specific technical claims. Safety reviewer Safety gates, risk classifications, refusals. Release approver Public release boundaries. Fabrication approver Physical production handoffs. Deployment approver Production digital deployment. Critical authority High-risk or irreversible actions. ________________

16.2 Human Review as a Resource Human review capacity is a first-class resource. In v0, human review should not require abstract time tracking if that adds friction. Use operational proxies first: number of claim-state confirmations number of claim-state edits number of critique decisions number of release checklist confirmations number of approval prompts number of rejected or corrected model suggestions optional wall-clock review time

A project should later track: available reviewers reviewer qualifications review queue length approval latency approval fatigue index review budget critical approval coverage

Rule: Human approval must be qualified, scoped, rate-limited, and budgeted. Otherwise it becomes theater. ________________

17. Fast Router and Routing Policy Review The production-minded version of VIEA does not assume a powerful autonomous routing mind. It uses: Fast Router = runtime routing policy execution Routing Policy Review = periodic human/offline review of routing residuals

---

17.1 Fast Router The Fast Router is the low-latency policy layer. It handles: * initial specialist selection; * permission envelope assignment; * context packaging; * risk-tier routing; * default tool selection; * simple fallback decisions; * token budget enforcement; * compute budget enforcement; * latency budget enforcement. It should be deterministic or policy-constrained wherever possible. ________________

17.2 Fast Router Budget Caps A routing decision should include: max specialist calls max tokens / context budget max compute budget max latency max financial cost max human review requests risk tier fallback behavior

If the request exceeds budget, the system should reduce scope, choose cheaper specialists, run a quick path, ask for budget approval, defer expensive verification, or refuse nonessential execution. ________________

17.3 Routing Policy Review Routing policy should improve through periodic review, not by assuming an autonomous meta-agent can solve routing. Inputs: routing residuals specialist performance metrics integration failures cost reports user corrections approval delays runtime failures feedback records

Outputs: updated routing rules specialist scope changes new routing tests permission policy updates budget policy updates recommendations for split/merge/retire

This can initially be human-led. The architecture does not require autonomous routing-policy learning. ________________

18. Routing Residuals Routing failures are first-class residuals. Routing residual Meaning Wrong specialist selected The chosen module lacked needed expertise. Missing specialist No available module fit the task. Context under-allocation Specialist lacked needed information. Context over-allocation Specialist received irrelevant or unsafe information. Conflict unresolved Specialist outputs disagreed without resolution. Verifier skipped Output needed review but was not routed to verifier. Over-routing Too many specialists were called. Under-routing Too few specialists were called. Permission mismatch Specialist lacked or exceeded necessary authority. Routing residuals should feed Routing Policy Review. ________________

19. Specialist Modules Specialist modules are bounded subsystems with defined scopes. Module Scope Writing Module Structure, clarity, tone, final polish. Research Module Sources, related work, evidence gathering. Claim Audit Module Extract and classify claims. Skeptic Module Challenge assumptions and identify weaknesses. Code Module Generate, review, patch, and test software. CAD Module Create or revise geometry and assemblies. Simulation Module Run or specify tests and simulations. Fabrication Module Plan manufacturability and production handoff. Hardware Target Module Adapt software to chip or embedded constraints. Benchmark Module Design evaluations and track capability. Safety Module Identify risk, enforce gates, veto unsafe actions. Deployment Module Release planning, rollout, monitoring, rollback. Memory Module Retrieve relevant artifacts, history, and context. Each specialist should have: name scope input_schema output_schema allowed_tools memory_scope permission_level benchmarks residuals runtime_tier lifecycle_status cost_profile

Specialists should be created, evaluated, benchmarked, updated, split if they become too broad, merged if redundant, and retired if stale. ________________

20. Specialist Output Contracts Specialists should not return unstructured text by default. They should return structured outputs. A specialist output should include: result confidence assumptions evidence compatibility_requirements risks residuals recommended_next_steps required_verification provenance cost side_effect_class is_reversible compensation_plan

If two specialists disagree, the system should preserve the disagreement, route to verification, or expose the uncertainty. It should not flatten disagreement into false consensus. For any output that can mutate external state, side_effect_class is mandatory. ________________

21. Integration Layer Bounded specialists reduce monolithic chaos, but they introduce a new failure mode: Specialists can produce locally valid outputs that are globally incompatible. This is contextual shattering. Example:

• Code Module produces valid memory logic.
• Hardware Target Module produces valid hardware constraints.
• Each is correct locally.
• The integrated system fails because the memory logic violates the hardware constraints. VIEA therefore needs an Integration Layer. ________________

21.1 Integration Is Bounded A whole-system pass is not magic. Integration checks fall into three categories. Check type Examples Strength Directly checkable Schemas, interfaces, permissions, resource budgets, runtime targets, dependency versions Strong. Testable with effort Build tests, integration tests, simulations, canaries, hardware-in-loop plans Medium to strong depending on coverage. Not fully checkable before execution Conceptual fit, long-term effects, human usefulness, real-world robustness Must remain assumptions or residuals. The Integration Layer should not pretend to prove what it cannot prove. It should classify checks by strength. ________________

21.2 Integration Contract Every multi-specialist task should define an integration contract: global objective shared constraints required interfaces runtime target resource budget critical invariants integration tests failure boundaries rollback behavior side_effect_policy

---

21.3 Side-Effect Classes Rollback is only simple before side effects occur. Every specialist output and integrated candidate should declare a side-effect class. Side-effect class Meaning Rollback behavior Pure No external state change. Fully reversible. Local reversible Local file or artifact change. Roll back to checkpoint. External reversible External change with known undo path. Execute compensation plan. External compensatable Cannot undo exactly, but can compensate. Execute mitigation or compensation. Irreversible Cannot undo or compensate reliably. Requires strict gate before execution. Safety-critical Physical, financial, legal, security, or human-impacting side effect. Requires qualified approval or refusal. This prevents the paper from pretending that all rollback is like reverting a Git commit. ________________

21.4 Transactional Integration and Rollback For high-impact tasks, a set of specialist outputs should be treated as a transaction until side effects begin. If global integration fails before side effects occur, the system should: 1. reject the integrated candidate; 2. preserve the failed integration bundle as an artifact; 3. roll back to the last known valid checkpoint; 4. log an integration residual; 5. route the residual to review or relevant specialists; 6. require a revised integration candidate before execution.

If side effects have already occurred, rollback may be impossible. The system must then use the declared compensation plan, mitigation path, or incident process. Rule: Rollback applies cleanly only to reversible states. Irreversible side effects require gates before execution, not rollback after failure. ________________

22. Workflow-to-Tool Compiler This subsystem is important, but it is not part of the VIEA Kernel. It remains an expansion-layer capability. If the system repeats the same workflow many times, it should eventually consider compiling that workflow into a reusable tool. The lifecycle is: trajectory logs → loop candidate → tool candidate → shadow mode → assisted tool → active tool → monitored tool → revised or retired tool

A workflow should not become a tool merely because it repeats. Example threshold: At least 5 successful similar trajectories AND at least 2 distinct contexts AND verification pass rate ≥ 90% AND no unresolved critical failures

The system should not jump from detected pattern to automatic execution. ________________

23. Tool Rot and Revalidation Tools decay. APIs change. Dependencies break. Physical sensors drift. Environments shift. User preferences change. Lighting changes. Hardware degrades. Critical rule: No tool remains trusted solely because it passed once. Revalidation should trigger when:

• dependency changes;
• runtime target changes;
• environment differs from known context;
• failure rate rises;
• residuals recur;
• verification suite changes;
• tool has not run recently;
• tool crosses into a higher risk tier. ________________

24. Evaluation Ratchet A VIEA system needs a way to improve over time. Benchmarks should function as curriculum. Status Meaning Frontier Exposes missing capability. Diagnostic Isolates a failure mode. Graduated Mastered enough to move forward. Regression Preserves prior capability. Public calibration Enables apples-to-apples comparison. Live Updated over time. Retired No longer useful. The system should not require 100% on every ordinary benchmark before moving on. For ordinary non-safety benchmarks, a starting mastery threshold might be 90%. If progress stalls, the threshold can decay toward a floor such as 70%. Critical failures still block graduation. This threshold policy is heuristic and should be treated as M1–M2 until validated. The rule: Advance at mastery. Preserve the tail. Promote recurring residuals. ________________

25. Runtime Adapter Scope Runtime adapters are not equally mature. They should not be treated as equally solved. Level Meaning R0 — Contract only Output contract defined, no execution. R1 — Planning adapter Produces plans, specs, or checklists. R2 — Sandboxed execution Executes in controlled digital environment. R3 — Verified execution Executes with tests, gates, and rollback. R4 — External handoff Produces packages for external fabrication, deployment, or review. R5 — Closed-loop runtime Executes, monitors, and feeds results back automatically. The MVP should mostly target R0–R2. Physical, robotic, and organizational runtimes should begin as planning or handoff adapters, not autonomous execution systems. ________________

26. Runtime Adapters Different runtimes require different artifacts and verification. ________________

26.1 Digital Runtime Produces: documents specs code apps agents APIs dashboards datasets workflows deployment bundles

This is the first runtime VIEA should implement. ________________

26.2 Hardware / Chip Runtime Produces: firmware embedded builds GPU kernels FPGA bitstreams target-specific binaries hardware-in-loop test plans

In the early system, this should be a profile and planning adapter, not necessarily an automatic compiler. ________________

26.3 Fabrication Runtime Produces: requirements CAD or schematic artifact list simulation plan DFM / DFA checks bill of materials fabrication packet inspection plan assembly plan field-test plan

In the MVP, fabrication should remain a handoff package, not autonomous fabrication. ________________

26.4 Robotic Runtime Produces: controller motion plan sensor loop reflex/failsafe behavior telemetry plan

Robotic runtime is out of scope for the MVP except as a specification target. ________________

26.5 Organizational Runtime Produces: standard operating procedures team workflows policies contracts business plans training programs release processes governance systems

In early VIEA, organizational runtime should produce reviewed plans, not automatically impose policies. ________________

26.6 Spatial Project Workspace Runtime Produces: project worlds visual artifact graphs collaborative workspaces simulation arenas world templates forkable project spaces

This is not required for the MVP. Every spatial object must map to a real artifact or state. Otherwise it is only visual decoration. ________________

27. Latency and Compute Control VIEA is heavier than a chat response. That overhead is justified for high-impact execution but not for every small task. The system therefore needs execution tiers. Tier Use case VIEA overhead T0: Ephemeral Brainstorm, scratch note, low-risk drafting Minimal artifacting, optional claim tracking. T1: Draft Reusable text, internal analysis, low-risk code sketch Lightweight artifacts, basic provenance. T2: Work Product Specs, papers, code modules, workflows Full artifacts, claim ledger, critique, specialist routing. T3: Release Public output, shared tools, production-bound code Release gate, verification, provenance, residual tracking. T4: Execution Deployment, fabrication, robotics, finance, security Full command, runtime gates, approval, monitoring. T5: Critical Irreversible or safety-critical action Strict gate, certified process, refusal when appropriate. Rule: Use the cheapest process that is safe for the consequence level. ________________

28. Resource and Economic Model VIEA needs explicit resource accounting. Every project should have a resource envelope: compute budget storage budget specialist invocation budget runtime execution budget human review budget latency budget fabrication budget maintenance budget

Human review budget is one of the most important scarce resources in the system. The system should not pretend computation, storage, human attention, and fabrication are free. ________________

29. Reduction to Practice The most important practical question is: What should be built first? The answer is the VIEA Kernel. ________________

29.1 Two-Week v0 The smallest useful build is: artifact store claim ledger critique log release manifest feedback record resource log

No command drafter is required for v0. No specialist router is required for v0. No workflow-to-tool compiler is required for v0. No runtime adapters are required for v0. The two-week v0 should support one workflow: take a draft → create artifact record → extract or manually enter material claims → assign support states → record critiques → create release manifest → record feedback plan → record resource events

This should be usable by the author on the next paper. ________________

29.2 v0 UX The v0 uses the sidecar-first interface defined in Section 9. It should look like a working folder beside the draft, not like a ticketing system. Minimum sidecar: draft.md artifacts.jsonl claims.jsonl critiques.jsonl release_manifest.json feedback.jsonl resources.jsonl

---

29.3 One-Month v0.5 After v0 proves useful, add only the two most valuable AI-dependent features: auto-drafted command contracts candidate claim extraction

The v0.5 should not add routing, tool compilation, runtime adapters, or spatial workspaces. Its purpose is to test whether model-assisted structure improves the artifact and claim workflow. ________________

29.4 Three-Month v1 Kernel After v0.5 proves useful, add: assumption diff intent checksum critique suggestions artifact retention policy manual handoff to human or model reviewers for specific claim states

This becomes the VIEA Kernel. The timeline is intentionally conservative. Each added feature increases model-dependence risk and should be tested separately. ________________

29.5 Kernel Success Condition The kernel succeeds if it can take a serious idea or draft and produce: structured artifact record claim ledger critique log revised artifact release manifest feedback plan resource log

better than a normal chat workflow. That is the first proof. ________________

30. Operational Metrics A metric is only useful if the system can compute it. Metric Numerator Denominator Command correction rate Auto-drafted fields changed by user Auto-drafted fields shown to user Claim support ratio Claims with verified, empirical, source-backed, or accepted inference state Material claims in artifact Critique resolution rate Critiques resolved, accepted, or waived Open critiques created Artifact bloat rate Active artifacts unlinked to core/support artifacts after TTL Total active artifacts Routing residual rate Routing residuals logged Routed tasks Integration failure rate Integrated bundles rejected Integration attempts Rollback rate Bundles rolled back High-impact integration attempts Tool drift rate Tool failures caused by environment/dependency drift Tool executions Human review prompt count Explicit confirmations, edits, approvals, or critique decisions requested Work session or release candidate Human review budget usage Review events or minutes consumed Review events or minutes budgeted Runtime pass rate Runtime executions passing verification Runtime executions attempted Stream retention rate Stream chunks retained due to event/residual/benchmark linkage Stream chunks generated These metrics should feed improvement decisions. ________________

31. Safety and Permission Model The system must distinguish between exploration and execution. Inside a private workspace, users can explore freely. At the boundary to shared reality, gates apply. Stage Safety posture Exploration Free ideation and reversible manipulation. Simulation Mostly free, logged. Digital compile Verification required. Hardware compile Target constraints and regression required. Fabrication Safety, manufacturability, and inspection required. Deployment Approval, rollback, and monitoring required. High-risk action Strict gate, refusal, or certified process. Core rule: Nothing leaves a project workspace into shared reality without the correct gate. ________________

32. Threat Model VIEA systems will be attacked because they connect intent to execution. Threat Description Controls Prompt injection Malicious content tries to alter commands or tools. Command isolation, source labeling, permission envelopes. Artifact poisoning Bad artifacts inserted into graph to influence future work. Provenance, trust scores, review gates. Verifier capture Same model family verifies its own false outputs. Evidence hierarchy, external checks, model diversity. Permission escalation Tool or specialist gains more authority than intended. Least privilege, permission envelopes, audit logs. Tool rot Old verified tool fails under changed environment. Revalidation, confidence decay, monitoring. Routing sabotage Bad routing sends tasks to wrong specialists. Routing residuals, policy review. Approval fatigue Humans approve too many requests and stop reviewing. Risk-based batching, qualified approval, fatigue metrics. Graph exfiltration Sensitive project artifacts are exposed. Access control, private-by-default workspaces, audit logs. Stream loss High-bandwidth telemetry is pruned before failure analysis. Stream manifests, event chunking, cold storage policy. Untracked side effects Output mutates external state without side-effect class. Mandatory side_effect_class before execution. Fabrication misuse Unsafe physical designs are produced. Fabrication runtime gates, compliance review, refusal policies. Benchmark gaming System optimizes metric while losing real utility. Live benchmarks, residual tracking, public calibration. A VIEA system should be designed as infrastructure, not a toy assistant. ________________

33. Failure Modes 33.1 Output without artifact The system generates a response but does not store durable structure. Mitigation: Require artifacts for important outputs. ________________

33.2 Unsupported claims The system produces confident but unsupported claims. Mitigation: Use claim ledger, support states, and evidence hierarchy. ________________

33.3 Vocabulary outpaces mechanism The paper or implementation names a primitive before making it operational. Mitigation: Assign maturity levels to primitives. Distinguish concepts, schemas, policies, metrics, and implemented mechanisms. ________________

33.4 Automation bias Users rubber-stamp incorrect auto-drafted commands. Mitigation: Use intent checksum, assumption diff, risk-based confirmation, and misalignment probes. ________________

33.5 User friction The command layer becomes too heavy and users avoid it. Mitigation: Use sidecar-first v0 UX and tiered command structure. ________________

33.6 Artifact graph bloat The graph becomes too large, noisy, or expensive to traverse. Mitigation: Use retention classes, TTLs, hash-link rules, active context selection, summarization, archival states, and relevance scoring. ________________

33.7 High-bandwidth data loss Sensor streams, video, telemetry, or logs are pruned before they can support failure analysis. Mitigation: Store stream manifests in the graph, chunk raw data into cold storage, retain anomaly windows and benchmark-linked segments. ________________

33.8 Epistemic collapse Specialists internally agree on false claims. Mitigation: Model consensus alone cannot verify. Require external evidence, tests, independent tools, expert review, or field feedback. ________________

33.9 Model capability mismatch The architecture assumes a model can perform tasks it cannot reliably perform. Mitigation: Treat model outputs as proposals. Lower claim states, require confirmation, and use human-assisted extraction where needed. ________________

33.10 Contextual shattering Local specialist outputs fail when combined. Mitigation: Use Integration Layer, bounded checks, global invariants, compatibility tests, and transactional rollback. ________________

33.11 Rollback overclaim The system assumes every failed integration can be rolled back. Mitigation: Require side-effect classes, reversibility flags, and compensation plans. Gate irreversible side effects before execution. ________________

33.12 Untracked side effects A specialist or tool mutates external state without declaring a side-effect class. Mitigation: Require side_effect_class, is_reversible, and compensation_plan for any output that can affect external state. ________________

33.13 Runtime abstraction overreach The paper treats all runtimes as equally mature or equally solvable. Mitigation: Use runtime maturity levels. Start with digital and planning adapters before physical or robotic execution. ________________

33.14 Tool bloat Too many tools accumulate without value. Mitigation: Use observed recurrence thresholds, shadow mode, tool ROI, merge, and retirement lifecycle. ________________

33.15 Tool rot Old tools fail under changed conditions. Mitigation: Use revalidation schedules, confidence decay, drift detection, canaries, and runtime monitoring. ________________

33.16 Benchmark gaming The system optimizes scores without improving useful capability. Mitigation: Use live benchmarks, private holdouts, residual tracking, and public calibration distinction. ________________

33.17 Approval fatigue Human reviewers become bottlenecks or rubber-stamp decisions. Mitigation: Use qualified approval roles, batching, fatigue metrics, and risk-tier gates. ________________

33.18 Unsafe execution The system executes beyond safe bounds. Mitigation: Use runtime gates, permission envelopes, human approval, and refusal policies. ________________

33.19 Cost explosion The system spends too much compute, storage, human review, or runtime budget. Mitigation: Use resource envelopes, cost tracking, budget gates, and tool ROI. ________________

33.20 Architecture overreach The system attempts the full vision before proving the core loop. Mitigation: Build the VIEA Kernel first. ________________

34. Claims and Non-Claims 34.1 Claims This paper claims:
35. AI systems need structured intent, not only prompts.
36. Durable artifact graphs are stronger than chat history for long-running work.
37. Claims should have explicit support states.
38. Model consensus alone should not count as verification.
39. Low-risk claim tracking can be waived, but waivers do not create evidence.
40. VIEA primitives should be labeled by maturity level.
41. The first implementation should build the kernel, not the full architecture.
42. The v0 kernel needs a low-friction sidecar interface, not a heavy workflow UI.
43. The v0 schema includes critique and resource records because they are needed by the sidecar workflow.
44. High-bandwidth data needs stream manifests and cold storage, not ordinary transient-artifact treatment.
45. Human review budget can start with operational proxies such as confirmation counts and claim-state edits.
46. Integration must be treated as a first-class problem, not assumed after decomposition.
47. Integration checks are bounded and vary in strength.
48. Rollback is only reliable for reversible states; irreversible side effects require gates before execution.
49. Untracked side effects are a distinct failure mode and require mandatory side-effect classification.
50. Repeated workflows should become verified tools only when valuable and safe.
51. Tools require revalidation because environments drift.
52. Benchmarks should be treated as moving curriculum.
53. Residual failures should be tracked rather than forgotten.
54. Runtime targeting is necessary for real execution.
55. Runtime adapters should have maturity levels rather than being treated as equally solved.
56. Fabrication requires simulation, manufacturability checks, inspection, and approval.
57. Resource accounting is necessary for practical deployment.
58. Human review budget must be treated as a first-class resource.
59. The next meaningful deliverable after this paper is implementation evidence, not another expanded architecture draft. ________________

34.2 Non-Claims This paper does not claim: 1. The full system already exists. 2. AI should execute all user intent automatically. 3. Verification is absolute. 4. Structured commands eliminate ambiguity completely. 5. Users will carefully review every auto-drafted command. 6. Specialist modules always outperform monolithic systems. 7. Routing is easy. 8. Autonomous routing-policy learning is solved. 9. Integration after decomposition is automatic. 10. Every named primitive is already implemented. 11. Every repeated workflow should become a tool. 12. Benchmarks perfectly measure capability. 13. Runtime adapters are equally mature. 14. Physical artifacts should be fabricated without safety review. 15. VR/AR is required for all use cases. 16. Human approval alone solves safety. 17. Rollback can undo every side effect. 18. High-bandwidth sensor data can be handled like ordinary text artifacts. 19. AI replaces human responsibility. 20. The architecture can ignore compute, storage, financial, or human-review costs. ________________

35. Compact Operating Rules

36. If it matters, make it an artifact.

37. If it claims something, assign a support state.

38. If claim tracking is waived, record the waiver.

39. If the command is auto-drafted, show the intent checksum.

40. If the task is high-impact, require explicit confirmation of constraints and failure behavior.

41. If the v0 interface feels like a ticketing system, simplify it.

42. If a named primitive is not implemented, label its maturity level.

43. If specialists disagree, preserve the disagreement.

44. If routing fails, log a routing residual.

45. If integration fails, log an integration residual.

46. If integration fails before execution, roll back to the last known valid checkpoint.

47. If side effects are irreversible, gate them before execution.

48. If side effects are possible, require a side-effect class.

49. If high-bandwidth data is produced, store a manifest and preserve relevant chunks.

50. If it repeats, consider compiling it into a tool.

51. If a tool is old, revalidate it.

52. If it fails, track the residual.

53. If it is mastered, preserve it as regression.

54. If it executes, verify first.

55. If it affects shared reality, apply gates.

56. If it costs resources, account for them.

57. If it consumes human review, budget it.

58. If it produces feedback, update the system.

59. If it grows too broad, split it.

60. If it becomes stale, retire it.

61. If the runtime is immature, keep it as a contract or handoff until evidence supports execution. ________________

62. One-Paragraph Summary Verified Intent-to-Execution Architecture is a systems framework for converting human goals into verified execution. Its kernel turns intent into artifacts, tracks claims, records critiques, produces release manifests, preserves feedback, and accounts for resource use. Its control layer adds command contracts, provenance, permissions, retention, evidence hierarchy, routing policy, bounded integration checks, high-bandwidth stream manifests, and side-effect controls. Its expansion layer adds specialists, workflow-to-tool compilation, evaluation ratchets, and runtime adapters. The first build should be small: an artifact store, claim ledger, critique log, release manifest, feedback record, and resource log with a low-friction sidecar interface that can be used on real work. ________________

63. Closing The next major AI architecture may not be a single larger model. It may be an execution environment around models: structured commands artifact memory claim ledgers permission envelopes bounded integration workflow compilation benchmark ratchets runtime adapters verification gates resource accounting feedback loops

That is the shift. From prompt to artifact. From response to execution. From chat history to provenance. From one-off generation to reusable tools. From static benchmarks to capability ratchets. From local outputs to integrated systems. From unpriced automation to resource-accounted execution. From output to verified action. The goal is not merely for AI to answer. The goal is for AI systems to help humans execute intent reliably. That is Verified Intent-to-Execution Architecture.