← Files Frontier InfraARCHIVED FILE
skills/machine-deployment/SKILL.md
4.07 KB · Oct 5, 2026 · 18:30 UTC
--- name: machine-deployment description: Implement, adapt, or harden a Frontier Infra Machine-shaped AI harness with a deterministic driver, durable state, fresh workers, independent verification, governance gates, budgets, quarantine, receipts, and runtime health. --- # Deploy The Machine Read `../../references/philosophy.md`, `../../references/system-architecture.md`, `../../references/pattern-catalog.md`, and `../../references/threat-model.md`. If the control loop asks a model to choose the next transition, stop and use `conductor-pipeline` or explicitly redesign it as an orchestrator shape. You are implementing the target Machine, not participating in it as a worker. ## Target runtime contract Implement or adapt a ratifiable work-contract capability in the target runtime with: - one outcome-oriented definition of done; - runnable acceptance checks and immutable constraints; - an independently ratified contract (`ratified_by` differs from `proposed_by`) before the target runtime performs commit-capable work; - worker-run and wall-time budgets; - a conservative initial autonomy ceiling (`0` / propose-only). Do not use `goal-contract` to gate the current coding task unless the user explicitly asks to govern the development workflow or a real ADL/Proctor-style integration already enforces it. ## Required deployment shape 1. Fill `../../assets/harness-design-dossier.md`; inventory every durable mutation path. 2. Define typed durable states, legal transitions, terminal quarantine, and write ordering. 3. Implement queue, worker, verifier, store, gate, receipt, alert, and ground-truth ports behind narrow adapters. 4. Persist before dispatch and before effects; enforce stable idempotency at the mutation store. 5. Start a new bounded worker for every attempt from contract plus current state, not transcript history. 6. Run contract checks in a distinct verifier and hard-deny success or mutation when it is absent, stale, or failed. 7. Evaluate operator dial, contract ceiling, scoped verifier trust, and verified reversibility at the single mutation gate. 8. Enforce attempt/resource budgets, acknowledgement escalation, terminal quarantine, and out-of-band override. 9. Emit receipts for transitions and gate decisions; publish health for every critical organ and the monitor itself. 10. Implement runtime health as four independent layers: process heartbeat, scheduler work-claim path, representative execution path, and governance gate path. Aggregate status must fail closed unless every layer passes a fresh check. ## Reference implementations Start from the working deployments instead of a blank page: `machine-driver` (github.com/frontier-infra/machine-driver) is the deterministic Box-2 driver for code work with Machine-L2 evidence; `conductor-public` is the orchestrator-shaped ops template. Adapt; do not reinvent. ## Target deployment verification Run kill/resume, duplicate replay, lying-worker, missing/stale-verifier, forged-rollback, cap/quarantine, override, bypass, and dead-workforce health fixtures against the target deployment before claiming enforcement. Validate runtime health with the published reducer — add `@frontier-infra/protocol` to the deployment and evaluate records with `evaluateRuntimeHealth` / `runtimeHealthExitCode`. When the user requests a conformance claim or the target's release criteria require it, score the target deployment repository with the published CLI, which bundles The Machine's static kit: ```sh npx -y @frontier-infra/audit run <path-to-deployment-repo> --out <dir-outside-that-repo> ``` Treat the generated evidence packet as the source for conformance claims. Static implementation review establishes only a `structural candidate`; a README claim or a passing happy path does not establish a Machine level. ## Boundaries - Start in propose-only mode; do not change to commit mode without a verified contract and operator authority. - Requeue failed work only within a fixed budget; quarantine and surface repeated failures. - Do not treat driver hash-chain logs as canonical AARs unless they are actually shaped, signed, and independently verified as AARs.
SHA-256: b63d4caabb6da0dc8431942f1df6b201f1c0d2d6bbffc4430bda47b5e461d584