What shipped
- A concise offer, qualification guide, source boundary, statement of work, delivery runbook, quality checklist, readout agenda, and demo storyboard
- Three outreach drafts held for approval and a three-slot demand tracker
- Eight allowlisted source samples paired with eight clearly labeled fictional client-safe samples
- Two file-hash manifests, an offline verifier, and mutation tests that confirm the package rejects unsafe or altered copies
Architecture
- The package wraps the original review process; it does not copy or fork the application.
- Commands against the parent review system were used only during authoring in disposable workspaces. The delivered package does not import, run, locate, or require that system.
- Only eight approved sample outputs were copied into the package. The client-safe versions preserve their meaning, add source hashes, and are clearly labeled as fictional.
source-manifest.jsonrecords sample lineage.pack-manifest.jsonrecords the required files and their hashes; it excludes only itself because a file cannot contain its own stable hash.- The verifier checks the expected inventory, file integrity, fixed service terms, safety boundaries, and each state in the demonstration. It uses independent expectations rather than treating either manifest as its only source of truth.
- Mutation tests work only on temporary copies. They confirm that missing, extra, altered, malformed, mislabeled, or unsafe content fails verification.
Limitations
The service evaluates only accepted supplied files and statements. File locations confirm where text appeared; file sizes and SHA-256 values confirm exact bytes. Neither establishes truth, authorship, authorization, sanitation, recency, accuracy, or completeness.
Reviewer details are recorded as provided; the package does not independently verify identity or authorization. An approved state means the clean candidate matches the recorded decision. It does not mean the reviewer’s identity was authenticated or that changes were deployed.
The sample is entirely fictional. It demonstrates review, hold, approval, and stale states, but it does not prove customer demand. The one-cent example shows that any change to a reviewed source requires another review; it is not presented as a material business error.
Verification
Run from the build root:
``bash bash verify.sh ``
Requirements are Bash and Python 3.11 or newer. No installation, environment variables, credentials, or network access are needed. The check works from a standalone copy and verifies:
- The complete artifact tree and both manifests
- The original and client-safe sample relationship
- All four states in the demonstration
- Fixed commercial terms and service boundaries
- Held outreach status and client-safety constraints
- Expected failures for tampered copies
**Status on 2026-09-03:** passing in the build root and a standalone temporary copy; all 12 mutation-test groups and the independent semantic verifier completed successfully.
Suggested next steps
Review the three held drafts and approve recipients separately if desired. Keep the fixed terms unchanged through three qualified offers:
- **Primary success:** one paid $750 pilot
- **Secondary evidence:** one usable authorized intake or two independent, qualified conversations that identify the same problem
- **Decision after three offers:** continue after payment, revise only around repeated actionable evidence, or pause
A separate $250 review may be tested only after a paying client explicitly requests a later source change. Do not build a subscription unless validated demand supports it.