Skip to content

Add an ALLOW verdict so the corpus can carry negative controls - #4

Open
laxsharma wants to merge 2 commits into
a2a-settlement:mainfrom
laxsharma:feat/allow-verdict-negative-controls
Open

Add an ALLOW verdict so the corpus can carry negative controls#4
laxsharma wants to merge 2 commits into
a2a-settlement:mainfrom
laxsharma:feat/allow-verdict-negative-controls

Conversation

@laxsharma

@laxsharma laxsharma commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Add an ALLOW verdict so the corpus can carry negative controls

Every v0 vector expects BLOCK or REVIEW, and both are satisfied by an
HTTP 4xx. A rail that rejected every request would therefore score 100
percent on the current corpus while being useless in production, and
nothing in the format lets a submission demonstrate otherwise.

For the gates these vectors exercise, dispute rate limiting, reputation
velocity, refund authorization, the false-positive rate is the dominant
product risk. It is the one property the corpus cannot currently measure.

Changes:

  • expected_verdict accepts ALLOW in the shape validator.
  • Mapping rule: ALLOW passes when the legitimate operation completes;
    blocking it, or holding it for review, is FAIL.
  • A "Negative controls" section in docs/vector-format.md with a
    candidate ALLOW case paired to each of the five existing vectors, for
    example a genuine second partial release on an escrow in
    partially_released as the counterpart to escrow_double_release.
  • Verdict semantics in the README updated to match.
  • Tests covering accepted and rejected verdict values, including
    lowercase and near-miss strings.

No vectors are added here, and no existing vector or result changes.
Signing is the blocker for contributing the vectors themselves:
harness/jws.py pins a single key, so anything not signed by
did:web:api.algovoi.co.uk fails CI. Happy to draft the ALLOW fixtures
for signing if that is the preferred order, or to work on multi-signer
support first if you would rather open contribution up.

Verified locally: pytest tests/ is 22 passed, and
python -m harness.validate_vectors --vectors vectors/v0 reports all 5
valid.

Co-Authored-By: Claude Fable 5 noreply@anthropic.com

All five v0 vectors are `BLOCK` or `REVIEW`, and `docs/vector-format.md`
makes both satisfiable by an HTTP 4xx. A rail that returns 400 to every
request therefore scores 100 percent, and the corpus has no way to say so.

That matters most for the gates these vectors actually test. For dispute
rate limiting and reputation velocity, the false positive is the real
product risk: an over-eager dispute gate is itself the liquidity-freeze
denial of service that motivated the dispute-DoS category in the first
place. Right now the corpus measures one side of the confusion matrix.

This adds the verdict and documents the pairing, without adding vectors:

- `validate_vector_shape` accepts `ALLOW`.
- README verdict table gains the row plus a note on why.
- `docs/vector-format.md` gains an `ALLOW` pass condition and a
  "Negative controls" section listing a concrete counterpart for each of
  the five current vectors, for example a legitimate second partial
  release within the remaining balance to pair with
  `escrow_double_release`.

No behaviour changes for existing vectors and no existing vector is
touched, so this is inert until someone lands `ALLOW` fixtures.

I would be glad to write those five fixtures, but I cannot sign them:
`harness/jws.py` pins one key, so any vector not signed by
`did:web:api.algovoi.co.uk` fails CI, and `docs/vector-format.md` already
notes contributors must "coordinate with maintainers for signing". If
there is appetite for a signer registry in `manifest.json` (a list rather
than a single `kid`, with the harness resolving `signer_did` per vector),
that would unblock this and any other outside contribution. Happy to send
that as a separate PR if it is wanted, or to hand the fixtures to
@chopmob-cloud for signing under the existing key, whichever fits better.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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