Require evidence-bearing proof kernels in unsafe Rust V5 - #3536
Conversation
Revise the runtime skill around the root cause of the V4 failures: agents must not silently promote visible Rust syntax or artifact text into the semantic proposition needed by an unsafe-code proof. Require every load-bearing premise to state its exact proposition, provenance, applicability domain, and downstream consumer. Distinguish directly observed artifact facts from claims about Rust execution, typing, arithmetic, control flow, library behavior, or caller obligations; the latter must follow from applicable authoritative text, an explicit admitted TCB premise, or a checked derivation. Verify that cited text entails the proposition in the direction the proof uses it rather than merely mentioning related concepts. Add a valid-use certificate that identifies why the counterexample or proof case is admitted at each safe API boundary. Track root blockers separately from the atoms that depend on them so one missing semantic bridge cannot be hidden by many repeated conclusions. When an auditor must reconstruct a proof that the code comment does not contain, require the report to expose that reconstructed proof for maintainer review instead of silently accepting the site. Keep the existing exact-domain, set-relation, staged-construction, whole-execution, verdict-certificate, local-invariant, and abstraction-design discipline. Express the new requirements as a compact evidence-bearing proof kernel, not as a list of syntax forms or evaluated fixtures. gherrit-pr-id: Gj24u57i5qq6wbmrnwypu7cy7dupt2mt3
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 552516db54
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| implementer obligation owned outside the audited scope—including an | ||
| obligation imposed on caller or implementer code supplied by the witness—is | ||
| satisfied. No prose-only condition is imposed on a safe boundary. Do not |
There was a problem hiding this comment.
Keep audited API preconditions in the valid-use domain
When the audited scope includes an unsafe API, this instruction permits its boundary assertion to be left false even when that assertion is a documented caller precondition. For example, an out-of-range call to an audited get_unchecked-style API could then be certified as a valid witness and its expected UB reported as UNSOUND, contradicting SKILL.md's definition that valid uses of unsafe APIs satisfy all documented safety obligations. Distinguish caller preconditions—which must be satisfied regardless of where their contract is declared—from implementation or impl assertions that the audit is testing.
Useful? React with 👍 / 👎.
Revise the runtime skill around the root cause of the V4 failures: agents must
not silently promote visible Rust syntax or artifact text into the semantic
proposition needed by an unsafe-code proof.
Require every load-bearing premise to state its exact proposition, provenance,
applicability domain, and downstream consumer. Distinguish directly observed
artifact facts from claims about Rust execution, typing, arithmetic, control
flow, library behavior, or caller obligations; the latter must follow from
applicable authoritative text, an explicit admitted TCB premise, or a checked
derivation. Verify that cited text entails the proposition in the direction the
proof uses it rather than merely mentioning related concepts.
Add a valid-use certificate that identifies why the counterexample or proof
case is admitted at each safe API boundary. Track root blockers separately from
the atoms that depend on them so one missing semantic bridge cannot be hidden by
many repeated conclusions. When an auditor must reconstruct a proof that the
code comment does not contain, require the report to expose that reconstructed
proof for maintainer review instead of silently accepting the site.
Keep the existing exact-domain, set-relation, staged-construction,
whole-execution, verdict-certificate, local-invariant, and abstraction-design
discipline. Express the new requirements as a compact evidence-bearing proof
kernel, not as a list of syntax forms or evaluated fixtures.
Latest Update: v2 — Compare vs v1
📚 Full Patch History
Links show the diff between the row version and the column version.
⬇️ Download this PR
Branch
git fetch origin refs/heads/Gj24u57i5qq6wbmrnwypu7cy7dupt2mt3 && git checkout -b pr-Gj24u57i5qq6wbmrnwypu7cy7dupt2mt3 FETCH_HEADCheckout
git fetch origin refs/heads/Gj24u57i5qq6wbmrnwypu7cy7dupt2mt3 && git checkout FETCH_HEADCherry Pick
git fetch origin refs/heads/Gj24u57i5qq6wbmrnwypu7cy7dupt2mt3 && git cherry-pick FETCH_HEADPull
Stacked PRs enabled by GHerrit.