---
slug: udst-v1-1-attack-protocol
title: UDST: V1 1 Attack Protocol
canonical: https://miscsubjects.com/a/udst-v1-1-attack-protocol
---

# 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.


---

## Corpus map
- Previous: [UDST: V1 1 What Would Falsify It](/a/udst-v1-1-what-would-falsify-it)
- Next: [UDST: V1 1 Appendix A Compact Definitions](/a/udst-v1-1-appendix-a-compact-definitions)
- Series start: [UDST v1.1 — The Claim](/a/udst-v1-1-the-claim)
- Kin: [Book V — The Machine Plane](/a/oip-v3-book-v-the-machine-plane) · [Total Structure](/a/oip-total-structure)
