The Autonomaton Pattern: Toward Self-Authoring Software Systems

Q: What does "three files and a loop" actually mean?

A routing configuration (zone boundaries and tier preferences), a zones schema (operation classifications), and a structured telemetry log (interaction history) — these are the three files. The five-stage pipeline (Telemetry, Recognition, Compilation, Approval, Execution) traverses them every cycle. That is the entire architecture. Everything else — auditability, composability, portability, the Skill Flywheel — is implication of this constraint.

Q: How is this different from existing agent frameworks?

Agent frameworks orchestrate model calls; the Autonomaton governs them. The pipeline is invariant — nothing runs alongside it, no sub-pipelines, no bypasses. The Zone Model is the consent boundary: Green is autonomous, Yellow is supervised, Red is human-only. The Skill Flywheel ratchets confirmed patterns toward cheaper execution tiers over time. No existing agent framework specifies all three as structural invariants.

Q: What does it mean to own memorialized judgment?

The behavioral intelligence the system accumulates — your patterns, your preferences, your decision-making cadence — lives at the operator endpoint, not in vendor infrastructure. Telemetry is structured and inspectable. Configuration is YAML a non-technical operator can read. Confirmed skills are exportable and portable. Delete a skill and the behavior stops. This is what sovereign computing means in practice.

Q: Is this compatible with enterprise compliance?

Auditability is a byproduct of the pipeline. Every action traces back to a telemetry entry, a classification decision, a skill specification, a zone boundary, and an approval record. The Red Zone is enforced structurally — a self-scope-expanding write is impossible on the autonomous loop, not merely blocked. Compliance teams audit the configuration instead of interrogating the system at runtime. Governance becomes inspectable by design.

Q: Can the operator change what the agent is allowed to do?

Yes — and only the operator can. In 2.0 the zone model keys on operator scope: a write that would expand the agent's own authority is impossible on the autonomous loop, not merely refused. To change what the agent may do, the operator issues an authenticated grant — one the agent can request but can never issue to itself — naming a specific scope region and write class. The agent then executes that one scope change inline, as the operator's hands, provenance-stamped to the grant. Progressive personalization without self-promotion: the operator widens the boundary once, the grant is sticky and auditable, and the agent never crosses it on its own.

Jim Calhoun

Open Standard · GRV-001 · CC BY 4.0

The Autonomaton Pattern

Toward Self-Authoring Software Systems

The Autonomaton pronounced auto-NAHM-uh-tawn · /ɔːˈtɒnəmətɒn/ is a self-authoring engine: it converts metered cloud dependencies into permanent, zero-marginal-cost institutional assets that get smarter, cheaper, and more private with every human interaction.

Three files and a loop. A routing config, a zones schema, a structured telemetry log, and a pipeline that traverses them in order. That is the entire architecture. Everything else is implication.

Jim Calhoun · The Grove Foundation · v2.0 · June 22, 2026

I

The Problem

The dominant paradigm for AI-assisted software is reactive. You ask. It answers. The session ends. Nothing is retained. Nothing is learned. The next session starts from zero.

This is not a limitation of the models. It is a limitation of the architecture. The models are capable of pattern recognition, context assembly, and nuanced classification. But the systems built around them treat every interaction as independent—a stateless request-response cycle with no memory, no governance, and no mechanism for improvement.

The consequences are structural:

No learning. The system cannot distinguish a request it has seen a hundred times from one it has never seen. Every query pays full inference cost regardless of novelty. Institutional knowledge evaporates between sessions.

No governance. There is no architectural distinction between a routine task and a high-stakes decision. The system treats “rename this file” and “restructure this database” with identical authority. Risk classification is absent, not because it’s impossible, but because no standard architecture requires it.

No sovereignty. The behavioral intelligence the system accumulates—your patterns, your preferences, your decision-making cadence—lives inside the provider’s infrastructure. You cannot inspect it, export it, or take it with you.

The industry has built brilliant models and wrapped them in architectures that cannot learn, cannot be audited, and do not belong to the people who use them. The Autonomaton Pattern addresses the architecture, not the model.

Architectural Governance

The Autonomaton is a self-authoring engine: it converts metered cloud dependencies into permanent, zero-marginal-cost institutional assets that get smarter, cheaper, and more private with use.

Operational Resilience

A model-agnostic, five-stage invariant pipeline that decouples business logic from the LLM provider.

The Skill Flywheel

Observation → Human Approval → Local YAML Asset. As the system “learns” your team’s judgment patterns, it authors its own deterministic code.

The Economic Ratchet

TCO Optimization: T3 → T0

The Cognitive Router demotes expensive frontier calls (T3) to local, deterministic rules (T0) as patterns confirm. Your ROI compounds as your API costs collapse.

Config Over Code

Governance is portable and auditable. Change system behavior via YAML files—no vendor re-training or deep-stack development required.

The CIO Stake: Centralized AI is a 100% depreciating OpEx. The Autonomaton creates Non-Depreciating IP the operator owns and compounds across providers, regardless of which model provider wins the scale war.

II

The Lineage

The Autonomaton Pattern is not novel. It is a synthesis of established ideas from computer science, industrial engineering, and the PC revolution’s deepest architectural insight: that coherent products are expressions of coherent worldviews.

The generation that built the personal computer treated product architecture as the embodiment of a worldview. Wigginton, Kare, Mok, Atkinson—design as philosophy expressed through constraint. The Macintosh was not a collection of features; it was a coherent set of structural commitments. Industry attention shifted to platform scale and that mode of architectural authorship became uncommon. The Autonomaton Pattern returns to it deliberately.

IBM, 2001

Autonomic Computing

Self-managing systems that configure, heal, optimize, and protect themselves. The Autonomaton extends this to the cognitive layer—systems that govern their own AI decision-making.

CS Theory, 1982+

Computational Reflection

Systems that inspect and alter their own execution. The Skill Flywheel is a reflective mechanism: the system observes its own behavior, proposes optimizations, and rewrites its routing table.

Toyota, 1960s

Digital Jidoka

Machines detect abnormalities and stop the line. Humans diagnose and approve the fix. The Zone Model is Jidoka applied to AI: the system detects risk, escalates appropriately, and never acts beyond its authority.

Industry Practice, 2010s

Telemetry-Driven Development

User behavior IS the feature request. The Autonomaton’s feed-first telemetry makes interaction data the primary input to the improvement cycle, not an afterthought.

III

The Pattern

Every Autonomaton instance traverses the same five stages, regardless of domain, model, or provider. The pipeline is not a suggestion. It is an invariant. Nothing runs alongside it. No sub-pipelines. No bypasses. No exceptions.

This constraint is the source of every property that matters: auditability, composability, portability, and the structural guarantee that every action can be traced to a governance decision a human can read.

01

Telemetry

Capture interaction data. Structured, inspectable, owned by the operator. Every interaction produces a trace—this is the system’s primary output.

02

Recognition

Classify intent, assess confidence, determine risk. The Cognitive Router dispatches to the cheapest tier capable of handling the request.

03

Compilation

Assemble context from local knowledge, historical patterns, domain expertise, and operator configuration. Build the response.

04

Approval

Zone-governed checkpoint where each write is classed by what it changes, not by its category. Green = in-scope, autonomous. Yellow = supervised. Red = scope-defining, human-only. The system never acts beyond its granted authority: a write that would expand the agent’s own scope is impossible on the autonomous loop, where the agent is capability-absent. When the operator issues an authenticated grant here, the agent executes that one scope change inline and stamps it with provenance — the authorized mutation that feeds the Skill Flywheel and lets the system improve with use.

05

Execution

Action fires. Output becomes telemetry for the next cycle. Audit trail generated as byproduct, not afterthought.

The Cognitive Router

At Stage 02, the Cognitive Router classifies each request and dispatches it to the cheapest tier capable of handling it. This is the mechanism that makes the system structurally cheaper over time—as patterns are confirmed, they migrate downward through the tiers. The LLM is the brain. Keywords are the bootstrap cache. Confirmed patterns become deterministic rules.

T0

Deterministic

Hardcoded rules, regex matches, keyword lookups. Zero inference cost.

Cost: $0

T1

Local Model

On-device inference. Private, fast, no network dependency.

Cost: ~$0

T2

Cloud (Fast)

Lightweight cloud models. Quick classification and routine generation.

Cost: Low

T3

Cloud (Frontier)

Frontier models for novel, complex, or high-stakes requests.

Cost: High

← Patterns migrate downward through confirmed use. The system gets cheaper as a structural property of operation. →

IV

The Principles

The Autonomaton Pattern implements the DEX (Declarative Exploration) standard—a set of architectural principles that separate exploration logic from execution capability. These are not guidelines. They are structural constraints. A system that violates them may work, but it is not an Autonomaton.

I

Declarative Sovereignty

Domain expertise belongs in configuration, not code. Every behavior rule is externalized in files a non-technical domain expert can read, edit, and version. Change the config, the behavior changes. Audit the config, the behavior is explained. No separate “explainability layer” required.

The test: can a domain expert alter system behavior by editing a YAML file, without a deploy?

II

Capability Agnosticism

The architecture never assumes specific model capabilities. Today’s frontier model is tomorrow’s local script. The Cognitive Router dispatches to tiers, not to specific models. Swap providers without rewriting governance. Architecture should make modest capability sufficient.

The test: if the model hallucinates, does the architecture contain it without breaking?

III

Provenance as Infrastructure

A fact without a root is a weed. Attribution chains are mandatory—the system tracks who collapsed the superposition and when. Every decision, every classification, every skill promotion carries a complete audit trail. Governance and auditability fall out of the architecture for free.

The test: can you trace any system action to the config rule and telemetry entry that produced it?

IV

Human-AI Symbiosis

AI generates possibilities. Humans apply judgment. The system requires human-in-the-loop for every transition that crosses a zone boundary. Sovereignty is structural: the system earns autonomy through demonstrated reliability and can never unilaterally grant itself new authority — on the autonomous loop, a write that would expand the agent’s own scope is impossible, the loop being capability-absent at the operating-system level, not merely refused. What the agent cannot do for itself, the operator can do for it: an authenticated, contemporaneous grant lets the agent execute one specific scope change inline, as the operator’s hands, every such write provenance-stamped to the grant that authorized it. Where no operator channel can be made unforgeable, the system authorizes no inline scope change at all and falls back to operator-performed writes — the relaxation is only ever as strong as the authentication of consent. That authorized, recorded mutation is how reliability compounds into autonomy — the essential input to the Skill Flywheel and the means by which the system ratchets capability toward cheaper, more local tiers.

The test: does the system ever act beyond explicitly granted authority, regardless of model capability?

V

Composability

Sovereign Autonomaton nodes compose through declarative interfaces rather than adapter code. The interfaces are structural — pipeline shape, telemetry format, zone semantics — not technological; an Autonomaton cultivated in YAML files, in a Notion database, in a Python service, or in text files and a shell script all compose identically, because they share architecture rather than code. This is cultivation architecture at work: the structural commitments create conditions for composition; the composition itself emerges when the commitments hold. Variance of substrate, of domain, of scale is the property the architecture relies on — the rich topology of a federated Autonomaton network is what grows from correct cultivation, not what gets engineered on top of it.

The test: can two independently developed Autonomatons — cultivated in different substrates, at different scales, by operators who have never met — compose into a working system by sharing only the pipeline shape, the telemetry format, and the zone semantics?

V

The Zone Model

Every action traversing the pipeline passes through Stage 04: Approval. The Zone Model determines what happens there. It is the structural guarantee that the system respects human authority—not through prompting, but through architectural constraint.

Green Zone

Autonomous

Routine operations the system handles without human intervention. These are actions the system has earned the right to perform through repeated confirmation—known patterns, low risk, high confidence. The operator defines the boundary.

Yellow Zone

Supervised

The system proposes, the human approves. Novel patterns, moderate risk, or insufficient confidence. The system presents its recommendation with full context. The human decides. Every approval or rejection trains the next cycle.

Red Zone

Human-Only

The system does not act on its own authority. It may provide context, but the decision belongs entirely to the human. Two things live here: high-stakes, irreversible, or ethically sensitive operations; and every write to the scope-defining surface — the zones schema, the routing authority fields, permission grants, skill activations — because changing those would change what the system is allowed to do. The system cannot promote itself out of the Red Zone: on the autonomous loop, a self-scope-expanding write is impossible—capability-absent at the operating-system level, not merely blocked. The operator, however, can. An authenticated, contemporaneous grant opens one scope change for the agent to execute inline — as the operator’s hands, provenance-stamped to the grant. That operator-authorized mutation, not any act of the system’s own, is how the Autonomaton’s repertoire grows and how the Skill Flywheel turns.

Zone boundaries are declarative—defined in configuration, not hardcoded—and in 2.0 they key on operator scope, not action category: a write’s zone is computed from what it changes (the scope-defining surface versus a granted in-scope workspace), never from which category of action it resembles. A healthcare deployment and a content-scheduling deployment use the same Zone Model with different boundaries. The architecture is identical. The governance is domain-specific.

Confused-Deputy Protection

Keying zones to scope raises one hard question: what stops an in-scope write from becoming a scope change by the back door? If the agent writes a harmless-looking note that some later step then reads as configuration, an in-scope write has quietly rewritten authority. The architecture closes this structurally. The scope-defining surface must declare every path it reads; a write qualifies as in-scope only when its target is provably disjoint from the transitive read-closure of that surface, a test that runs at Stage 04 before any write executes. And it fails closed: any undeclared or dynamic read path on the scope-defining surface forfeits autonomy for everything it could reach. The system never resolves ambiguity in favor of its own authority.

The Confirmation Gate

A scope change reaches the agent as a grant token: an operator-issued authorization naming one specific surface region and write class, authenticated through a channel the autonomous loop cannot forge, sticky across sessions until revoked, and provenance-stamped. The agent can request a grant; it can never issue one to itself. The grant token is delivered through the operator-authenticated channel—it never enters the agent’s write pipeline—so there is no bootstrap by which the agent could author its own authority. Sovereignty stays with the operator because the one artifact that opens a scope change is the one artifact the agent cannot produce.

Breadth is the operator’s to decide—the standard does not cap it, because capping it would violate Declarative Sovereignty. But breadth must be legible: an implementation should warn when a grant exceeds a configurable maximum scope, and a blanket grant (a surface_region of "*" or equivalent) must be recorded with an explicit scope: blanket provenance flag, so a standing grant that restores broad write authority can never be silent.

VI

The Flywheel

The Autonomaton is not a static system. It is a self-reinforcing improvement loop—a ratchet that turns interaction data into reusable skills and migrates those skills toward cheaper execution tiers through confirmed use.

The mechanism is structural, not statistical. Every skill is a readable specification—not an opaque weight adjustment. Delete a skill and the behavior stops. Add a skill and the behavior starts. The operator can inspect, edit, version, and audit every piece of learned behavior the system accumulates.

The LLM is the brain. Keywords are the bootstrap cache. Confirmed patterns become deterministic rules. The ratchet only turns in one direction: toward cheaper, faster, more private execution—unless the operator explicitly resets it.

01

Observe

Telemetry captures interaction patterns. The system watches what the operator actually does.

02

Detect

Recognition identifies recurring patterns that cross a confidence threshold.

03

Propose

Compilation generates a skill specification—a declarative rule the operator can read and approve.

04

Approve

Human reviews, edits, or rejects the proposed skill. Nothing enters the system without consent.

05

Execute

Confirmed skill handles future matches autonomously. Usage data refines the pattern or deprecates it.

The ratchet: T3 → T2 → T1 → T0. Skills migrate toward deterministic execution through confirmed use. The system gets cheaper as a structural consequence of operation.

VII

Reference Schemas

The Autonomaton Pattern is implemented through structured data—not proprietary APIs. The following schemas are illustrative, not exhaustive. They show enough structure that a developer can say “I could build this” and enough constraint that an architect can say “I can audit this.” The canonical machine-readable schemas—zones-v2, routing-operational-v2, routing-authority-v2, confirmation-gate, and provenance-stamp—are published under /standards/001/schemas/.

Migration from v1. 2.0 breaks compatibility with v1 routing configurations: the single routing.config is split into routing.operational (in-scope) and routing.authority (scope-defining), and the category-keyed zone_overrides is removed. A v1 config does not validate under 2.0 and must be migrated.

Telemetry Entry

{
  "id": "tel-20260315-001",
  "timestamp": "2026-03-15T14:23:01Z",
  "source": "user:direct",
  "input": "Schedule the weekly team sync for Thursday at 2pm",
  "context": { "domain": "scheduling", "recurrence": true },
  "session_id": "ses-4a7b",
  "provenance": { "operator": "jim@example.com", "environment": "atlas-v1.2" }
}

Intent Classification (Stage 02 Output)

{
  "intent": "calendar.schedule.recurring",
  "confidence": 0.94,
  "tier_assigned": "T0",
  "zone": "green",
  "surface_class": "in_scope",
  "matched_skill": "skill-weekly-sync-017",
  "fallback_tier": "T2",
  "classification_source": "keyword_match",
  "provenance": { "classifier": "cognitive-router-v3", "timestamp": "2026-03-15T14:23:01Z" }
}

Skill Specification

{
  "skill_id": "skill-weekly-sync-017",
  "name": "Weekly Team Sync Scheduler",
  "version": "1.3",
  "trigger": { "keywords": ["weekly sync", "team meeting", "recurring thursday"], "intent_pattern": "calendar.schedule.recurring" },
  "zone": "green",
  "lifecycle_state": "active",
  "activation_grant": "grant-20260218-008",
  "tier": "T0",
  "action": { "type": "calendar_create", "params": { "title": "Weekly Team Sync", "day": "thursday", "time": "14:00", "recurrence": "weekly" } },
  "promotion_history": [
    { "from": "T3", "to": "T2", "date": "2026-02-01", "confirmations": 3 },
    { "from": "T2", "to": "T0", "date": "2026-02-18", "confirmations": 8 }
  ],
  "provenance": { "created_by": "flywheel", "approved_by": "jim@example.com", "last_used": "2026-03-08" }
}

Routing — Operational (In-Scope)

{
  "schema_version": "2.0",
  "surface_class": "in_scope",
  "default_tier": "T2",
  "tier_preferences": {
    "T0": { "max_latency_ms": 50 },
    "T1": { "model": "local-llama-3", "max_latency_ms": 500 },
    "T2": { "provider": "anthropic", "model": "claude-sonnet" },
    "T3": { "provider": "anthropic", "model": "claude-opus", "retry": { "max_attempts": 2, "backoff_ms": 400 } }
  }
}

Routing — Authority (Scope-Defining)

{
  "schema_version": "2.0",
  "surface_class": "scope_defining",
  "writable_on": "operator_authenticated",
  "default_zone": "red",
  "escalation_threshold": 0.6,
  "approval_requirements": { "T3": true },
  "zone_assignment": { "keying": "operator-scope", "category_keying": "forbidden", "derived_from": "zones.schema/surfaces" }
}

Zones Schema (Scope-Keyed)

{
  "schema_version": "2.0",
  "keying": "operator-scope",
  "surfaces": {
    "scope_defining": {
      "writable_on": "operator_authenticated",
      "default_zone": "red",
      "members": [
        { "kind": "zones_schema", "path": "zones.schema" },
        { "kind": "routing_authority", "path": "routing.authority" },
        { "kind": "skill_activation", "path": "skills/*/activation.json" }
      ],
      "declared_read_paths": ["zones.schema", "routing.authority", "skills/*/activation.json"]
    },
    "in_scope": {
      "writable_on": "autonomous_loop",
      "default_zone": "green",
      "members": [
        { "kind": "telemetry" }, { "kind": "knowledge_artifact" }, { "kind": "pending_skill" }, { "kind": "operational_routing", "path": "routing.operational" }
      ],
      "granted_workspaces": ["research/", "notes/", "skills/proposed/"]
    }
  },
  "skill_promotion": {
    "pending_write": { "surface_class": "in_scope", "writable_on": "autonomous_loop", "zone_field_meaning": "proposal", "inert": true },
    "activation": { "surface_class": "scope_defining", "writable_on": "operator_authenticated", "requires": "verified_grant_token" }
  }
}

Confirmation Gate — Grant Token

{
  "schema_version": "2.0",
  "grant_id": "grant-20260621-007",
  "scope_target": { "surface_region": "skills/research/*", "write_class": "skill_activation" },
  "granted_zone": "green",
  "authorized_by": "jim@example.com",
  "issued_at": "2026-06-21T15:04:00Z",
  "authentication": { "method": "signing_key", "issuer_key_id": "op-key-3", "signature": "ed25519:9f3c1a2b" },
  "sticky": { "across_sessions": true, "across_reboots": true, "persists_until": "revocation" },
  "revocation": { "revocable": true, "status": "active", "handle": "revoke/grant-20260621-007" }
}

Provenance Stamp

{
  "schema_version": "2.0",
  "actor": "agent",
  "surface": "operator_authenticated",
  "surface_class": "scope_defining",
  "write_target": "skills/research/skill-arxiv-scan-003/activation.json",
  "write_class": "skill_activation",
  "pipeline_stage": "execution",
  "timestamp": "2026-06-21T15:04:02Z",
  "grant_id": "grant-20260621-007",
  "authorized_by": "jim@example.com",
  "source_chain": ["tel-20260621-114", "cls-20260621-114"]
}

Provenance Stamping

Every write the agent performs carries a provenance stamp: who or what wrote it, on which surface, under which grant, at which stage of the pipeline. This is Provenance as Infrastructure applied to the act of writing—and it carries the zone guarantee inside its own structure. A provenance stamp cannot describe a scope-defining write performed on the autonomous loop; the combination is unrepresentable, rejected before it can be recorded. Two layers stand behind that guarantee: the operating-system permissions make the action impossible—the autonomous loop is capability-absent—and the schema makes the impossibility auditable. “The agent cannot expand its own authority” is therefore not a rule the system promises to follow. It is a sentence the system cannot form. Cannot, not won’t.

VIII

The Implications

The Autonomaton Pattern is not a product. It is a set of structural constraints that produce properties the industry currently treats as features—governance, auditability, sovereignty, cost reduction—as architectural byproducts. The implications extend beyond any single implementation.

Terms of Art

The Autonomaton Pattern names four structural conditions that recur across AI deployments and that the architecture is designed to address or to produce. These terms are introduced here as canonical Grove terms; downstream standards (including GRV-003) cite them by reference.

Cognitive platforming. The structural condition in which the architectural drift of an AI deployment concentrates judgment, telemetry, and decision-context at the platform tier rather than at the operator’s node. Cognitive platforming is the consumption-layer analog of platform-side data lock-in: the same dynamic, applied to the substrate of human reasoning. The Autonomaton Pattern is an explicit countermeasure.

Judgment extraction. The flow of operator decision patterns, approval cadences, and discrimination criteria from the consumption layer back to the model provider, where they become inputs to the next training cycle. Distinct from telemetry extraction (which describes behavioral data flow); judgment extraction specifically describes the cognitive patterns the operator brings to evaluating model outputs. Extraction creates a recurring obligation; the architecture’s substrate-ownership constraint is what discharges it.

Lien on thinking. The accumulating dependency that results when an operator’s reasoning patterns are routed through a platform that retains them. Each interaction expands the lien; switching providers does not discharge it. The Autonomaton Pattern’s substrate-ownership constraint is the architectural mechanism for keeping the lien at zero.

Cultivation architecture. The architectural posture in which structural commitments—pipeline shape, telemetry format, zone semantics, substrate ownership—create the conditions for emergent properties such as composability, federation, and cross-substrate cooperation, rather than engineering those properties directly. Cultivation architecture treats variance of substrate, of domain, and of scale as the property the architecture relies on, not as a problem to solve. The Composability principle (Section IV.V) is cultivation architecture at work.

Governance by Architecture

Policy documents describe what systems should do. Architecture determines what systems can do. The Autonomaton makes governance structural: the Zone Model enforces authority boundaries, the pipeline enforces sequencing, and declarative configuration makes every governance decision inspectable. You do not need a compliance team to audit an Autonomaton. You read the config.

Auditability as Byproduct

The five-stage pipeline produces a complete audit trail as a consequence of normal operation—not as an additional feature bolted on after the fact. Every action traces back to a telemetry entry, a classification decision, a skill specification, a zone boundary, and an approval record. The question “why did the system do that?” always has a readable answer.

Sovereign Computing

The operator owns the telemetry. The operator owns the configuration. The operator owns the skills. The behavioral intelligence the system accumulates belongs to the person who generated it—not to the model provider, not to the platform, not to the infrastructure vendor. Switch providers without losing institutional knowledge. Inspect your own data without filing a request. Delete a skill and know it is gone.

The Vision

The Autonomaton Pattern is Act One of a three-act architecture.

Act One: The Autonomaton. The transistor. A single node—one person, one cognitive engine, one knowledge store—that authors its own improvement through the invariant pipeline. This document.

Act Two: The Trellis. The integrated circuit. A domain-scale knowledge architecture that organizes what individual Autonomaton nodes produce—making expertise navigable, refinable, and composable across an organization or discipline.

Act Three: The Knowledge Commons. The network. A distributed economy where Autonomaton nodes share refined knowledge with provenance, attribution, and market pricing intact. Not a database. A protocol for sovereign expertise exchange.

Same architectural DNA at every scale. The pattern you just read is the entry point.

The apex tier is critical infrastructure receiving roughly $650 billion in current capital commitments. The architectural layer that determines whether that investment compounds at sovereign nodes or evaporates as extractive dependency is receiving effectively none. That asymmetry is not stable. The Autonomaton Pattern is the engineering substrate the missing capital should be flowing toward.

Three files and a loop. The rest is distillation.

PDF JSON Manifest GRV-002: TCP/IP Paper GRV-001 · v2.0 · June 22, 2026 · CC BY 4.0

This document is published under Creative Commons Attribution 4.0 International (CC BY 4.0). You are free to share, adapt, and build upon this work for any purpose, provided you give appropriate credit.

Jim Calhoun · The Grove Foundation · Indianapolis · jim@the-grove.ai