Source identity
| Field | Recorded value |
|---|---|
| Source type | GitHub source |
| Original record | Janady13/missionmatch / docs/evidence/phase2/functional/document-trial-rehearsal.txt |
| Date | Not specified in source |
| Repository | Janady13/missionmatch |
| Revision | 720d47fae476b0d38477ae4401697d372b1ea2bc |
| Branch | feature/opportunity-to-outcome |
| Path or archive member | docs/evidence/phase2/functional/document-trial-rehearsal.txt |
| Original SHA-256 | eaf36931d934d886dcbad96bf04eb8eb2c495c2abc23141504503907c91c11d1 |
| Git blob SHA | 491add110ff0fbd0d5ac9613fb5325b31a816d69 |
| Reading-copy SHA-256 | eaf36931d934d886dcbad96bf04eb8eb2c495c2abc23141504503907c91c11d1 |
Recovered source transcript
Download complete source text ↓142 lines · 7.9 KB
PHASE 2 DOCUMENT TRIAL, REHEARSAL AGAINST A SYNTHETIC PACKAGE
28 July 2026. Target: missionmatch_staging. Everything used was invented: no real
notice, no real person, no real award. All of it was removed afterwards and the
removal was verified, 0 rehearsal rows remain.
WHY REHEARSE A CHECKLIST. docs/PHASE2_DOCUMENT_TRIAL.md is the thing that runs
the day the real package arrives, and until today nobody had ever executed it. A
checklist that has never been run is a plan, not a procedure. This rehearsal is
that checklist's own positive control: it exists to make the checklist fail while
failing is cheap.
IT FAILED IN FOUR PLACES. That is the result. The refusals it does prove are
listed after them, but the four defects are the point of the exercise.
================================================================================
CHECKLIST DEFECT 1, STEPS 1 AND 2 NAME MACHINERY THAT DOES NOT EXIST
================================================================================
Step 1 says "upload through the real intake path".
Step 2 says "run cmd/opportunity-extract, deterministic only".
There is no cmd/opportunity-extract. There is no upload handler. The tables
opportunity_documents and opportunity_document_chunks EXIST, are correct, and
carry provenance bound at origin, but the only Go file in the repository that
names either of them is internal/platform/scrub/binding_sites_test.go.
So the document path is SCHEMA WITHOUT CODE. Nothing writes an uploaded
document, and nothing chunks one.
This is not a surprise in the sense that the two deferred Phase 1 items are
exactly the upload screen and the attachment sync. It IS a surprise in the
checklist, which reads as though steps 1 and 2 are ready to execute and only
the file is missing. On the day, that reading would have cost an hour before
anyone realised the blocker is engineering and not paperwork.
================================================================================
CHECKLIST DEFECT 2, STEP 3 NORMALIZES METADATA, NOT A PERFORMANCE WORK STATEMENT
================================================================================
Step 3 reads as though the model pass consumes the uploaded PWS. It does not.
cmd/opportunity-scope-normalize joins tracked_opportunities to
sam_opportunities and composes its payload from NINE METADATA FIELDS: title,
department, sub agency, NAICS, PSC, set aside, notice type, and the place of
performance city and state. Verified by reading the query and by the byte
count of the composed payload at run time, 250 bytes.
A real PWS is tens of thousands of bytes of clauses. The normalizer has never
seen one and cannot, because nothing puts one in front of it.
CONSEQUENCE FOR THE TRIAL: the scope items it produces on the day will restate
the notice header, not the statement of work. In this rehearsal, from a notice
titled PACAF Cyber Systems Operations Support, it produced exactly one cited
item titled "PACAF Cyber Systems Operations Support". That is the honest
ceiling of the current pipeline and it should be said before the package
arrives, not discovered while Joseph is watching.
================================================================================
CHECKLIST DEFECT 3, THE COLUMN NAMES IN THE CHECKLIST ARE NOT THE SCHEMA
================================================================================
Four inserts written from the checklist's own vocabulary were rejected by the
database before any assertion could run:
sam_opportunities has no "description" column, and requires raw and poc
opportunity_documents has file_name, not filename
requirement_drafts has no "title", it has labor_category
requirement_drafts review_status is draft, in_review, approved, rejected,
and NOT "pending"
Small, and exactly the kind of thing that turns a twenty minute trial into an
afternoon. Corrected in the checklist.
================================================================================
CHECKLIST DEFECT 4, STEP 5 NAMES ONE CONSTRAINT AND THERE ARE TWO
================================================================================
Step 5 says promotion records the named human and the schema refuses an
approved draft with no reviewer. True, but incomplete. There are TWO
constraints and they fail in a fixed order:
ck_drafts_approved_has_requirement fires FIRST, because an approved draft
must carry approved_requirement_id
ck_drafts_decided_has_reviewer fires only once the first is satisfied
An operator asserting "no reviewer is refused" would see the FIRST error and
conclude the reviewer rule works without ever exercising it. Both are proven
separately below.
================================================================================
WHAT THE REHEARSAL DID PROVE, each with the refusal quoted
================================================================================
PROVENANCE IS BORN, NOT DECLARED. The synthetic notice was inserted with NO
provenance column supplied:
notice provenance BORN as: public_cache
PROVENANCE IS IMMUTABLE. An update straight at the column:
ERROR: provenance is immutable: public_cache cannot become tenant_upload
on table sam_opportunities
CONTEXT: PL/pgSQL function provenance_is_born_not_chosen()
A CALLER CANNOT LAUNDER A TENANT DOCUMENT. The insert DECLARED public_cache:
caller declared public_cache, row was born: tenant_upload
This is the single most important line in the rehearsal. It is the sharpening
Joseph asked for, proven against the real table rather than a fixture: the
egress decision derives from what the database says about where a row came
from, and a caller who lies about it is simply overwritten.
THE EGRESS GATE READ PROVENANCE FROM THE DATABASE AND ALLOWED A PUBLIC NOTICE:
egress allowed {"backend":"megamind-gateway","byte_count":250,
"content_sha256":"bf1161ce...","payload_class":"REQUIREMENT_NORMALIZE",
"provenance":["public_cache"]}
Then the LOCAL model produced one cited item, and the run wrote nothing
because it was a dry run.
AN UNCITED SCOPE ITEM IS REFUSED:
ERROR: new row for relation "opportunity_scope_items" violates check
constraint "ck_scope_items_cited"
AN APPROVED DRAFT WITHOUT ITS REQUIREMENT IS REFUSED:
ERROR: violates check constraint "ck_drafts_approved_has_requirement"
AN APPROVED DRAFT WITH A REQUIREMENT BUT NO NAMED HUMAN IS REFUSED:
ERROR: violates check constraint "ck_drafts_decided_has_reviewer"
POSITIVE CONTROL ON THOSE TWO REFUSALS, because a table that refused
everything would produce the same evidence:
draft accepted, review_status=draft, reviewer=none
THE AMENDMENT DOES NOT REACH THE REVIEWED WORK. The notice was rewritten
underneath a reviewed scope item, title changed and deadline moved:
notice amended to: PACAF Cyber Systems Operations Support, AMENDMENT 0001
the reviewed scope item is UNCHANGED: PACAF Cyber Systems Operations
Support (hash a1b2c3d4)
and its provenance is STILL: tenant_record
================================================================================
WHAT THIS CHANGES ABOUT THE DAY THE PACKAGE ARRIVES
================================================================================
The package is STILL the one blocker for the parts of Gate A that only a real
document can close. It is no longer the only thing standing between here and
steps 1 and 2, and pretending otherwise was the checklist's biggest defect.
On the day, steps 3 through 6 run as written and prove what is listed above on
real notice metadata. Steps 1, 2, and 7 need the deferred Phase 1 engineering
first: the upload screen, the extraction binary, and the attachment sync. Those
were deferred on documents existing. The rehearsal shows the sequencing is the
other way around for two of them: the code has to exist before the document can
be useful to it.