# DeliveryAcceptance — plain-language explanation

Generated by the OSS Singularity contract lab for: **Synthetic delivery-and-acceptance example**.
Synthetic example: placeholder addresses, a digest over the public synthetic
artifact, a future deadline. The lab explains signatures; it never requests
one from a wallet, deploys anything, or holds funds.

## What this contract models

The same shape as the coordination protocol you already use off-chain: a
contributor delivers immutable revisions, the coordinator reviews, a revision
request records what is missing, and acceptance binds exactly the newest
revision before a deadline. On-chain deployment is NOT part of this slice.

## Every function and its requested signature

| Function | Signature you would be asked to sign | What it establishes | Who may call |
| --- | --- | --- | --- |
| `recordDelivery(uint16 revision)` | a call naming the next revision number | that the contributor recorded revision N referencing the declared digest | contributor only |
| `requestRevision(uint16 revision, string calldata note)` | a call naming a revision and a note | that the coordinator asked for changes on exactly that revision — no state is destroyed | coordinator only |
| `accept(uint16 revision)` | a call naming the newest revision | final acceptance of exactly that revision, before the deadline | coordinator only |

## What can fail, and how each failure is named

- `NotContributor` / `NotCoordinator` — role checks at the decision point: nobody reviews or delivers for someone else.
- `DuplicateRevision` — revisions only move forward, one at a time.
- `NothingDelivered` — reviews need a delivery first.
- `NotNewestRevision` — stale revisions are refused, not silently superseded (matched history is not a current delivery).
- `DeadlinePassed` — acceptance after the deadline is refused.
- `AlreadyAccepted` — acceptance is final; replay adds nothing.

## Honest boundaries

This contract holds no funds and defines no payment. A digest proves which
bytes were declared, not quality, authorship or availability. Deployment,
testnet exercise, or any wallet interaction requires separate, explicit
authorization — nothing here signs or deploys merely because it was generated.