Boot Sequence
Boot reads .ostk/ state, resolves identity, initializes the current kernel surface, and reports what it found. It can perform kernel-state housekeeping such as stale-process cleanup, but it does not rewrite ordinary project source as part of discovery.
What Boot Does
ostk boot assembles a complete picture of the current workspace from three layers:
Shared project state — .ostk/ directory, Agentfile, boot.md, pin caps. Committed to version control.
Personal identity — ~/.HUMANFILE (global) merged with .ostk/HUMANFILE (project). Never committed.
Runtime environment — detected from environment variables at startup. Determines tool routing policy. Ephemeral.
The output is the merged context: context = f(repo) + g(operator) + h(harness). The agent instance receives this at session start. It knows who it is talking to, where it is running, and what it is allowed to do — without being told.
BOOT_STAGES
Boot executes five stages in strict sequence. Each stage depends on the output of the previous one. If a stage fails fatally, boot halts and prints a diagnostic.
If the OSTK_AGENTFILE environment variable is set, boot reads and parses the Agentfile at that path. Resolves:
FROM <model>— which LLM the agent targetsTOOL <name>— tool declarations (counted, not loaded)LIMIT,ISOLATION— resource and sandbox constraints
Missing Agentfile is non-fatal — boot continues with defaults. Present-but-unreadable is an error.
Hierarchical resolution loads operator identity and preferences. Resolution order:
~/.HUMANFILE— global identity (MODEL, SIGN, TRUST directives are immutable from this layer).ostk/HUMANFILE— project-level config (may EXTENDS global)- Merge if both exist — project overlays global, but identity fields stay pinned to the global source
Directives resolved at this stage: MODEL, SIGN, PREPROCESS, TRUST, SECRET, EMBED, DRIVER, VERB, BOOT.
After loading, boot auto-populates the AVAILABLE model list by scanning for known API keys (ANTHROPIC_API_KEY, GEMINI_API_KEY, etc.) and initializes secret masking for any SECRET directives.
The identity and capability layer. Boot determines who you are and what you can do:
- Trust tier — HUMANFILE and verified primefile evidence resolve first; the local GPG keyring is the fallback path for T0 through T3.
- ENTITYFILE — governance evidence is loaded through the supported verifier. Current Ed25519/DSSE paths are primary; detached GPG and Sigstore-era artifacts remain compatibility routes.
- Pin caps — when
OSTK_PIN=<name>is active, capabilities load from.ostk/pins/<name>/pin.capsand compose with tier defaults. - Drivers — declared drivers probed via Unix sockets. Boot never spawns drivers — it only checks what is already running. Inactive drivers are registered for demand-spawn on first use.
- .language — the verb registry is populated. Kernel services, MCP primitives, introspection tools, and HUMANFILE VERB directives are all registered into the
.languagefile.
Before any of this, boot reaps dead agents from the process table and cleans up orphaned heartbeat files — housekeeping from the previous session.
Builds the context injection that every agent instance receives at session start. The preload is assembled from:
- Project structure scan (what files exist, language breakdown)
.languageregister contents (all verbs, devices, services with their resolutions)boot.mdswap — the compiled operator section replaces the template boot.md- Identity blocks from HUMANFILE (communication style, scheduling preferences, corrections log)
The stable portion can be rendered once and reused locally. Compatible Anthropic routes may optionally upload a file-backed copy for context efficiency, but upload is not required and other routes can keep the same artifact local.
Resolves the tack grammar and validates the dispatch loop:
- Tack grammar — HUMANFILE VERB definitions are validated against
.language. Unresolvable verbs reduce boot confidence. - INIT validation — the post-language INIT verb sequence is checked. Missing verbs in the INIT chain are flagged and penalize the boot confidence score.
- Verb momentum — recent tack resolution history from the audit log is loaded to seed the confidence gradient.
After this stage, the compressed register dump is printed — a one-line summary of .language state (verb count, fleet size, open needles).
The agent loop begins. Boot transitions from observation to action:
- Harness detection — environment is probed to determine tool routing (Claude Code, ostk-serve, CI, terminal). This controls whether the agent uses native tools or MCP primitives.
- Checkpoint verification — the most recent checkpoint is checked through its configured verifier. Current attestation and legacy detached-signature paths have separate compatibility rules.
- Version pin — if
.ostk/versionexists, the running binary version is checked against the pin. - Continuation prompt — if enabled, a dynamic prompt is generated from current workspace state and written to
.ostk/prompts/continuation.md.
The embedded CPU agent loop uses the 7-step approval chain. Other System ABI verbs use their own documented policy and audit paths.
POST_CHECKS
Power-On Self-Test. Seven checks run during boot to verify system integrity. The POST 7/7 line in boot output confirms all passed. A failed check does not necessarily halt boot — some degrade gracefully, others are fatal.
Boot Confidence
The boot confidence score is a 0.00–1.00 value computed at the end of boot. It measures how well the system can resolve operator intent into action. Three inputs feed the score:
HUMANFILE loaded, trust tier resolved, ENTITYFILE verified. Missing identity layers drag the score toward zero.
Recent tack resolutions from the audit log are weighted by tier (T1 = 1.0, T2 = 0.8, T3 = 0.5). High-tier resolutions lift the score.
The INIT verb sequence is checked against .language. Missing verbs in the post-language chain penalize confidence.
The score determines the operating mode:
A fresh project with no audit history will always show 0.00 (restricted mode). This is normal — the score rises as the system accumulates successful tack resolutions. It is a measure of earned trust, not a pass/fail gate.
BOOT_OUTPUT
A typical ostk boot run on a configured workspace. Each line maps to a stage above:
✓ HUMANFILE loaded (global only)
trust: T1 (endorsed identity, guarded source writes)
.language: 58 verbs | fleet: 0 alive
needles: 0 open
boot confidence: 0.00 (restricted mode)
✓ HUMANFILE loaded (global only) trust: T1 (endorsed identity, guarded source writes) .language: 58 verbs | fleet: 0 alive needles: 0 open boot confidence: 0.00 (restricted mode) Harness Detection
Boot can identify common execution environments, but the active integration still determines which operations enter the kernel boundary. Use the namespaced ostk tool surface when its audit, policy, context, or CAS behavior matters.
Configured ostk MCP connection ostk-managed CPU agent CI=true or provider-specific signal No ostk route selected
The OSTK_HARNESS environment variable overrides all detection — it always wins.
First Run
When no .ostk/ directory is found, boot does not fail — it prints a welcome message and guides you to initialization:
- No git repo — suggests
git initfirst. The OS requires a git repository as its substrate. - Git repo, no .ostk/ — prints the full welcome with
ostk initandostk init --guidedoptions.
After running ostk init, re-run ostk boot to complete the full boot sequence. See Quick Start for the step-by-step guide.