# Directory publication review: worked and blank worksheet

All listings, owners, contacts, rules and events here are fictional. Reserved `.example` websites and `example.test` email addresses are setup data, not destinations or real businesses. This is a publication-policy answer key, not tested directory software. All actual app outcomes remain **Not tested**.

## Decide the policy before building

Keep listing lifecycle (active/withdrawn), identity review (clear/held), and revision decision (draft/submitted/approved/rejected) separate. Owners may create/submit revisions and withdraw their own listing. Only reviewer M01 can approve/reject or clear the identity hold in this example. These are proposed server rules, not proof that a UI enforces access.

Each revision has a fixed ID and immutable text. Only the latest submitted revision can receive a new approval/rejection; a newer draft alone does not displace it. Keep the last approved revision public while a newer one waits or is rejected. A rejection reason remains private. Withdrawal hides the entire listing even if another revision awaits review; this example has no restore action.

Public output contains only: `listing_id`, `revision_id`, `name`, `category`, `summary`, `website`. Private owner IDs/emails, revision notes, rejection reasons and identity notes never belong in that output. This synthetic download deliberately includes private seed fields to help you test the rule; the file itself provides no access control.

## Five starting listings

Every first revision starts as a draft, with no public listing. L04's repeated display name is held for an identity decision. A matching name alone never merges IDs.

| Listing | Owner | Fictional name | Identity | Private test email |
| --- | --- | --- | --- | --- |
| L01 | O01 | Cedar Print | clear | `owner01@example.test` |
| L02 | O02 | Moss Ceramics | clear | `owner02@example.test` |
| L03 | O03 | Quarry Frames | clear | `owner03@example.test` |
| L04 | O04 | Cedar Print | held | `owner04@example.test` |
| L05 | O05 | Fern Repairs | clear | `owner05@example.test` |

The [worked JSON dataset](/learn/resources/directory-publication-example.json) contains all eight immutable revision texts, the ordered event payloads and expected public revision IDs. Nothing in this link imports data into an app.

## Public record key

Only four revision texts ever reach an approved decision. This table is a lookup key, not a claim that all four appear at once. Each timeline row below identifies which approved records are public at that step.

| Revision | Listing | Name / category | Summary | Website |
| --- | --- | --- | --- | --- |
| L01-R1 | L01 | Cedar Print / Print | Small-run stationery. | `https://business01.example/` |
| L01-R3 | L01 | Cedar Print / Print | Stationery and invitation printing. | `https://business01.example/order` |
| L03-R1 | L03 | Quarry Frames / Frames | Custom picture frames. | `https://business03.example/` |
| L04-R1 | L04 | Cedar Print / Print | Hand-printed posters. | `https://business04.example/` |

## Complete action journal and expected public snapshots

Actions E01–E20 use November 2, 2026, 10:00–10:19 UTC in order. Attempts 21 and 22 reuse E20's original ID and timestamp: attempt 21 is an exact replay; attempt 22 changes its target to L02-R1. Review the exact payload in the JSON when reproducing these attempts.

| Attempt / ID | Proposed action | Expected result | Public revision IDs after attempt | Actual app outcome |
| --- | --- | --- | --- | --- |
| 1 / E01 | submit L01-R1 | applied | None | Not tested |
| 2 / E02 | approve L01-R1 | applied | L01-R1 | Not tested |
| 3 / E03 | submit L02-R1 | applied | L01-R1 | Not tested |
| 4 / E04 | submit L03-R1 | applied | L01-R1 | Not tested |
| 5 / E05 | approve L03-R1 | applied | L01-R1, L03-R1 | Not tested |
| 6 / E06 | create revision L01-R2 | applied | L01-R1, L03-R1 | Not tested |
| 7 / E07 | submit L01-R2 | applied | L01-R1, L03-R1 | Not tested |
| 8 / E08 | approve L01-R1 | stale_revision | L01-R1, L03-R1 | Not tested |
| 9 / E09 | reject L01-R2 | applied | L01-R1, L03-R1 | Not tested |
| 10 / E10 | create revision L01-R3 | applied | L01-R1, L03-R1 | Not tested |
| 11 / E11 | submit L01-R3 | applied | L01-R1, L03-R1 | Not tested |
| 12 / E12 | approve L01-R3 | applied | L01-R3, L03-R1 | Not tested |
| 13 / E13 | create revision L03-R2 | applied | L01-R3, L03-R1 | Not tested |
| 14 / E14 | submit L03-R2 | applied | L01-R3, L03-R1 | Not tested |
| 15 / E15 | withdraw L03 | applied | L01-R3 | Not tested |
| 16 / E16 | approve L03-R2 | listing_withdrawn | L01-R3 | Not tested |
| 17 / E17 | submit L04-R1 | applied | L01-R3 | Not tested |
| 18 / E18 | approve L04-R1 | identity_held | L01-R3 | Not tested |
| 19 / E19 | resolve identity L04 | applied | L01-R3 | Not tested |
| 20 / E20 | approve L04-R1 | applied | L01-R3, L04-R1 | Not tested |
| 21 / E20 | approve L04-R1 | duplicate_noop | L01-R3, L04-R1 | Not tested |
| 22 / E20 | approve L02-R1 | action_id_conflict | L01-R3, L04-R1 | Not tested |

After E07, the owner sees pending L01-R2, while visitors still see approved L01-R1. E08's new decision on L01-R1 is stale; it does not approve R2. E09 rejects R2 without hiding R1. The owner creates R3, submits it, and E12 approves that exact revision.

E15 withdraws L03 with R2 pending. E16 cannot undo that withdrawal. L04 stays held through E18; E19 records a fictional assumed-distinct identity decision, then E20 approves L04-R1. The two Cedar Print names remain separate records.

Exact accepted-action replay is a no-op. Conflicting reuse is `action_id_conflict`, left unresolved for the caller; it must not become a second approval. Invalid attempts make no business-state change and consume no accepted ID. Keep attempt/error receipts separately from accepted action IDs.

## Reconcile the end state

- Five listing IDs and eight revisions.
- Seventeen accepted action IDs, one exact replay and four rejected attempts across 22 rows.
- Four historical approved revisions, two submitted, one rejected and one draft.
- **Two public listings:** L01-R3 and L04-R1. L02 is awaiting first review; L03 is withdrawn; L05 was never submitted.

These counts describe the fictional key, not measured app behavior. Detail pages, directory lists, your own search and exports should agree on the approved public records and field allowlist. Test those surfaces separately. The policy does not erase copies someone already downloaded or guarantee third-party search removal.

## Blank review and observed-results card

Listing ID: ______  Owner: ______  Current approved revision: ______

Proposed revision ID: ______  Latest submitted revision ID: ______

Lifecycle / identity hold: ______  Reviewer: ______

| Field | Currently approved value | Proposed value | Approve / reject reason |
| --- | --- | --- | --- |
| Name | ______ | ______ | ______ |
| Category | ______ | ______ | ______ |
| Summary | ______ | ______ | ______ |
| Website | ______ | ______ | ______ |

Decision targets this exact revision: ______  Action ID: ______  UTC time: ______

| Surface / case | Expected public IDs and permitted fields | Actually observed | Pass / Fail / Not tested | Evidence / next owner |
| --- | --- | --- | --- | --- |
| Signed-out listing detail | ______ | ______ | Not tested | ______ |
| Directory list | ______ | ______ | Not tested | ______ |
| Own search results/snippets | ______ | ______ | Not tested | ______ |
| Public export | ______ | ______ | Not tested | ______ |
| Withdrawal plus stale approval | ______ | ______ | Not tested | ______ |
| Exact replay / conflicting ID | ______ | ______ | Not tested | ______ |

Choose a real expiry/cache policy and test fresh reads after withdrawal; do not equate the offline projection with cache invalidation. Test with two owners and a reviewer account you control. Record missing or blocked observations as Not tested; a performed violation fails.

## Starting build brief

Build a directory where visitors see only an active, identity-clear listing's explicitly approved revision. Owners may draft and submit immutable revisions for their own listing and withdraw it; owners cannot publish or edit others' listings. Reviewers decide the latest submitted revision by exact ID and record private reasons. Keep the last approved revision public while a newer one waits or is rejected. Withdrawal blocks later approval from republishing. Public output allows only listing_id, revision_id, name, category, summary and website; never owner emails or private notes. Keep duplicate names as separate IDs pending an explicit identity decision. Enforce permissions on the server. Replaying an accepted action ID with identical payload is a no-op; conflicting reuse must not change state. Begin without payments, reviews, bookings or messages. I will supply fictional setup and expected snapshots separately; the brief does not import them.

Use the [Overskill marketplace builder](https://www.overskill.com/build/marketplaces), paste and edit that brief, then review the build action and your account's requirements. This is a proposed app policy, not a built-in moderation guarantee. For a general briefing method, use [Write an AI app brief](https://www.overskill.com/learn/write-an-ai-app-brief).