UDST: V1 1 Attack Protocol

An attack on this framework should do six things. Each step is implemented by a live endpoint in the build, so the attack is not a theoretical exercise but an operational procedure.

Engage the strongest version of the claim. State the claim back in its strongest form, with the qualifiers intact, before attacking. Attacking a weakened restatement is not engagement.

In the build, this is the ?why=1 endpoint: GET /api/dispatch?why=1&format=markdown returns the 18 objections, each with the strongest version of the claim and the verdict. Before attacking, read the objections. If your attack is already addressed, it is not engagement.

Name the tier. State which falsification surface the attack engages. The framework is designed so higher tiers can fail without collapsing lower tiers; an attack should know what it kills and what survives if it succeeds.

In the build, this is the conformance suite: GET /api/dispatch?conformance=1 returns 15 clauses, each a tier. An attack on C1 (manifest) does not collapse C14 (clarity recursion). Name the tier so the system knows what to test.

Name the exact claim. Quote the line. Identify the specific assertion. Diffuse criticism of the general orientation is not an attack.

In the build, this is the thread-state: GET /api/protocol/thread-state?target=B7 returns the accepted updates for the proof-hygiene branch, each with the exact claim, the source ledger event, and the settled answer. Quote the claim, not the vibe.

Classify the attack. Definition, logic, empirical, scope, category-error, implementation, prior-art, or falsifiability. Multiple types may apply; name them.

In the build, this is the materiality classifier: POST /api/protocol/thread-update classifies the raw turn into objection, settlement, patch, breakage, test_result, clarification, prior_art, open_question, or branch_update. If your attack is not one of these types, it is sludge, not material. The classifier will route it to the noise floor.

Show full-scope accounting. Where the attack is empirical, show the costs. Enforcement, externality, recurrence, suppressed capability, downstream instability, maintenance burden, audit debt. A counterexample that excludes a known cost is not a counterexample; it is a scope error.

In the build, this is the receipt: GET /api/dispatch?receipt=INV_ID returns the full request and response, including the story (one-line forensic narrative), the authorized_by (token provenance), and the result (the exact output). Show the receipt. If your attack has no receipt, it is not empirical. The ledger is the accounting.

Propose the minimum patch. If the attack succeeds, what is the smallest revision that lets the framework survive? An attack that does not specify the minimum patch is a demolition request, not engagement.

In the build, this is the repairs field: POST /api/dispatch {key:KEY, repairs:INV_ID, body:PATCH} creates a new invocation that repairs the previous one, with lineage in both directions. The minimum patch is not a rewrite; it is a single capability invocation that fixes the defect. The patch is ledgered, replayable, and audited. If your attack does not include a patch, the system will route it to the objection ledger as status: open and wait for the owner to settle it.

The framework's closure is structural, not protective. It can be refined by surviving patches. Refinement and refutation are different operations; the framework treats them differently. Refinement is welcome. Refutation requires the work above.

In the build, this is the oip_articles table: append-only versions, never UPDATE or DELETE. A refinement is a new version (v2, v3, v4) with the patch applied. A refutation is an objection that collapses the spine. The system does not protect itself from refinement; it welcomes it. The system does protect itself from demolition requests by requiring the six steps above. The distinction is the difference between a migration and a deletion.

---