Conversation
Reconcile the THOTH-GQL-OPS-03 effective-mode fleet-verification specification against the post-THOTH-GQL-OPS-02 repository state and resolve its mandatory section 3.2 information-disclosure decision, so it can go for fresh independent specification review. Specification and control only. No runtime, GraphQL, schema, migration, workflow or infrastructure change; no implementation; no implementation branch created. Section 3.2 is now RESOLVED: the effective-mode verification signal must be available only through an orchestration/administrative-plane or equivalent out-of-band per-instance mechanism; a public unauthenticated effective-mode surface is REJECTED; the public GraphQL schema stays unchanged; and only the effective MutationGuardMode plus the minimum runtime identity needed to correlate one observation to one orchestrator-enumerated instance may be disclosed. The rejected alternatives and the reasoning are recorded, and reopening the decision is reserved to the CTO. The pre-OPS-02 premise is corrected throughout: the specification no longer describes the image-default init path as ignoring THOTH_GRAPHQL_MUTATION_GUARD_MODE, because OPS-02 merged and closed capability gap 1. The silent-adoption failure class survives the fix and is now stated generically as configured intent != process-effective mode, with capability gap 2 the one still open. Acceptance criteria are strengthened, never weakened: complete fleet enumeration is required rather than merely supported, incomplete coverage must fail closed with UNKNOWN structurally distinct from OFF (AC-22), a negative test must prove no unauthenticated public caller can obtain the mode (AC-11.1), and the disclosed correlation identity must be justified field by field (AC-23). Status remains DRAFT and implementation remains NOT AUTHORIZED. CG-13 stays OPEN, the runtime-operations gate stays NOT SATISFIED, the runbook stays PROVISIONAL, OBSERVE, ENFORCE and BE-02 runtime stay NOT AUTHORIZED, OPS-04 stays unimplemented, and CL-1 is unchanged.
ja573
left a comment
ja573
left a comment
There was a problem hiding this comment.
Independent exact-head specification review — THOTH-GQL-OPS-03-SPEC
Decision: CHANGES REQUIRED
Exact head reviewed: e8e8fb3af0616a5745bfbd4bcf583d873ec2d955
Authorized base: d0f71ee10d3c3f3482fd76796f1ded31cbb2de8b
Risk: HIGH
The core specification direction is sound: OPS-02 is correctly reconciled as merged, capability gap 2 remains the target, the §3.2 administrative/orchestration-plane or out-of-band boundary is coherent, the public unauthenticated surface is rejected consistently, complete enumeration/UNKNOWN/fail-closed requirements are materially strengthened, and implementation authorization remains separate. The diff is documentation-only and exact-head CI is clean for that classification.
Three bounded documentation/evidence defects must be corrected before specification approval:
1. Unsupported feasibility assertion in §3.2.3 / preparation report
The specification states that "At least one mechanism class within this boundary is available in-repository without infrastructure change", and the preparation report repeats that claim. This review found no evidence establishing that claim. In particular, satisfying the task requires both a process-effective-mode signal and runtime identity correlatable to the orchestrator's enumerated instance; whether an existing in-repository mechanism can provide that without infrastructure change has deliberately not been established here.
The existing STOP rule already handles this correctly. Therefore remove the positive feasibility assertion, or explicitly classify feasibility as not established at specification time and require the implementing task to determine it within the approved boundary. If no permitted mechanism satisfies section 3, implementation returns BLOCKED; it must not fall back to a public surface.
Do not change the selected §3.2 boundary.
2. Un-evidenced current production-state claim in the preparation report
Report §12 currently states:
deployed production release = pre-guard (no guard mode exists)
The same report states that no external deployment fact was required and neither Route A nor Route B evidence was obtained. A current deployed-release statement is an external/runtime fact and cannot be asserted as current from repository evidence or inherited historical evidence alone.
Remove this line from the specification-preparation rollout state, or explicitly mark it historical / [UNVERIFIED here] without using it for any conclusion. This specification task does not need the current deployed production release to approve OPS-03.
No protected-source read is required to fix this.
3. Branch-status wording in the decision register is too broad
The new decision-register text says THOTH-GQL-OPS-03 and -04 ... neither of their branches exists, while this PR itself is on feature/shared-architecture/graphql-guard-mode-fleet-verification-spec.
The intended control fact is that the reserved implementation branches do not exist. Say that explicitly. Branch existence is a lifecycle/control fact, so the register must not use wording that is literally contradicted by the active specification branch.
Scope of remediation
This should remain a documentation-only follow-up on the same branch/PR. No Rust, infrastructure, task implementation, ADR-0006, runtime-control record, runbook, or protected-source access is required. The §3.2 decision itself does not need to change.
After the follow-up commit, the new exact head requires fresh CI and fresh independent specification review. Keep PR #798 DRAFT and UNMERGED; do not create the OPS-03 implementation branch; do not authorize implementation or activation.
Independent exact-head specification review 4905511366 returned CHANGES REQUIRED at e8e8fb3 with three bounded documentation/evidence defects and no redesign request. All three are remediated here, on the same branch and pull request. Documentation only: no runtime, GraphQL, schema, migration, workflow or infrastructure change, and no external evidence gathered. Finding 1 - unsupported feasibility assertion removed. The claim that at least one mechanism class within the approved boundary is available in-repository without infrastructure change was unsupported by any evidence this specification task gathered. It is removed from specification section 3.2.3 and from the preparation report, and is not replaced by an equivalent claim. Feasibility is now explicitly classified as NOT ESTABLISHED at specification time: the implementing task determines it from evidence and returns BLOCKED if no permitted mechanism satisfies section 3. A public unauthenticated surface remains unavailable as a fallback, and the distinction approved boundary != preselected mechanism is stated explicitly. Finding 2 - un-evidenced current production-state claim withdrawn. This task obtained no Route A evidence, no Route B evidence and read no protected source, so it may not assert a current deployed release. The pre-guard line is withdrawn from the preparation report's rollout state and from the identical inherited line in specification section 11, replaced by NOT RE-ESTABLISHED BY THIS SPECIFICATION TASK. The OPS-01 pre-guard finding stays historical evidence owned by its own record, is not re-certified and is used for no conclusion. Production is not relabelled OFF. Finding 3 - branch-status wording corrected. The decision register now names the two reserved IMPLEMENTATION branches explicitly, records that neither exists, and states that a specification branch is not an implementation branch and constitutes no implementation authorization. The section 3.2 architecture decision is unchanged, no acceptance criterion is weakened, and no public surface becomes permitted. The specification stays DRAFT with implementation NOT AUTHORIZED, the reserved implementation branch remains absent, and CG-13, the runtime-operations gate, the runbook, OBSERVE, ENFORCE, BE-02 runtime and CL-1 are all unchanged.
ja573
left a comment
ja573
left a comment
There was a problem hiding this comment.
Independent exact-head specification review — THOTH-GQL-OPS-03-SPEC
Decision: APPROVED
Exact head reviewed: a24536e868c05205eeefd9e5f3b19731290926ca
Authorized base: d0f71ee10d3c3f3482fd76796f1ded31cbb2de8b
Risk: HIGH
The prior CHANGES REQUIRED review 4905511366 is fully remediated on this exact head.
Finding closure
- Unsupported feasibility assertion — CLOSED. The specification and preparation report no longer claim that a compliant mechanism is already known to exist. Feasibility is explicitly
NOT ESTABLISHEDat specification time and is delegated to the implementing task, withBLOCKEDas the required outcome if no permitted mechanism satisfies section 3. No public unauthenticated fallback is reopened. - Un-evidenced current production-state claim — CLOSED. The specification and preparation report now state that the deployed production release was
NOT RE-ESTABLISHED BY THIS SPECIFICATION TASK; the historical OPS-01 pre-guard finding is not re-certified or used for a current conclusion. No Route A/B evidence or protected-source read is claimed. - Branch-status wording — CLOSED. The decision register now explicitly refers to the two reserved implementation branches, records them absent, and distinguishes the existing OPS-03-SPEC documentation branch from implementation authorization.
Specification decision
The section 3.2 architecture boundary remains coherent and unchanged in substance:
- administrative/orchestration-plane or equivalent out-of-band per-instance mechanism only;
- public unauthenticated effective-mode surface rejected;
- public GraphQL schema unchanged;
- disclosure limited to actual effective
MutationGuardModeplus the minimum identity necessary for orchestrator correlation; - no secret, credential, environment value, deployment configuration, publisher/user/request data, or unnecessary topology metadata.
The strengthened acceptance model remains intact: complete enumeration is required; sample-only verification fails; UNKNOWN is structurally distinct from OFF; incomplete coverage fails closed; mixed-mode and configured-intent/effective-mode divergence must be detectable; observation remains read-only and side-effect-free; OPS-02 behaviour is regression-pinned and not reopened.
Scope / CI / controls
Remediation delta from e8e8fb3a... to a24536e8... is exactly three documentation files and one commit. No runtime, schema, migration, Cargo, Dockerfile, workflow or infrastructure change exists.
Fresh exact-head CI is green. Actual job classification is:
PASS 4
SKIPPED 6
FAIL 0
PASS = check-changelog plus three classify jobs. The six runtime jobs were legitimately skipped by the documentation-only path classifier.
Control state remains unchanged:
THOTH-GQL-OPS-03 specification approval candidate
Implementation NOT AUTHORIZED / NOT IMPLEMENTED
Reserved implementation branch ABSENT
CL-1 OPEN
CG-13 OPEN
Runtime-operations gate NOT SATISFIED
Runbook PROVISIONAL
OBSERVE NOT AUTHORIZED
ENFORCE NOT AUTHORIZED
BE-02 runtime NOT AUTHORIZED
THOTH-GQL-OPS-04 NOT IMPLEMENTED
No deployment, runtime/configuration action, protected-source read, external evidence gathering, or activation occurred.
APPROVED for CTO specification approval consideration. This review is not implementation authorization, merge authorization, deployment authorization, or production activation authorization. PR #798 should remain DRAFT and UNMERGED until the CTO/control owner records the specification decision and separately authorizes any merge.
CTO / control-owner specification approval — THOTH-GQL-OPS-03I approve This approval covers the specification content at that exact head, including the section 3.2 information-disclosure boundary:
This is specification approval only. It does not authorize implementation, creation of the reserved implementation branch, merge of PR #798, deployment, configuration change, Fresh independent exact-head specification review has already returned |
CTO / control-owner merge authorization — THOTH-GQL-OPS-03-SPECI authorize the merge of PR #798 into This is merge authorization only and does not authorize implementation of This authorization is valid only while:
The approved section 3.2 boundary remains binding. Implementation authorization remains separate and absent. |
Terminal merge evidence — THOTH-GQL-OPS-03-SPECPR #798 was merged into The merge was executed with GitHub's expected-head SHA guard against This merge makes the approved THOTH-GQL-OPS-03 specification and its section 3.2 boundary repository-authoritative. It does not authorize or perform implementation of THOTH-GQL-OPS-03, creation of its reserved implementation branch, deployment, configuration changes, The PR changed documentation/control records only. Existing |
CTO / control-owner implementation authorization — THOTH-GQL-OPS-03I authorize implementation of This authorization is anchored to the repository-authoritative specification merged by PR #798 and to the current verified
The implementing task may create the reserved branch:
from that exact base, and may implement only the approved Binding limits remain:
If |
1 participant
Task identity
thoth-pub/thothTHOTH-GQL-OPS-03-SPECTHOTH-GQL-OPS-03— effective-mode fleet-verification mechanismdevelopd0f71ee10d3c3f3482fd76796f1ded31cbb2de8bThis pull request is specification-only. It reconciles and finalizes an
existing specification and resolves its one outstanding architecture decision. It
implements nothing, creates no implementation branch, changes no runtime,
GraphQL, schema, migration, workflow or infrastructure file, performs no
deployment or configuration action, and activates nothing.
Review status —
CHANGES REQUIREDremediatedIndependent exact-head specification review
4905511366returned
CHANGES REQUIREDat heade8e8fb3a, accepting the specificationdirection and the §3.2 boundary and requesting no redesign. It raised three
bounded documentation/evidence defects. All three are remediated on this same
branch and pull request:
BLOCKEDif no permitted mechanism satisfies section 3deployed production release = pre-guardis withdrawn from the preparation report's rollout state and from the identical inherited line in specification §11, replaced byNOT RE-ESTABLISHED BY THIS SPECIFICATION TASK. The OPS-01 pre-guard finding stays historical evidence owned by its own record and is used for no conclusionArchitecture decision: unchanged. Acceptance criteria: unchanged by the
remediation. Runtime/infrastructure effect: none. No Route A or Route B
evidence was gathered, and no protected source was read — none is required to fix
any of the three.
The remediated head requires fresh independent specification review; review
4905511366is discharged but is not an approval, and review of the previoushead does not carry forward.
Prerequisite:
THOTH-GQL-OPS-02is mergedVerified from GitHub and from the code at the base, not from narrative:
So capability gap 1 is closed and capability gap 2 remains open — exactly
what the reconciled specification states.
The §3.2 decision — unchanged by the remediation
A public unauthenticated surface is rejected, not deferred and not left as a
fallback — including in the case where no permitted mechanism turns out to
satisfy section 3, which is a
BLOCKEDstop rather than a licence to widen theboundary. Reopening the decision is reserved to the CTO.
The decision fixes the boundary, not the mechanism, and — after Finding 1 —
asserts nothing about whether a mechanism inside it exists.
Post-OPS-02 reconciliation
The specification predated OPS-02 and used the then-current
initdefect as itsworked example. That defect no longer exists, and no statement describes it as
current behaviour. The silent-adoption failure class survives the fix and is
stated generically — configured intent is not proof of process-effective mode —
with the verifier still required because intent is not proof, rolling replacement
produces mixed generations, unknown instances must stay unknown, future
regressions must be detectable, and sampling the shared load balancer can never
establish fleet consistency.
Acceptance criteria — strengthened, never weakened
Unchanged by the remediation; recorded here for completeness.
initdefectUNKNOWNmust be distinct fromOFFin the result shapeFiles changed
The review remediation touched exactly three of these: the specification, its
preparation report and the decision register.
Runtime code: 0 files. Migrations, generated SDL, Dockerfile, workflows,
Cargo: 0 files.Validation
Branches — specification vs implementation
Control state — unchanged by this pull request
No deployment, no deployment-workflow dispatch, no configuration change, no mode
set anywhere, no real environment or fleet accessed, and no read of the private
infrastructure repository or of any secret-bearing production configuration.
What this pull request asks for
This is an approval candidate, not an approval.
required — by a reviewer that did not author this work;
only the specification and its §3.2 boundary;
stays
Status: DRAFT/Implementation: NOT AUTHORIZED.Known deferral, surfaced rather than silently edited
The
THOTH-GQL-OPS-01deliverables — the runtime-operations control record(sections 4.3, 13.1) and the mode-transition runbook (section 0) — still carry
pre-OPS-02 language describing capability gap 1 as open. Both sit outside this
task's permitted paths, the control record is an evidence document with its own
authority condition, and
THOTH-GQL-OPS-04already owns re-establishing everyexternal fact and finalising the runbook. Whether an earlier bounded
reconciliation is wanted is the control owner's call. The OPS-03 specification
does not depend on that wording: it cites control-record section 4.3 explicitly
as historical.
Do not mark ready, approve or merge on the author's initiative.