untool.ai Bootstrap Order¶
This is the shared naming spine for directing coding-agent teams. Use it before assigning platform work so every thread knows what the parts are called and what must exist first.
Source of truth: ontology/platform-self-model/model/instances.yaml
Generated agent vocabulary: ontology/platform-self-model/generated/lexicon.yaml
Machine access:
- CLI:
npm run -s bootstrap:order -- --json - MCP:
platform_bootstrap_order
Operator Build Train¶
Use this table when directing agent teams. The operator phrase is what you call the work in chat, issues, PRs, and handoff packets. The module name remains the canonical ontology-backed name.
The bootstrap question is: how quickly can the platform safely build itself? So the runtime order starts with trust, then the smallest useful intelligence lane: a guardrailed LLM/MCP feed, available almost immediately after identity and AKV, so initial agents and the god-mode human can reason without bypassing policy. In this bootstrap context, intelligence means that governed reasoning feed, not the full future AI platform. The small file-backed bootstrap ontology packet comes next; it is the pre-Fuseki shared vocabulary and temporary bootstrap truth. Fuseki becomes the full source of truth after that bootstrap packet is online and loaded.
| Order | Operator phrase | Canonical module | Owning repo first | Runtime/container first | Unblocks |
|---|---|---|---|---|---|
| 0 | Establish trust | Identity and Secret Kernel | backend-core / platform hub | AKV + credentials broker | Agents can act without raw secrets or unaudited authority. |
| 1 | Turn on safe reasoning | Guardrailed LLM Feed | backend-core / platform hub | LLM gateway + MCP guardrails | Initial agents and the god-mode human can reason, inspect, and steer safely right after trust exists. |
| 2 | Carry the seed ontology | Bootstrap Ontology Packet | platform hub | file-backed ontology packet | Agents have shared words and module grammar before Fuseki is live. |
| 3 | Stand up truth | Fuseki Truth Store | platform hub | agentarmy-fuseki-ontology |
Fuseki becomes the full source of truth. |
| 4 | Publish the capability view | Capability Feed and Adoption Log | platform hub | feed + adoption audit | Agents can ask what capabilities exist and who must adopt them. |
| 5 | Start the semantic bus | NATS Semantic Bus | platform hub / backend-core | NATS JetStream | Platform facts can move as fast system messages. |
| 6 | Bridge fast messages to slower teams | Webhook Projector Bridge | platform hub / middle-core | agentarmy-platform-update-projector |
Non-NATS agents can subscribe by webhook/MCP. |
| 7 | Serve objects, not sources | UDA Object Model Runtime | backend-core | backend-core |
DataObjects can read through UDA instead of bespoke source seams. |
| 8 | Generate typed objects | Forge Codegen | agentarmy-forge | agentarmy-forge |
C#/TS/Python/Rust object contracts can be regenerated from ontology. |
| 9 | Create the source-control substrate | HVFS Source-Control Substrate | backend-core / commons-core | lakeFS + HVFS client/provider | Agents can work over virtual files, branches, content hashes, and evidence paths. |
| 10 | Show the control room | Fleet Console | frontend-core | frontend-core app | Humans and agents can see capability, adoption, fleet, and evidence state. |
| 11 | Move agents into contained runtime | MicroVM Agent SDK | platform hub / untool.ai SDK repo | microVM agent runner | Our own SDK agents can replace external coding-agent execution. |
| 12 | Prove adoption | Evidence and Adoption Closure | platform hub | watchdog/audit jobs | Capabilities can graduate from planned to adopted. |
| 13 | Replace GitHub as substrate | HUB on HVFS GitHub Replacement | HVFS/HUB repos after module 9 | HUB work coordination + HVFS-native source control | GitHub becomes optional for work/evidence routing. |
Short version: trust -> guardrailed LLM feed -> bootstrap ontology -> Fuseki truth -> capability view -> bus -> bridge -> UDA -> forge -> HVFS -> console -> microVM agents -> evidence -> GitHub replacement.
Bootstrap Dependency Gates¶
Treat each gate as the minimum evidence needed before launching dependent teams.
| Gate | Required proof | Teams that can start after the gate |
|---|---|---|
| Trust gate | Identity, AKV/secret references, and credential broker boundaries are available before agents or MCP tools act. | Guardrailed LLM feed, MCP tools, event publishers. |
| Intelligence gate | The guardrailed LLM feed can reason with the god-mode human through policy/identity boundaries. This is the minimum governed reasoning feed for safe self-building, not the full future AI platform. | Bootstrap ontology work and early self-building agents. |
| Bootstrap ontology gate | The pre-Fuseki ontology packet names modules, capabilities, surfaces, message families, and adoption tracks, and acts as temporary bootstrap truth. | Fuseki load, capability feed, agent handoffs. |
| Truth gate | Fuseki graph IRI and ontology instances contain the capability, message family, surface, and adoption track. | Capability feed, NATS publishers, MCP tools. |
| Feed gate | docs/platform-capability-log.feed.json, adoption status, board, launch packets, and work orders are current. |
Coding-agent adoption threads. |
| Eventing gate | platform.capability.*, platform.adoption.*, platform.hvfs.*, fleet.agent.*, and platform.security.* boundaries are explicit. |
NATS producers/consumers and webhook projectors. |
| Runtime gate | UDA receiver contracts and forge-generated fixtures prove DataObjects can talk to UDA. | backend-core, frontend-core, middle-core object consumers. |
| Workspace gate | HVFS client/provider contract exists and maps file, branch, commit, merge, diff, and evidence events. | MicroVM agent SDK and future GitHub replacement. |
| Agent runtime gate | Agents can discover capabilities through MCP, subscribe through NATS/webhooks, use UDA/HVFS, and emit evidence. | Contained SDK agents. |
| Closure gate | Adoption audit shows linked PRs/issues, validation commands, and closure evidence. | Capability graduation and replacement of GitHub lanes. |
Ordered Modules¶
| Order | Module | What It Is | Enables |
|---|---|---|---|
| 0 | Identity and Secret Kernel | Platform identity, AKV reachability, credential broker, and access guardrails. | Safe authority for every later self-building action. |
| 1 | Guardrailed LLM Feed | Governed LLM/MCP reasoning lane for initial agents and the god-mode human, brought up right after trust. | Safe reasoning before the platform is fully built. |
| 2 | Bootstrap Ontology Packet | File-backed pre-Fuseki ontology, lexicon, and capability grammar. | Early shared truth before Fuseki is live. |
| 3 | Fuseki Truth Store | The platform self-model loaded into Fuseki as the full source of truth. | Durable source of truth. |
| 4 | Capability Feed and Adoption Log | Machine feed, human log, GitHub adoption tracks, and audits. | Current view for coding-agent teams. |
| 5 | NATS Semantic Bus | MECE system-message families over NATS JetStream. | High-speed orchestration. |
| 6 | Webhook Projector Bridge | Projection from NATS CloudEvents to subscriber webhooks. | Teams without native NATS access. |
| 7 | UDA Object Model Runtime | Universal Data Adapter serving typed DataObjects from optimal backends. | Backend/frontend data access without source-specific seams. |
| 8 | Forge Codegen | Materializes ontology into typed Object Model outputs. | C#, TypeScript, Python, and Rust object contracts. |
| 9 | HVFS Source-Control Substrate | lakeFS-backed virtual filesystem for the future GitHub replacement. | Agent-native source control and evidence paths. |
| 10 | Fleet Console | Operator and agent-team surface for capability/adoption/readiness state. | Human-in-the-loop platform steering. |
| 11 | MicroVM Agent SDK | Contained SDK agents that use MCP, NATS, UDA, HVFS, and evidence contracts natively. | Replacement path for today's external coding agents. |
| 12 | Evidence and Adoption Closure | Audit and validation loop proving teams actually adopted capabilities. | Safe graduation from planned to adopted. |
| 13 | HUB on HVFS GitHub Replacement | Holonic Unified Board work flow backed by HVFS-native source control and platform evidence. | Reduces dependence on GitHub as the work/evidence substrate. |
Capability Words¶
Use these as verbs. Do not use surface names as capability names.
| Capability | Meaning |
|---|---|
| forge | Materialize ontology into typed Object Model code. |
| UDA | Serve Object Model/DataObjects from the best backend through a standard adapter. |
| sieve | Validate ontology conformance with SHACL gates. |
| capability announcements | Publish ontology-sourced capability facts to feed, MCP, and NATS projections. |
| HVFS | Provide the source-control substrate for the untool.ai GitHub replacement. |
| holonic work coordination | Coordinate kanban/work items through HUB while binding them to HVFS branches, diffs, merges, provenance, and evidence. |
| platform messaging update system | Carry semantically distinct high-speed platform updates through NATS, webhooks, and MCP. |
Surface Words¶
Use these as spaces where users or agents interface with capabilities.
| Surface | Exposes |
|---|---|
| Crucible | Corpus to ontology pipeline and forge. |
| Refinery | Snap JSON to typed fragments. |
| Registry | Ingest, assay, and bridge ontologies. |
| Workspace | Swarm synthesis, knowledge graph, HUB work flow, and HVFS workspace flows. |
| Fleet Console | Observability, agent orchestration, capability announcements, adoption state, and HUB/HVFS replacement readiness. |
HUB / HVFS Naming¶
Use HUB on HVFS for the combined GitHub-replacement product path.
| Word | Means | Do not collapse into |
|---|---|---|
| HUB | Holonic Unified Board; kanban/work coordination, lanes, assignments, blockers, dependencies, and evidence links. | HVFS |
| HVFS | Holographic Virtual Filesystem; branch, file, diff, merge, content hash, provenance, and evidence substrate. | Kanban |
| HUB on HVFS | The combined replacement lane where work items live in HUB and durable source/evidence objects live in HVFS. | Generic project board |
Agent Pickup Rule¶
Every coding-agent thread should start with this packet:
Read docs/untool-bootstrap-order.md.
Read ontology/platform-self-model/generated/lexicon.yaml.
Run npm run -s bootstrap:order -- --json when you need machine-readable module order.
Run npm run handoff:capabilities -- <repo-name>.
Read docs/platform-capability-adoption.status.json for the latest checked-in adoption status.
If touching capabilities, run npm run check:capability-feed.
If publishing adoption instructions, run npm run audit:capability-adoption-bootstrap.
If live issue state changed, run npm run status:capabilities.
If the snapshot changed, run npm run check:capability-status.
If closing adoption, run node tools/capability-adoption-audit.mjs --json.
If an agent cannot name the module it is changing using the ordered module names above, stop and update the lexicon/ontology first. That is a platform-design bug, not an implementation detail.