Skip to content

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:

LAYER 1: REPO

Shared project state — .ostk/ directory, Agentfile, boot.md, pin caps. Committed to version control.

LAYER 2: OPERATOR

Personal identity — ~/.HUMANFILE (global) merged with .ostk/HUMANFILE (project). Never committed.

LAYER 3: HARNESS

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 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.

0
PARSE AGENTFILE

If the OSTK_AGENTFILE environment variable is set, boot reads and parses the Agentfile at that path. Resolves:

  • FROM <model> — which LLM the agent targets
  • TOOL <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.

0b
LOAD HUMANFILE

Hierarchical resolution loads operator identity and preferences. Resolution order:

  1. ~/.HUMANFILE — global identity (MODEL, SIGN, TRUST directives are immutable from this layer)
  2. .ostk/HUMANFILE — project-level config (may EXTENDS global)
  3. 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.

1
KERNEL INIT

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.caps and 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 .language file.

Before any of this, boot reaps dead agents from the process table and cleans up orphaned heartbeat files — housekeeping from the previous session.

2
PRELOAD RENDER

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)
  • .language register contents (all verbs, devices, services with their resolutions)
  • boot.md swap — 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.

3
INTENT COMPILE

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).

4
EXECUTION

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/version exists, 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.

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.

HUMANFILE_RESOLVE
CHECKS
Hierarchical HUMANFILE resolution succeeds. Global (~/.HUMANFILE) and project (.ostk/HUMANFILE) merge without conflict.
ON FAILURE
Graceful — defaults used. Warning printed.
TRUST_VERIFY
CHECKS
HUMANFILE SIGN evidence and verified primefile evidence resolve first, then the legacy GPG fallback. Trust tier (T0–T3) is determined.
ON FAILURE
Invalid required evidence fails closed. Missing GPG alone yields T3 only when no verified primefile or other recognized identity evidence resolves.
ENTITYFILE_SIGN
CHECKS
ENTITYFILE governance evidence is checked through the primary verifier, with detached .asc and Sigstore-era artifacts treated as legacy compatibility paths.
ON FAILURE
Invalid signature at primary location is fatal. Missing ENTITYFILE is non-fatal (fresh install).
DRIVER_PROBE
CHECKS
Declared drivers are probed via Unix socket. Alive drivers registered; inactive ones marked for demand-spawn.
ON FAILURE
Graceful — inactive drivers spawn on first use. No boot failure.
LANGUAGE_INIT
CHECKS
.language registry is populated with kernel services, MCP primitives, HUMANFILE VERBs, and introspection tools.
ON FAILURE
Unresolvable VERBs reduce boot confidence score but do not halt boot.
CHECKPOINT_VERIFY
CHECKS
The most recent checkpoint is checked through its configured attestation verifier, including legacy detached signatures where present.
ON FAILURE
Fatal for governed agents. Advisory for interactive sessions. Expired keys reduce confidence.
VERSION_PIN
CHECKS
Running binary version matches .ostk/version pin (if present).
ON FAILURE
Warning with upgrade hint. Boot continues.

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:

IDENTITY COMPLETENESS

HUMANFILE loaded, trust tier resolved, ENTITYFILE verified. Missing identity layers drag the score toward zero.

RESOLUTION QUALITY

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.

INIT VALIDATION

The INIT verb sequence is checked against .language. Missing verbs in the post-language chain penalize confidence.

The score determines the operating mode:

FULL
0.90 – 1.00
All capabilities available. Normal operation.
MINIMAL
0.50 – 0.89
Core operations available. Some advanced features may be constrained.
RESTRICTED
0.00 – 0.49
Read-heavy mode. Write operations may require explicit confirmation. Fresh projects with no audit history start here.

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.

A typical ostk boot run on a configured workspace. Each line maps to a stage above:

ostk boot

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)
Stage 0b succeeded. Only ~/.HUMANFILE was found (no project-level HUMANFILE). Identity and preferences resolved from the global file.
trust: T1 (endorsed identity, guarded source writes)
Stage 1. Verified evidence is endorsed by a T0 root. Source writes remain subject to kernel-state and governance restrictions.
.language: 58 verbs | fleet: 0 alive
Stage 2–3. The .language registry holds 58 verbs. No agents are currently running.
needles: 0 open
No open work items. The needle system is idle.
boot confidence: 0.00 (restricted mode)
Stage 3. No audit history yet — the confidence score starts at zero on a fresh workspace.

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.

MCP client
DETECTION
Configured ostk MCP connection
TOOL ROUTING
Namespaced System ABI tools; coverage follows the called verb.
embedded loop
DETECTION
ostk-managed CPU agent
TOOL ROUTING
System ABI plus the embedded approval chain and lifecycle.
CI
DETECTION
CI=true or provider-specific signal
TOOL ROUTING
Explicit CLI/System ABI integration; no assumption of a TTY.
native client
DETECTION
No ostk route selected
TOOL ROUTING
Client-native tools remain outside kernel audit, policy, and CAS OCC.

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 init first. The OS requires a git repository as its substrate.
  • Git repo, no .ostk/ — prints the full welcome with ostk init and ostk init --guided options.

After running ostk init, re-run ostk boot to complete the full boot sequence. See Quick Start for the step-by-step guide.