Architecture
Runtime Authority
Runtime Authority sits between human intent and AI execution. It is not a chatbot, not a prompt pack, and not “an AI agent.” It is the durable layer that owns truth for Missions, Runs, Target Sets, policy, and Evidence.
Why Runtime Authority — short conceptual explainer on the product page.
The problem
AI Workers can propose useful work and still claim success after failed commands, skip bounds, and leave proof in scrollback. When the model is treated as the system of record, operators inherit that unreliability.
Why prompts are insufficient
A prompt can request careful behavior. It cannot revoke a write grant, stop a loop, or prove a mutation stayed inside an approved path. Policy as natural language alone is a request, not a gate.
Why orchestration is not enough
Tool graphs still leave an open question: who owns Mission state, approvals, fail-closed bounds, and inspectable Evidence after the run? Without an authoritative runtime, orchestration is still chat with more steps.
Why Runtime Authority exists
Without it
Prompt → model → claimed “done”
- Truth lives in chat
- Policy is a request, not a gate
- Evidence is scrollback
- Workers look like the product
What Runtime Authority owns
It plans the Mission, compiles the Target Set, delegates to Workers, enforces the write envelope, collects Evidence, and leaves Preview and Promote as human actions. Humans stay in the loop wherever mutation requires a decision.
Runtime Authority control loop Human intent becomes durable runtime truth
- HumanOperator states intent
- MissionWhat should be true when the work is done
- WorkersReplaceable models and tools — never the authority
- EvidenceReceipts, run records, runtime logs
- Review / PromoteA verified change promoted from Evidence — not from chat
A Mission is not a prompt
A Mission states what should be true when the work is done. Runtime Authority binds it to a Target Set and executes it as Runs with approvals and Evidence — not as a longer system prompt.
Workers are replaceable
Workers are models and tools. They propose. They do not own grants. Swapping a Worker must not redefine policy or invent missing Evidence.
Who owns what? Runtime Authority is not an AI agent
Workers
Replaceable cognition
- Propose plans and patches
- Execute bounded tool calls
- Can be swapped under policy
- Never own runtime truth
- Never grant their own scope
Evidence, Preview, Promote
If it is not recorded, it is not runtime truth. Promotion is a human action on a verified change with Evidence and receipts — not on a model saying “done.”
Predator
Predator is Hotshot's private operator console; a small invited alpha is starting — write-enabled, with known limitations. Testers create a Project, attach a repository, and declare writable roots; writes inside those roots are autonomous on an isolated workspace branch, refusals are reported and recoverable, and push / PR / deploy stay governed. It is the primary operator experience for Missions, Runs, approvals, and Evidence. It is not part of the public OSS distribution.
Runtime Authority in one loop
Work targets a confirmed Target Set. Writes need a write envelope —
allowed roots, denied roots, deny-wins. The envelope is a ceiling, not a
grant. Inspect-only (INSPECT_ONLY) mints no write authority.
Work-in-branch (WORK_IN_BRANCH) runs in a branch inside the
envelope. If a worker wants a path outside it, it can only propose; the
runtime fails closed until an operator approves a Binding. Every Run ends
in a Result envelope: what changed, receipts, and an acceptance state.
Without a validation closure the state is UNVERIFIED; verification can
move it to PASS. Verification, Preview, and Promote are receipts, and
Preview is not production. Autopilot may continue inside one Mission
under budgets and a lease; it does not renew its own authority.