Skip to content

docs: concrete operation execution, fencing, and recovery - #62

Draft
scotwells wants to merge 8 commits into
mainfrom
proposal/execution-recovery
Draft

scotwells wants to merge 8 commits into
mainfrom
proposal/execution-recovery

Conversation

@scotwells

@scotwells scotwells commented Nov 14, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Execution, fencing and recovery: proposed documentation only. Select the shared management asset slot, selected-cell durable inbox/step journal, one effect broker, exact protected inputs, L1–L5 and conservative S1 uncertainty. Preserve one Installation driver, real physical stop evidence, bounded authority, no blind hardware replay and independently fenced restore.

Add PhysicalMaintenance as a fourth explicit subject, with a finite field procedure rather than a commissioning boot plan. The same cell broker journals S1 before one-use permit delivery and once-only online start. Independent witness/site/old-crew exclusion proves cessation; expiry does not. Add cancellation, dependency and restore cases; update both DOT/SVG diagrams and passive qualification applicability.

Remaining P2 response and preserved boundaries

Responds to the exact fresh complete-set review. The earlier commissioning/adopted-settlement findings remain resolved in the proposed contracts; this revision does not replace them with maintenance.

  • physical-maintenance-v1 adds one explicit subject to the existing shared custody/slot/journal/release protocol, not a second allocator or executor.
  • Passive Device work has exact asset/resource/custody identity, current action/input authority, protected finite work inputs and one-use technician permits; no MachineCapacity, Machine, quota hold, Installation or bootstrap is invented.
  • Active dependent devices and connections retain their own custody and writers. Their separately authorized, effective prerequisite fences precede field admission; target clearance cannot reset, disconnect, wipe or reconnect them.
  • Unknown work, delivery, cessation, identity, accounting or physical clearance retains custody and conservative old/new interests. Restoration reconciles independent owner/field history and excludes old crews before any recovery authority.
  • L5, R2, physical reservation disposition and fresh inventory eligibility remain separate. Observational adoption causes no effects. Catalog withdrawal blocks acquisition but does not revoke retained runtime capabilities; current action/input rights and separate suspension remain mandatory.

No runtime implementation, core #41/#51/#58/#59 change, managed-service scope, compatibility machinery, new PR, merge, watch or self-signoff. This existing branch remains based on origin/main at 8ebec19513a0cbc8f219d3acae46f89ab471510b; companion branch diffs are not imported.

Exact final complete-set manifest

PR Exact final head
#41 f04e63ddd9d10cbf306daf3a0232961debd85e7f
#51 fa07c2236801a33a58efc914b555586c8e146cc6
#58 a922ff1eb3275e26af6ae750a7515ddde245a754
#59 d7ff793b03711203dbfc9fac87d43922cc649b6f
#60 80c72446a574202c9dac5f6d3c26ce4a0af875ba
#61 8101f645cc8167f71a07147e6ea1a9cdf69a57cf
#62 496ec4530aa3bacdb4858d0b22192be1a92b0c48
#63 ce4a30a36ee476073281b40b8353ac5eb2c99e0c
#64 4495e20f4c3ee7697dfd97a5a95823ca5fa7b448
#65 94824bf7ef614fcdecf3ce813c289e259367e90c
#66 ffe6ed28e261578bbc3d0226585b5e80f5d5985c

This PR's final head is 496ec4530aa3bacdb4858d0b22192be1a92b0c48. Core heads are unchanged. #60–#65 pin immutable contract-bearing snapshots; #66 pins their final source heads. Post-contract commits refresh only pins/review provenance, avoiding circular final-head dependencies. Older embedded pins in snapshots are drafting history, not authority to substitute an older contract for this aligned set.

PR Immutable contract-bearing snapshot
#60 4bf770db8bd2b065748c3b9384d4c72f9b8ec0e1
#61 25fef48790b13da95900de64ffd2d1b36e0510eb
#62 4f9934980b3f441c1d777157fa0ba1dcfce372d7
#63 2b384517fd08c04cf078923ebda2cddcfa1dc424
#64 58a6596d30b3819d0b3799192730626439ef9885
#65 310a55d97394bb296c579bd3ad01177455c15cc4
#66 26601c7121542d7c89ddac84c1f8592f08cb8372

Documentation validation

  • Combined all eleven revisions with temporary git merge-tree/commit objects only: conflict-free; no branch or PR merge and no shell worktree. Combined tree c5c26cf30c2ee1f974404576220c106ad32961f2, local validation commit 036e40a0573be61b506fff7e8604bac4377117a0.
  • Repository link checker plus fence-aware validation: 48 Markdown files, 647 local targets, 355 local anchors, no missing targets/anchors or undefined explicit references. All 21 unique pinned Fleet source paths exist.
  • 15 SVGs parse/render; both DOT sources render; all three PlantUML sources pass check-only; four JSON examples parse. Three changed SVGs visually inspected for clipping/layout.
  • D01–D40, I1–I39 and N1–N23 have unique contiguous definitions. All preexisting D01–D35, I1–I35 and N1–N21 rows remain byte-for-byte unchanged. New scenarios are specifications, not qualification runs.
  • Per-PR changes remain inside each intended enhancement directory; original unrelated branch changes preserved. Original supplied head is an ancestor of each published head. Per-PR and combined whitespace checks pass.
  • External HTTP sources were not comprehensively revalidated. docs: propose standalone Metal network handoff #61's previously unavailable cloud attachment reference remains an explicit owner prerequisite, not an assumed integration.

Remaining prerequisites and review status

Fresh independent complete-set integration review is required for this exact changed manifest; no previous approval or author check signs off these revisions. Implementation still needs the shared ledger hooks and synchronous storage/restore interlocks, independent R/KMS/PKI and physical fences, registered owner gates, protected inputs/evidence, qualified online field permits and site/crew exclusion, active-custody/network owner agreements, accounting applicability proofs, measured profile limits and real qualification/drills. QP does not qualify compute or supplier execution. R-history-loss reactivation remains unsupported until separately implemented and qualified.

No runtime, hardware, provider, Q0/Q1/QP/QD/QE qualification, owner approval or independent signoff is claimed. Ready for the requested fresh independent review, not merge or deployment approval.

Copy link
Copy Markdown
Contributor Author

CHANGES REQUIRED — 23d9423d9d705927d012431d3c8bae8da101deb8

Independent adversarial architecture review, standalone Fleet/Metal only. Refreshed head matches the requested SHA. Reviewed the full execution proposal and DOT/SVG diagrams against the repository/source baseline and #41/#51/#58/#59; cross-checked #60 at 2563b2a2f177a72d20c1d62265c89ff15688ba25 and #61 at ed6edec5b056fd53343e11d58d979af495f1bd7c.

P1 — Order new operation authority against the allocation ledger's authority gates. L1, lines 204–215 resolves authorization first, then commits against binding/slot/predecessor/closure state. It does not require the transaction to consume the exact current-action/input AuthorityGate dependency vector or lock/validate ProviderGuard; the allocation-local closed marker is not the same thing. The same ordering is unspecified for renewal, lines 267–268.

Counterexample: an install caller receives an allowed image-use decision, then pauses before L1. IAM closes its #60 gate and makes revocation effective. The allocation remains bound with an open slot and unchanged predecessor. The enumerated L1 checks still pass, so a new operation/outbox can commit using the still-unexpired old decision. Bounded continuation of authority admitted before revocation does not justify this admission after revocation. Merely sharing PostgreSQL does not serialize transactions that do not contend on the same authority rows.

Minimum fix: explicitly consume #60's gate-vector/epoch/deadline validation and shared ProviderGuard ordering at L1 and management authority renewal, with the same ledger recovery lineage and lock order. Validate runtime action/input/suspension gates, not withdrawn acquisition grants. Require closed/changed/expired dependencies to prevent dispatch authority and add the paused-evaluation/revocation race to the acceptance matrix. This is a missing semantic integration rule, not a request to implement IAM or hardware in a documentation PR.

No additional architecture blocker found in delayed accepted BMC commands, unknown-ack/task dedup, physical installer stop versus new boot, stale broker/journal restore, hung senders/queues, tombstone-before-inbox ordering, expiry/cleanup, lost callbacks, asset reincarnation, or immutable-driver takeover. #61's exact owner evidence and durable terminal/no-reuse barriers are compatible with the execution settlement requirements; they remain necessary owner prerequisites, not an address-release decision by execution. Independent physical fencing, credential/path exclusion, zero-loss journal failover, boot trust and firmware/storage qualification remain explicit production enablement gates, not demonstrated behavior. No exactly-once hardware guarantee is accepted. No code changes, approval, merge, or watch performed.

Copy link
Copy Markdown
Contributor Author

ARCHITECTURAL SIGN-OFF — 7fa823050a443c1f5b85c56e85ed04ebaa5bd2cb

Fresh independent adversarial review of the full execution-recovery proposal and diagram source semantics, cross-checked against #60 2563b2a2f177a72d20c1d62265c89ff15688ba25, #61 ed6edec5b056fd53343e11d58d979af495f1bd7c, and the pinned #41/#51/#58/#59 contracts. Refreshed GitHub head immediately before this verdict; it matches the reviewed commit.

The previous architectural blocker is closed. In docs/enhancements/execution-recovery/README.md:204–228, L1 now retains and transactionally validates the complete current-action/input dependency vector, Open epochs/revisions, caller/digest, deadline and recovery lineage. Renewal explicitly uses those same checks at lines 280–290. Trace: evaluation succeeds → authority gate closes → paused admission/renewal resumes; the old decision cannot commit new operation/outbox authority. Conversely, a commit that wins before closure remains previously admitted bounded authority, not instantaneous physical revocation. The acceptance matrix now includes both that race and ProviderGuard/lineage changes (669–670).

The shared sorted-gates → ProviderGuard → applicable ledger rows → operation-slot order matches #60; no opposite lock acquisition or remote-call-under-lock requirement is introduced. Runtime evaluation expressly avoids reacquiring withdrawn offering/assignment grants. Provider closure rejects ordinary authority while retained service cleanup remains a separate, scoped lane—not permission to continue customer installation.

No additional architectural blocker found after challenging: S1-before-send crash/paused-sender traces and lost BMC replies (344–401); persistent BMC queues and independent power restoration (427–460); RAM-installer/storage stop versus PXE revocation (462–487); immutable-driver takeover and partial-disk holds (522–549); independent restore activation/lineage and missing inputs (588–644); and network-owner exact-revision receipts, stale downstream writers, identity/freshness and release separation (489–503, 553–570, 650–658), including #61's binding/claim tombstones and no-reuse barriers. None permits an unknown effect to become readiness, a callback to prove installer termination, or execution settlement alone to release addresses/capacity.

Scope: standalone Fleet/Metal proposed architecture only. This is not runtime, hardware, platform-owner, managed-platform, production-readiness or merge approval. Authority-owner gate participation, transaction integration, zero-loss/fenced storage, independent recovery custody, exclusive broker paths, qualified BMC/host/storage barriers, boot trust, network-owner realization/receipts, and protected input/key recovery remain mandatory production prerequisites. The failure matrix is specified—not executed testing. Documentation diff whitespace check passed; repository files were not edited. All currently reported PR checks pass; formal review remains required. No formal self-account approval, merge or watch performed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant