# missionMATCH BUILD_STATE

================================================================================
STANDING REFERENCE. The CURRENT handoff is the SESSION HANDOFF section below.
================================================================================

THE TOP OF THIS FILE USED TO CARRY A SECOND, OLDER HANDOFF and it went stale: it still said Gate
C fails and Gate A waits on one blocker, both of which were superseded the same day. Two handoffs
in one ledger is one handoff too many, and the stale one is the one a fresh session reads first.
Removed 29 July 2026. What remains here is DURABLE reference that does not change per session.

PRODUCTION IS TWO DATABASES. Reading this wrong caused an outage.
  CONTROL PLANE, authoritative identity, what MM_DATABASE_URL points at:
    missionmatch on megamind-agi 100.77.114.40 PORT 5433, v80.
    ANSWER EVERY IDENTITY QUESTION HERE.
  TENANT DATA PLANE, only via tenant_directory:
    missionmatch on M4 100.94.8.94 port 5432, v80. Its users copy is NON
    AUTHORITATIVE; an hourly sync keeps it honest.
  STAGING: missionmatch_staging on M4 5432, v81, served by mm-api-staging on
    Bubbles 127.0.0.1:8097, vhost missionmatch-staging.thatwebhostingguy.com.
    STAGING IS ONE AHEAD ON PURPOSE: 0081 is staging only pending a deploy.
  Both production nodes run 8f24414531e80a9a. Bundle index-BE5iWWvj.js.

ACCESS, all verified this session
  Bubbles      ssh user@100.90.97.104        pw user, sudo via echo user | sudo -S
  M4           ssh joseph@100.94.8.94        psql /opt/homebrew/bin/psql,
                                             local trust as -U postgres
  megamind-agi NO direct SSH. ssh -o PubkeyAuthentication=no
               -o PreferredAuthentications=password josep@100.69.120.61, then
               scp a script and run: wsl -- bash /mnt/c/Users/josep/<script>.sh
               MULTI LINE QUOTING THROUGH wsl BREAKS. Always stage a file.
               PASSWORD REDACTED 28 July 2026, finding D4. It is in the secrets
               store, never here. See the standing rule below.
  psql locally /opt/homebrew/opt/libpq/bin/psql, not on PATH by default.
  Staging test accounts: patriciacox6@aol.com and desk.admin@fg-talent.test.
               PASSWORDS REDACTED 28 July 2026, finding D4, and both were
               ROTATED before redaction because they were already burned. The
               replacements are in the secrets store. Redacting without rotating
               would have been theatre: the old values are in git history and in
               a chat transcript, and a redaction does not un publish them.

HOW TO DEPLOY, and why production is not repository HEAD
  HEAD carries Phase 1 and 2 build features that stay DARK until Gate 6. Build in
  a worktree at e74fd2e, overlay ONLY the approved track's files, hand resolve
  cmd/api/main.go, take AppShell.tsx from the BASELINE, then GREP THE ARTIFACTS.
  Both nodes get the identical binary or failover serves two answers.
  Frontend: rewrite ONLY the two asset hashes; the line count must not change.
  Env files: sudo tee TRUNCATES. Stage to /tmp then cp.
  Post deploy: re prove build routes dark on the UNAUTHENTICATED AND the
  AUTHENTICATED leg. An unauthenticated only sweep cannot see a defect behind the
  session gate, which is how a 500 was missed.

THE INSTRUMENTS, all new this session, all with positive controls
  tools/verify/stress          race, load, soak. -control plants a defect and the
                               profile MUST fail on it before a counted run.
  tools/verify/visual-sweep    logs in as real roles, 5 viewports, contact sheet.
                               --control plants a 4000px overflow.
  /usr/local/sbin/mm-restore-drill.sh   run at EVERY phase close.
  Timers: 02:45 cp backup, 03:05 db backup, 5min watch, hourly identity sync.

CANDIDATE INTAKE, WHAT EXISTS AND THE ONE DECISION IT NEEDS, 30 July 2026. Joseph asked for candidate import
that also PULLS FROM DATABASES rather than only ingesting files. Researched before building; most of it exists.

WHAT IS ALREADY BUILT, and it is more than expected
  connector.Connector is an interface: Name() and FetchPage(ctx, since, page) returning people, a next page
    cursor, and the max updated timestamp seen.
  connector.Sync is a REAL INCREMENTAL SYNC FRAMEWORK, not a stub. It reads the org's watermark from
    connector_sync_state, pages from it, ingests each page through the proven sourcing path with a
    sourcing_log provenance row, and advances the watermark PER PAGE in one atomic transaction. Network I/O
    runs OUTSIDE the transaction so a slow fetch never holds one open. A 429 maps to ErrThrottled and stops
    the run gracefully, keeping the pages already committed. No PII is logged.
  benchimport carries a FileSource interface with TWO implementations already: a resume source that extracts
    from documents, and a structured source for tabular records.
  ONE CONNECTOR EXISTS: iCIMS, an applicant tracking system.

SO THE GAP IS NOT THE MACHINERY. It is two things: no HTTP route reaches any of it, and there is no second
source to pull from.

THE DECISION, AND IT IS A SECURITY DECISION RATHER THAN A DESIGN PREFERENCE.
  iCIMS credentials come from PROCESS ENVIRONMENT VARIABLES: ICIMS_CUSTOMER_ID, ICIMS_CLIENT_ID,
  ICIMS_CLIENT_SECRET. That means ONE DEPLOYMENT CAN SERVE EXACTLY ONE iCIMS ACCOUNT. It works for a single
  pilot tenant and it cannot serve customers, because the second customer's credentials have nowhere to live.
  connector_sync_state holds watermarks, not configuration and not secrets.

  PULLING FROM A CUSTOMER'S DATABASE MAKES THIS SHARPER, not softer. A database source needs a DSN, which is a
  live credential to a system this platform does not own, stored per tenant. Three sub questions come with it
  and each is a real exposure rather than a detail:
    WHERE THE SECRET LIVES. The precedent in this codebase is good and should be followed: TOTP secrets are
      AES 256 GCM encrypted at rest with a key_version so the KEK can rotate. A connector_configs table with
      the same shape is the honest answer, not a plaintext column and not an env var.
    WHAT THE CONNECTION MAY REACH. An operator supplied DSN is a request the SERVER makes to an arbitrary
      host, which is server side request forgery with a friendly name. It needs an explicit egress posture:
      an allowlist, or at minimum a refusal of loopback and private ranges, decided deliberately rather than
      inherited by accident.
    WHAT THE QUERY MAY DO. A customer supplied query must run READ ONLY with a statement timeout, in a
      transaction that cannot write, because "SELECT the candidates" and "DROP the candidates" differ by one
      word in a text box.

  THE OPTIONS, stated as a choice rather than a recommendation dressed as a finding:
    A. Per org connector_configs with AES 256 GCM at rest, mirroring the TOTP pattern. Multi tenant, and the
       most work.
    B. Keep credentials in the environment and support ONE source per deployment. Cheapest, and it cannot
       onboard a second customer onto the same connector.
    C. Resolve credentials through the existing secrets.Resolver backend abstraction, which already has a
       cache and a pluggable backend, so a cloud secret manager becomes configuration rather than code.
  I recommend A for the database and ATS sources, with C as the deployment time option for platform wide
  credentials. B is what exists and it does not survive a second customer.

WHAT CAN BE BUILT WITHOUT THAT DECISION, and should be, because it needs no new credential surface at all:
  A STRUCTURED CANDIDATE IMPORT ROUTE. benchimport's structured source already parses tabular records into
  BenchRecord and ToSourcedPerson feeds the same proven ingest path connector.Sync uses. An upload that
  STREAMS and parses in memory needs no object storage, which matters because MM_STORAGE_ROOT is unset in
  production and document intake is therefore dark. So a customer could load a bench today, from the product,
  with no new secret anywhere.
  RESUME upload is the half that DOES need storage, and it is blocked behind the same disk decision as
  document intake, on a root disk at 82 percent whose backups share it.

NOTHING WAS BUILT FOR THIS YET. Recorded so the decision is made deliberately rather than discovered halfway
through a connector that is already holding a customer's database password. | this commit | 2026-07-30

PHASE 3 WORK PLAN, RESEARCHED PER ITEM, 30 July 2026. Joseph asked for each numbered item researched for what
it actually needs, then the list worked down, then a full application test round. Every "exists" or "absent"
below is a query result or a grep, not a recollection.

ITEM 1, PROPOSAL MIGRATIONS. DONE. Migration 0086 in all three databases at v86: 11 tables, 11 forced RLS, 6
  slate lifecycle columns, composite tenant keys throughout, no DELETE grants, the approved_count invariant in
  the schema, and mm_mirror_staging_role_privileges() so the 0085 class of gap cannot recur.

ITEM 3, THE READINESS ENGINE. NEXT, and first because everything downstream reads it.
  internal/modules/proposals/engine, pure Go, injected inputs, no database, no I/O, READINESS_ALGO_VERSION.
  Weights 0.30 staffing coverage, 0.25 compliance matrix, 0.20 required sections, 0.10 review and approval,
  0.10 schedule health, 0.05 risk posture. Sums to 1.00, asserted by a test rather than by arithmetic in a
  comment.
  EIGHT HARD BLOCKERS, from Section 7: customer deadline passed, required compliance item open, required
  section missing, required staffing quantity uncovered, final approval missing, unreviewed amendment affecting
  scope, required attachment missing, submission validation failed.
  DETERMINISM IS THE GATE CLAUSE AND IT HAS THREE KNOWN FAILURE MODES, all quiet: a float64 arriving through
  JSON unmarshalling into interface{}, GO'S RANDOMISED MAP ITERATION anywhere in the scoring path, and
  unstable tie breaking when two drivers score equal. Mitigations are decided in advance: decimal everywhere,
  NO map iteration feeds a score (inputs arrive as slices and any map is sorted before use), and every ordering
  carries a total order tiebreaker. A test runs the same input 100 times and asserts byte identical output.
  It shares NOT ONE LINE with the candidate engine, per Section 7, while mirroring its cap philosophy.

ITEM 7, THE SLATE APPROVAL LIFECYCLE AND THE EIGHT WAY RACE. Second, because it is the hardest thing in the
  phase and a concurrency design validated last is validated by hope.
  Schema is ready. What remains is the transaction: approve and withdraw each take FOR UPDATE on the member
  row, adjust proposal_staffing_links.approved_count, and audit through OnTx.
  THE REAL DIFFICULTY IS LOCK ORDERING, not the counter. Eight transactions touching a member row AND the
  links row deadlock unless they always acquire in the same order. Decision: ALWAYS the links row first, then
  the member row, because the links row is the contended one and taking it first serialises the counter update
  without holding a member lock while waiting.
  The harness runs eight concurrent workers doing approve, withdraw and re approve, then asserts the final
  count. The schema CHECK turns any lost update into an error rather than a flattering number.

ITEM 5, SUBMISSION WITH SERVER SIDE HARD BLOCKER ENFORCEMENT. The check lives in the SERVICE, never the
  handler, so a future route cannot bypass it, and a test asserts no submission path skips it. Gate 3 is
  explicit that the API refuses, not merely the UI.

ITEM 8 AND 9, PRICING AND RECORDED WAGE FLOORS, from the 30 July amendment. A pure margin function on decimal:
  bill minus pay minus burden. AN UNBURDENED LINE RETURNS NO MARGIN AT ALL, which is gate clause A, and the
  API omits the field with a stated reason rather than sending a spread that reads as margin. A line priced
  below its recorded floor is a hard blocker, which folds pricing into item 5 rather than beside it.

ITEM 6, OUTCOME RECORDING THROUGH bidoutcomes. The module EXISTS, 477 lines with a Routes function, and
  MM_BID_OUTCOMES_ENABLED is UNSET in both environments so the recording routes are not mounted and the ledger
  ships dormant. This item is mostly wiring plus the flag, not new machinery.

ITEM 4, THE TWO COMMANDS. cmd/proposal-readiness-snapshot for scheduled persistence and
  cmd/proposal-deadline-alerts sweeping deadlines into alerts, plus cmd/stale-requirement-scan. The alerts
  module EXISTS at 930 lines, so deadline alerts extend it. Every binary follows the sam-sync pattern:
  idempotent, bounded, observable, audited, provenance aware, safe to rerun.

ITEM 2, THE WORKSPACE TABS, Section 6. TEN tabs: Overview, Scope, Requirements, Compliance Matrix, Sections,
  Staffing, Milestones, Risks, Attachments, Activity. Overview alone carries opportunity summary, both
  deadlines, owners, stage, readiness, hard blockers, scope changes, staffing coverage, compliance completion,
  section completion, review milestones, risks and recent activity. Every tile clickable through to its
  filtered list. Reuse AppShell, ToolGuard, lib/queries. Activity is fed from the append only audit trail.
  LAST, deliberately: a tab that renders a number the engine has not settled is a tab built twice.

ROUTES, Section 9: POST /api/proposals, GET and PATCH /api/proposals/{id}, GET /{id}/readiness,
  POST /{id}/readiness/snapshot, POST /{id}/submit, POST /{id}/outcome, plus CRUD for sections, compliance
  items, milestones, risks, staffing links and attachments.
CAPABILITIES: proposal.manage at recruiter and above, proposal.submit at manager and above. The other 22
  exist; these two do not and the exhaustively tested matrix must be updated with them.

EVERYTHING IS BUILT IN PRODUCTION per the rail amendment, with rollback before each change, artifacts hash
verified after transit, and controls run before conclusions. | this commit | 2026-07-30

RECORDED SCOPE AMENDMENT, PHASE 3 GAINS PRICING, AND GATE 3 GAINS FOUR CLAUSES. 30 July 2026, Joseph's
decision after he challenged my claim that the gate was the obstacle. He was right and the claim was wrong: the
gate is a specification we write, not a constraint we inherit, so a phase that gains scope gains gate clauses.

PHASE 3 IS NOW: PROPOSAL OPERATIONS, INCLUDING PRICING. The directive's seven items stand unchanged, plus:

  8. PROPOSAL PRICING. A staffing line on a proposal carries a labor category, a pay rate, a BURDEN, and a bill
     rate. Margin is COMPUTED, never stored, by a pure function on shopspring/decimal, because a stored margin
     drifts from its inputs and the whole point is that the number can be re derived.
  9. RECORDED WAGE FLOORS. A table of wage determination floors per labor category and locality, entered by a
     named human with the determination number, revision, and effective date. NOT extracted from the document,
     and the reason is finding one: the SCA wage determination's text layer carries no usable character map, so
     the floor cannot be read from it and OCR is deferred as candidate P2. A floor a human recorded is honest.
     A floor guessed from an unreadable PDF would not be.

GATE 3 GAINS FOUR CLAUSES, and they are written to slot into the gate rather than sit beside it:

  A. A BILL RATE WITH NO BURDEN PRODUCES NO MARGIN AT ALL. Not a spread labelled as margin, not a zero, not a
     null quietly rendered as a dash. The API refuses to return a margin field for an unburdened line and says
     why. This is tonight's most expensive lesson made into a gate clause: the product could show bill minus
     pay and call it margin, and that number would be wrong in the direction that loses money.
  B. THE SAME INPUTS PRODUCE BIT IDENTICAL MARGIN ACROSS RUNS, decimal throughout, no float64 anywhere in the
     path, proven the same way readiness is proven.
  C. A STAFFING LINE PRICED BELOW ITS RECORDED WAGE FLOOR IS A HARD BLOCKER ON SUBMISSION, ENFORCED SERVER
     SIDE. This is why pricing belongs in this phase rather than beside it: it does not extend the gate, it
     makes the gate's central clause mean more. An underpriced SCA position is exactly the class of thing that
     must stop a submission at the API and not merely grey out a button.
  D. WRAP RATE RESOLUTION IS RECORDED ON THE PRICED LINE with its source and version, so a margin can be re
     derived months later and an assessor can see which burden assumption produced which bill rate.

WHAT IS DELIBERATELY NOT IN THIS PHASE, so the amendment does not become a bucket the way my three misfilings
did:
  THE WAGE BRIDGE, D22, STAYS OUT. Canonical SOC form, ontology_crosswalk, and skills.soc_code are MARKET
  COMPARISON data. Phase 3 needs a floor a human recorded, not a market band, and dragging a bridge that is
  broken in three ways into a phase that does not need it is how a phase stops closing.
  THE SELF EXTENDING KNOWLEDGE STORE STAYS OUT. Unphased and visible.
  OCR STAYS OUT. Candidate P2, and clause C is written to not need it.

THE HARD PARTS, NAMED IN ADVANCE so the plan is honest about where the time goes. Only two of the gate's
clauses are genuinely difficult and neither is pricing:
  THE EIGHT WAY RACE ON approved_count. The count moves both up AND down, since withdrawal decrements and re
  approval after withdrawal is allowed, so a member can cycle. The difficulty is not the counter, it is LOCK
  ORDERING: eight transactions each taking FOR UPDATE on a member row and touching proposal_staffing_links will
  deadlock unless they always acquire in the same order. And the gate says PROVEN BY RACING IT, so a harness
  that runs eight concurrent workers and asserts the final count, not an argument that the code reads correctly.
  I am building that harness FIRST, not last, because a concurrency design validated at the end is a
  concurrency design validated by hope.
  BIT IDENTICAL READINESS. Three ways it breaks and all three are quiet: a float64 arriving through JSON
  unmarshalling into interface{}, GO'S RANDOMISED MAP ITERATION anywhere in the scoring path, and unstable tie
  breaking when two drivers score equal. The frozen engine already solved this with decimal and total order
  tiebreakers; readiness has MORE inputs and must inherit the same discipline.

EVERYTHING IS BUILT IN PRODUCTION, per the rail amendment recorded above this entry. No side builds, no
sandbox. Rollback before each change, artifacts hash verified after transit, controls run before conclusions.
| this commit | 2026-07-30

CORRECTION, I ENLARGED PHASE 3 THREE TIMES WITHOUT CHECKING WHAT PHASE 3 IS, 30 July 2026. Found while
preparing the Phase 3 breakdown Joseph asked for.

THE DIRECTIVE'S PHASE 3 IS "PROPOSAL OPERATIONS", Section at line 550, and it is seven numbered items with its
own Gate 3: proposal migrations from Section 3.7, the workspace tabs from Section 6, the readiness engine from
Section 7 with snapshots and cmd/proposal-readiness-snapshot, cmd/proposal-deadline-alerts and
cmd/stale-requirement-scan, a submission workflow with SERVER SIDE hard blocker enforcement, outcome recording
through bidoutcomes, and the slate approval lifecycle merged from consolidated amendment 2.3.

I RECORDED THREE THINGS AS "PHASE 3 SCOPED WORK" TONIGHT AND NOT ONE OF THEM IS IN IT:
  the wrap rate and burden model
  the wage bridge, D22
  the self extending knowledge store
Each entry reasoned carefully about why the item did not belong in PHASE 2, which was correct, and then
assigned it to Phase 3 as though Phase 3 were a bucket for whatever is next. I never opened the directive to
check. THAT IS THE EXACT DRIFT THIS PROTOCOL EXISTS TO PREVENT, and I spent the night enforcing it on
everything else while doing it myself three times in the ledger.

WHAT IS ACTUALLY TRUE ABOUT THOSE THREE ITEMS: they are real, they are recorded with measurements, and they
have no phase. Saying they have no phase is more useful than assigning them one, because an unphased item is
visible while a misfiled one is not.

THE ONE THING THAT WAS CORRECTLY ASSIGNED: the office format reader holds Phase 3's single IMPROVEMENT slot,
which is the licensed channel for one unscoped item per phase, and that is what an improvement slot is for.
The other three are not improvements, they are scope, and scope needs a recorded amendment rather than a slot.

WHAT NEEDS JOSEPH'S DECISION, stated as a choice rather than a recommendation dressed as a finding:
  A. Run Phase 3 as the directive defines it. The three items wait, unphased and visible.
  B. Amend Phase 3 to include the wrap rate, on the argument that proposal operations without pricing is half a
     proposal. That is a defensible reading and it is an AMENDMENT, recorded as one, not an assumption.
  C. Insert a phase before Phase 3 for the money and knowledge substrate.
I recommend A or B and I lean B only if he wants proposal pricing in this phase, because Gate 3 as written does
not test pricing at all and a phase whose gate cannot see half its scope is a phase that closes on partial
evidence. | this commit | 2026-07-30

RECORDED DECISION, THE PRODUCTION RAIL IS AMENDED, 30 July 2026. Joseph: "push it into production. do not
build something outside production again it doubles the work."

WHAT CHANGED. The standing rail read "production scope closed outside recorded approvals", and the phase
protocol built and proved everything in staging while production stayed deliberately untouched. That is now
amended: BUILD IN PRODUCTION. The doubling he is describing is real and I should have named it first. Phase 2
was built and gated entirely against staging, then had to be deployed and re verified in production afterwards,
which meant every artifact was staged twice, every credential path exercised twice, and the Gate C fixture
accounts existed only on one side. Tonight's deploy also proved the two environments are NOT equivalent: the
staging role parity defect in migration 0085 existed precisely because staging has its own roles that no
migration names.

WHAT DOES NOT CHANGE, and this is not hedging, it is the part that makes the amendment safe:
  ROLLBACK BEFORE THE FIRST CHANGE. A copy of every artifact, and a database dump on disk, before anything is
  touched. Tonight that path was used twice and it worked twice.
  AN ARTIFACT IS HASH VERIFIED AFTER TRANSIT AND BEFORE A SERVICE START. Tonight a binary was corrupted in
  transit and segfaulted production's second node. The assertion now refuses a mismatch outright, because care
  is not a control and a hash is.
  HEALTH IS CHECKED AND THE CHECK IS CHECKED. A bad health URL caused a false rollback tonight. A rollback
  fired by a broken check is cheap; a deploy passed by a broken check is not.
  CONTROLS STILL RUN FIRST. The post deploy verification asserts that routes which SHOULD answer do answer,
  before concluding anything from a route that does not.
  THE ENGINE STAYS FROZEN, RLS STAYS FORCED, PROVENANCE STAYS BORN AT ORIGIN, AND MIGRATIONS REMAIN THE ONLY
  WAY TO CHANGE SCHEMA. Building in production changes WHERE work is proven, not what is permitted.

THE HONEST COST OF THE AMENDMENT, stated once so it is not rediscovered as a surprise. Building in production
means a defect's first audience can be a customer rather than a gate. The phase protocol's staging first order
existed to buy exactly that separation, and giving it up trades a slower build for a faster one with a shorter
blast radius between a mistake and a user. Joseph owns that trade and has made it. The mitigation is the list
above, and the one thing I will keep insisting on is that a production change still carries its rollback and
its controls, because those are what make a fast deploy survivable rather than merely fast. | this commit | 2026-07-30

## PER ORGANIZATION SETTINGS, SEALED SECRETS, FIELD SENSITIVITY AND WORK VISIBILITY, 30 July 2026

Migration 0087 is live in ALL THREE databases at v87, verified per database rather than summarized: control
plane 100.77.114.40:5433, tenant 100.94.8.94:5432, staging missionmatch_staging. Four new tables each with
FORCE ROW LEVEL SECURITY, four policies, and ZERO policies naming a role, which is the 0085 and 0086 lesson
held. Backfill covered every organization: 1 of 1 on each production database, 4855 of 4855 on staging.
Staging app grants mirrored 13 of 13 against the production app role, and the positive control confirmed the
staging app role still has NO CONNECT to the production database.

WHAT IT ANSWERS. Three asks landed on one missing thing, a place where a tenant states how it works and a
place where it stores a password. Invites had to be hand delivered, recruiters were double working the same
candidate, and rates were visible to everyone.

DECISIONS RECORDED.
- Secrets are AES 256 GCM under MM_ORG_SECRET_KEK with a key_version, MIRRORING the mfa_totp pattern from
  migration 0009 rather than inventing a second meaning for encrypted at rest. A SEPARATE key from the TOTP
  KEK, because one key covering both populations means one disclosure covers both.
- BOTH PRODUCTION NODES HOLD THE IDENTICAL KEY, proven by comparing hashes of the value, never the value. A
  secret sealed on one node must open on the other. STAGING HOLDS A DIFFERENT KEY, proven to differ, so a
  staging disclosure is not a production disclosure.
- Mail sends through the CUSTOMER'S OWN server from the CUSTOMER'S OWN address, so an invitation passes their
  SPF and DKIM and does not arrive from a domain their staff was trained to distrust.
- WHEN DELIVERY SUCCEEDS THE TOKEN IS WITHHELD from the response. It has reached the intended person; a
  second copy in an administrator's browser is a live credential with no purpose.
- IT DEGRADES TO THE PILOT BEHAVIOUR ALWAYS. No mail configured, or a mail server that refuses, returns the
  one time link exactly as before. A mail outage never costs an account creation.
- There is NO CLEARTEXT MAIL OPTION at any port. What this transport carries is an activation credential and
  a person's name.
- The test endpoint sends ONLY to the administrator's own address. One that accepted a recipient would be an
  open relay wearing a settings screen.
- Settings MAY NOT WEAKEN A COMPLIANCE GUARANTEE, which is why the table is typed columns and not a key value
  bag. Human approval of every slate member, adverse impact reporting, the audit trail and the fixed NIST
  session timeouts are NOT settings and must never be added here.
- Defaults are the INDUSTRY ones: rates at managers, margin at owner, contacts at team, work visibility at
  organization so the double work control ships ON.

THE SERVER SIDE REQUEST FORGERY BOUND, because a customer supplying a mail host is asking this server to
connect somewhere. The destination is resolved and checked and then the CHECKED ADDRESS is dialled, not the
name, which closes the rebinding window. Loopback, private ranges, link local, the cloud metadata address,
carrier grade NAT where this operator's own machines live, and IPv6 unique local are all refused. Proven live
against 127.0.0.1, 169.254.169.254 and 100.94.8.94, each refused with 502.

ONE REAL DEFECT FOUND AND FIXED BY THE WALKTHROUGH. Save was a single INSERT ... ON CONFLICT DO UPDATE. An
organization with no settings row took the INSERT branch, where the SET clause does not apply, so the FIRST
save an owner ever performed returned 200 and changed nothing. provision_org creates no settings row, so
EVERY newly provisioned customer hit it. MarkVerified and MarkAttemptFailed had the same class of bug, a
plain UPDATE against a missing row affecting zero rows and reporting success. Fixed with an ensureRow that
every writer calls. A structural regression test pins it and was PROVEN TO FAIL against the broken shape
before it was allowed to pass.

VERIFIED: 50 of 50 walkthrough assertions against staging, including the controls that matter. The stored
password never appears in any response, the scrubbed transport error carries no credential, a recruiter
cannot read the settings surface at all, a recruiter cannot widen their own access, and narrowing
work_visibility to private changes the recruiter's answer while leaving the owner's intact. 57 Go packages
pass, vet clean.

DEPLOYED: both production nodes run the IDENTICAL binary sha 93e07b85f224a0c9, both report organization
secret storage ENABLED key version 1, both health 200, public site 200, staging 200.

NOT DONE YET, named so it does not read as finished. work_claims and work_touches EXIST IN THE SCHEMA with
their indexes and policies, and nothing writes to them yet: the claim and presence ROUTES are the next piece,
and the visibility rules that will govern them are already live and tested. The frontend settings screen is
also not built; every route above is proven at the API only.

## WHO IS WORKING WHAT, the double work control, 30 July 2026

The tables went in with migration 0087 and nothing wrote to them. That is now closed. internal/modules/collab
serves five routes: read the activity on a record, record a visit, claim, release, and the caller's own list.

WHY ITS OWN MODULE. The question is identical for a candidate, a requisition, an opportunity, a proposal and
a client. Putting it in recruiting would have made the missionmatch module import a sibling to ask about a
candidate; a copy per module would have produced five answers that drift.

IT IS NOT A SECOND OWNERSHIP SYSTEM. clients and requisitions keep owner_user_id from migration 0047 as the
authority on whose desk a record belongs to. A claim is a shorter lived and different fact: not "this account
is mine" but "I am on this right now, do not also call them today". The read returns BOTH. CANDIDATES had
neither, and a candidate phoned twice in one day by the same agency is the complaint this closes.

DECISIONS RECORDED.
- A CLAIM IS NOT A LOCK. A second person gets 409 with the alternative named, and taking a record over is an
  EXPLICIT flag that writes its own audit row, so "Marcus took this from Dana" is findable later.
- CLAIMING AGAIN EXTENDS rather than conflicting, because a recruiter pressing claim twice means "I am still
  on this", which is what the expiry needs to hear.
- EXPIRED CLAIMS ARE RELEASED BEFORE A NEW ONE IS TRIED. The partial unique index covers every unreleased
  claim, so without this an abandoned claim would own a candidate forever.
- PRESENCE IS UPSERTED, NEVER APPENDED. One row per person per record. Appending would generate a row per
  page view per recruiter per candidate and put a browsing history of a named employee in a trivially
  reportable table. This is presence, not surveillance. Presence is also NOT RECORDED when the organization
  switches it off, rather than recorded and hidden.
- PRIVATE HIDES COLLEAGUES, NEVER YOURSELF, NEVER FROM MANAGEMENT. A caller who may not see others still sees
  their OWN claim, because hiding it causes the very double work this prevents. Managers see the team at
  every level, since a manager who cannot see the collision is the one person who could fix it.
- visible_to_you IS RETURNED EXPLICITLY. A filtered answer must never read as "nobody is on this".
- NO NEW CAPABILITY. Reads sit at candidate.read so a viewer sees the collision; writes at candidate.write.
  The frozen matrix already said this correctly and did not need widening.
- The entity type is a CLOSED MAP to table names because the table name reaches SQL. An unknown type is a 404
  before any query is built, and a test asserts every value is a bare lowercase identifier.

VERIFIED: 45 of 45 walkthrough assertions against staging with THREE real people on one real candidate, plus
8 module tests including a structural one that pins the visibility rule to exactly one call site. 58 Go
packages green, vet clean. Deployed to both production nodes, identical binary sha acf1f910eb9221f5, health
200 on each, site 200.

WORTH RECORDING: the first walkthrough run reported nineteen failures and every one was MY HARNESS, not the
product. The auth limiter is New(1, 10), burst ten refilling one per second, and creating three people in a
row makes about twelve auth calls, so the third person got 429 and I first misread it as a broken session.
The limiter was right. The harness now backs off instead, and the limiter was NOT weakened to make a test
pass.

STILL NOT BUILT: the frontend. Every route here is proven at the API only, so a recruiter cannot yet see any
of this.

## RECORD SCOPE AND TEAMS, the third access axis, 30 July 2026

Migration 0088 live in ALL THREE databases at v88, verified per database. teams and team_members with FORCE
ROW LEVEL SECURITY and zero role scoped policies, candidates.owner_user_id, three scope settings, and
mm_team_peer_ids.

WHY. A recruiting platform's access model has three axes and this had one and a half. WHAT ACTIONS may I take
was the capability matrix, already correct. WHICH FIELDS may I see was field sensitivity, migration 0087.
WHICH RECORDS may I see at all did not exist, and it is the axis Bullhorn, Greenhouse, Lever and Salesforce
all have. Two things blocked it: there was no notion of a TEAM, so "my team's records" could not be
expressed, and CANDIDATES HAD NO OWNER, so the most important record type in the product could not be scoped.

DECISIONS RECORDED.
- THE DEFAULT IS ORGANIZATION, WHICH IS EXACTLY TODAY'S BEHAVIOUR, and a test asserts every role still sees
  everything under the shipped settings. A migration that narrowed somebody's view on the morning it shipped
  would be an incident, not a feature.
- THE UNRESTRICTED QUERY PATH IS LITERALLY UNCHANGED. ListCandidatesScoped is a SEPARATE sqlc query, so an
  organization that has not narrowed runs the same statement it always ran and cannot have been broken.
- OWNER AND ADMIN ARE ALWAYS ORGANIZATION WIDE AND IT IS NOT CONFIGURABLE. A product that lets an
  administrator lock themselves out of their own data generates a support call it cannot resolve.
- A MANAGER MAY NOT BE NARROWED TO OWN, refused with 422: a manager who cannot see their team cannot run a
  desk. Manager scope chooses between the team and the floor, nothing narrower.
- AN UNKNOWN OR CORRUPT SETTING NARROWS TO own, never widens. The failure mode is somebody seeing too little
  and saying so, not everybody seeing everything and nobody noticing.
- A PERSON MAY BE ON SEVERAL TEAMS. Agencies run people across desks; one team per person makes the common
  case a lie. Team scope is the union of every team the caller belongs to, and the peer resolver INCLUDES the
  caller so somebody on no team still sees their own work.
- TEAM LEAD IS A LABEL, NOT AN AUTHORITY. Making somebody a lead does not promote them, which is what stops
  an org chart feature becoming a privilege escalation path.
- UNOWNED RECORDS ARE VISIBLE BY DEFAULT. An unowned candidate nobody can see is a candidate nobody will
  ever work. Releasing a candidate back to the pool is a supported action, not an error, so a departing
  recruiter's bench stays workable.
- READING the desks is candidate.read, since an org chart is not privileged. WRITING membership is
  org.settings.write, because under a narrowed scope adding somebody to a team IS an access grant, and it is
  audited as one.

VERIFIED: 41 of 41 walkthrough assertions against staging with an owner, a manager and TWO recruiters on
different desks over four candidates, proving narrowing hides, teams reveal, removal from a desk takes the
access with it, and no one can lock the account holder out. 58 Go packages green, vet clean. Both production
nodes on identical binary sha 2580f555149f9ff0, health 200 each, site 200.

THREE DEFECTS FOUND BY THE WALKTHROUGH, all mine, all fixed.
1. THE SAME SILENT NO OP AS LAST TIME. The three scope fields were added to the store, to validation and to
   the SQL, and NOT to the handler's request struct, so the API accepted them, returned 200 and changed
   nothing. A reflection test now compares the two structs field by field in BOTH directions and was proven
   to fail against the broken shape. This class of bug has now happened twice; it cannot happen a third time.
2. A NULL SCANNED INTO A Go bool. A team with no lead makes "lead_user_id = user_id" NULL, so every READ of
   the teams surface was a 500 while every write worked perfectly. That asymmetry is why it survived until
   somebody tried to look at the desks.
3. An untyped nil in an interface passed as a uuid parameter, which pgx cannot infer a type for.

STILL NOT BUILT: the frontend, and scope enforcement currently covers the CANDIDATE list, which is the record
type that had no owner and therefore the one that needed it. Requisitions, clients and opportunities already
carry owner columns and are NOT yet scoped; that is the honest boundary of this pass.

## THE TWO GAPS THAT MADE THE PRODUCT UNUSABLE, closed 30 July 2026

Research against the established products in this market, Bullhorn, Greenhouse, Lever, Ceipal, plus the
Salesforce patterns they all borrow, measured against a verified route inventory of 88 mounted routes. The
spine was strong: clients through requisitions through applications through offers through placements, with
activity logging, a task queue, six alert kinds including clearance_expiring, dispositions, reports and an
audit trail. TWO holes made it unusable in practice, and both change what a screen must show, which is why
they were closed BEFORE the frontend rather than retrofitted after it.

Migration 0089 live in all three databases at v89, verified per database: candidate_documents,
message_templates and messages, each with FORCE ROW LEVEL SECURITY, zero role scoped policies, and NO DELETE
grant to the app role, confirmed by querying grantee rather than trusting a count.

1. A RESUME COULD NOT BE ATTACHED TO A CANDIDATE. opportunity_documents existed; nothing equivalent existed
   for the record type the whole product is about. Now: upload, list, download and supersede, sharing the
   SAME object store as opportunity documents so there is one place to back up rather than two.
2. NOTHING COULD BE SENT TO A CANDIDATE. The only two send calls in the codebase were the account invite and
   the settings test message. Now: templates with server side placeholders, a preview, and sending through
   the organization's OWN mail server from migration 0087.

DECISIONS RECORDED.
- THERE IS NO DELETE ON A DOCUMENT. It is SUPERSEDED, so what was sent to a client six months ago stays
  recoverable. The duplicate index is PARTIAL on is_current, so the same bytes can be re uploaded once a
  document has been superseded, which is what a recruiter actually does.
- THE MEDIA TYPE IS DECIDED BY THE SERVER from a closed allowlist, and the EXTENSION beats the declared type
  because a browser's guess is caller supplied and frequently wrong. Downloads are served with
  Content-Disposition attachment, nosniff, a sandbox policy and private caching, so a file that slipped
  through could still not execute in the origin.
- THE INTEGRITY STAMP IS CHECKED ON THE WAY OUT. If stored bytes no longer hash to what was recorded, the
  download fails rather than handing somebody a file the audit trail does not describe.
- A MESSAGE ROW IS WRITTEN BEFORE THE SEND, not after. A send that succeeds while the database is briefly
  unavailable would otherwise leave a candidate holding a message the agency has no record of.
- EVERY SEND ALSO WRITES A recruiter_activities ROW with auto_captured true, so outreach appears in the same
  history as calls and meetings. The subject is folded into the body because that table has no subject
  column, and inventing one to suit messaging would change a table five other surfaces read.
- PLACEHOLDERS ARE VALIDATED AT AUTHORING TIME and refused if unfillable, because a candidate receiving a
  visible curly brace reads it as a broken mail merge.
- A PLACEHOLDER NEVER RENDERS EMPTY. first_name falls back to the full name and then to a neutral word,
  because "Hi ," is worse than no personalisation.
- SENDING IS candidate.write and reading correspondence is candidate.read. Template authoring is
  org.settings.write, because a template goes out under the organization's name to people who are not its
  employees.

VERIFIED: 38 of 38 walkthrough assertions against staging, including the controls: an HTML upload and an
executable both refused with 415, an empty file 422, an identical re upload 409, the attachment and nosniff
headers present, and a send refused with a 409 that names the screen that fixes it rather than a 500. 58 Go
packages green, vet clean. Both production nodes on identical binary sha f31cff48b3a78faa.

TWO DEFECTS THE WALKTHROUGH FOUND, both mine.
1. PREVIEW REFUSED WHEN A RECORD HAD NO EMAIL ADDRESS. Previewing text is useful whether or not an address
   exists, and refusing sends a recruiter hunting a bug that is not there. Preview now renders and returns
   sendable false with the reason; only the SEND path insists on an address.
2. A CANDIDATE CREATED THROUGH THE API COULD NEVER HAVE AN EMAIL ADDRESS. The candidates table has carried
   email and headline since migration 0002 and the insert always wrote them, but createCandidateRequest
   never exposed either. So the outbound correspondence just built would have been unusable for every
   candidate created through the API. Found only by testing a send against a real record.

DELIBERATELY NOT BUILT, recorded so it does not get picked up by accident: timesheets, invoicing and VMS,
which are a second product and which the client's enterprise customers already impose; and autonomous AI
sourcing and screening, which would damage the Automated Employment Decision Tool story that is this
product's actual differentiator.

STILL MISSING, in the order the research ranked them: saved searches and hotlists, bulk actions, an inbound
apply path and job board posting, email and calendar sync so activity logs itself, interview scheduling, and
duplicate merge. Then the frontend.

## SEARCH, SAVED SEARCHES, LISTS AND BULK ACTIONS, 30 July 2026

Migration 0090 live in all three databases at v90, verified per database: saved_searches, candidate_lists,
candidate_list_members, forced RLS, zero role scoped policies, plus two structured indexes search needed.

THE GAP WAS WORSE THAN THE RESEARCH SAID. There were no saved searches, and there was no SEARCH: the
candidates route took a limit and an offset and nothing else, so "TS/SCI cleared network engineers in
Maryland who are available" was not a question this product could be asked. The GIN index over search_tsv and
the HNSW index over resume_embedding have existed since migration 0002 with nothing mounted on them.

DECISIONS RECORDED.
- A SAVED SEARCH IS A QUESTION, A LIST IS AN ANSWER. Two tables, not one with a flag. A saved search re runs
  and its result moves with the bench; a list is what somebody committed to and must not move underneath
  them, because an agency that shortlists nine people for a bid needs those nine next week.
- EVERY USER VALUE IS A BOUND PARAMETER. Only column names and operators from closed sets are interpolated.
  Proven with an injection string, a bare wildcard, and punctuation, all of which return 200.
- websearch_to_tsquery, not plainto_ or to_tsquery, so a recruiter typing O'Brien or an ampersand gets
  results rather than a syntax error.
- SEARCH RESPECTS RECORD SCOPE through the SAME orgsettings.Filter every list uses. Without it a recruiter
  narrowed to their own records could simply search for everybody else's, which would be a hole straight
  through migration 0088. Proven: a scoped recruiter gets 0 and cannot widen it by naming an owner.
- scope_applied IS RETURNED, so a short answer is explained rather than mistaken for an empty bench.
- BULK IS ONE TRANSACTION and reports per record outcomes. Already on the list is a SKIP, not an error,
  because somebody selecting forty people does not know which nine are already there. One malformed
  identifier refuses the WHOLE batch, because a bulk action that quietly did thirty nine of forty is the kind
  of thing nobody notices until the fortieth person never gets called.
- NO DELETE ON A LIST, it is archived, because "who did we shortlist in March" is a June question and because
  a do_not_contact list that can be deleted is a compliance record that can be deleted. Membership CAN be
  deleted, since removing somebody from a shortlist is a correction.
- A PRIVATE SAVED SEARCH IS INVISIBLE TO EVERYONE ELSE INCLUDING THE OWNER OF THE ACCOUNT, and deleting one
  you do not own returns 404 rather than 403, so private search names cannot be enumerated.

THE DEFECT THIS FOUND, and it predates all of this work.
CLEARANCE WAS STORED AS A CODE AND COMPARED AS A LABEL. The persisted value is ts_sci; the interface shows
TS/SCI. codes.go says so explicitly and calls persisting the label rather than the code "a real bug class".
Two halves were both wrong: validLevelCode accepted ONLY an exact code and silently degraded anything else to
"unknown", so a candidate saved through the API with the label the interface displays LOST THEIR CLEARANCE,
with no error; and the new search compared raw input against the column, so a recruiter typing what they see
got an empty bench. Neither raised anything. Storing and searching now SHARE one translation, so the two
vocabularies cannot drift, and a test locks every label and code spelling to its stored value.

VERIFIED: 47 of 47 walkthrough assertions against staging over a five person bench with two lists and a
second signed in recruiter. 58 Go packages green, vet clean. Both production nodes on identical binary sha
b840acabd61a4222, health 200 each, site 200.

STILL MISSING, in the order the research ranked them: an inbound apply path and job board posting, email and
calendar sync so activity logs itself, interview scheduling, and duplicate merge. Then the frontend.

## THE INBOUND PATH, a public careers page and an apply route, 30 July 2026

Migrations 0091, 0092 and 0093 live in all three databases at v93, verified per database. job_postings and
job_applications with forced RLS, zero role scoped policies and no app DELETE, plus three SECURITY DEFINER
functions with EXECUTE revoked from PUBLIC.

Until now every candidate had to be imported or typed in by a recruiter, so the product could only hold
people somebody had already found. This is the difference between a database and a pipeline.

DECISIONS RECORDED.
- THE PUBLIC URL CARRIES THE EMPLOYER SLUG. A public request has no session, so no organization, so RLS
  denies it everything, and something must name the tenant first. A bare token would need a global token to
  tenant map that works across sharded databases; the slug is already the directory key and is information
  the applicant should see anyway, because they are applying to Acme and not to an opaque string.
- THE PUBLIC COPY IS ITS OWN TEXT, NOT A JOIN TO THE REQUISITION. A requisition carries bill rate, pay rate,
  the client name and the internal description, and rendering a public page from it would put the agency's
  margin and its customer's identity on the open internet with a silent failure mode. Publishing is therefore
  an act of WRITING, and a field that is not on the posting row cannot leak. The walkthrough asserts this
  directly against a requisition seeded with a rate and a confidential client name.
- A SUBMISSION IS NOT A CANDIDATE. Under the OFCCP Internet Applicant rule an applicant is somebody who
  expressed interest AND whom the contractor then CONSIDERED, and a federal contractor must show both.
  Submissions land in job_applications; converting one is a separate recorded act by a named human. It also
  means spam never reaches the bench.
- THE SELF REPORTED CLEARANCE IS NOT CARRIED ACROSS on conversion. Writing it into the candidate's clearance
  field would turn an unverified claim into a scored attribute. A recruiter sets it after checking.
- CONSENT IS REQUIRED AND RECORDED AS TEXT PLUS A TIMESTAMP, not a bare boolean, because "they ticked a box"
  is not a defensible answer and the wording changes over time.
- ONE ANSWER, 404, for a missing employer, a missing posting, a draft and a closed one, so the public surface
  cannot be used to map which customers exist or which roles they are quietly working.
- NO CSRF ON THE PUBLIC ROUTES, deliberately and correctly: CSRF protects a request carrying ambient
  authority and these carry none. They have their OWN rate limiter, two a second with a burst of twenty,
  sized for strangers rather than for a signed in floor.
- NO DELETE on either table. An applicant flow log with holes in it is not an applicant flow log; spam is
  marked spam.

VERIFIED: 35 of 35 walkthrough assertions against staging, with the public half tested using NO COOKIE JAR AT
ALL so a pass proves a genuine stranger can reach it. 59 Go packages green, vet clean. Both production nodes
on identical binary sha 322b606e56b175c9.

THREE DEFECTS, all found by the walkthrough, all mine.
1. THE STAGING PARITY HELPER MIRRORED TABLES AND COLUMNS AND NOT FUNCTIONS. Migration 0085's lesson in a new
   place: every SECURITY DEFINER function ever granted to missionmatch_app was unreachable from
   missionmatch_staging_app. It failed expensively, as the careers page reporting a genuinely published
   posting as unavailable, so the symptom pointed at the data and not at a permission. Migration 0092 fixes
   the HELPER rather than the one function, identifying functions by full argument signature because a name
   alone is ambiguous under overloading.
2. THE PRE TENANT RESOLVE WAS A PLAIN QUERY against organizations, which carries FORCE ROW LEVEL SECURITY.
   The app role is NOBYPASSRLS and a public request has no app.current_org_id, so it correctly returned zero
   rows. The tenancy contract was working exactly as designed and the feature was wrong. Migration 0093 adds
   a narrow SECURITY DEFINER resolve that returns an identifier and nothing else.
3. MIGRATION 0093 SHIPPED WITHOUT goose StatementBegin MARKERS, so goose split the dollar quoted function
   body on its internal semicolons and the migration failed. It failed SAFELY, transactional, version
   unchanged. Every other migration defining a function was then checked and all carry the markers.

STILL MISSING, in the order the research ranked them: email and calendar sync so activity logs itself,
interview scheduling, and duplicate merge. Then the frontend. External job board DISTRIBUTION, posting out to
ClearanceJobs or Indeed, is an integration per board and is NOT built; what exists is the careers page and
the apply route those boards would point at.

## MAIL SYNC, so a recruiter's correspondence logs itself, 30 July 2026

Migration 0094 live in all three databases at v94, verified per database: mail_accounts and synced_messages,
forced RLS, zero role scoped policies.

recruiter_activities has had the right vocabulary since migration 0049 and every row in it had to be TYPED BY
A HUMAN, which is the most reliable way to end up with an activity log nobody trusts: the people best at
recruiting are the least likely to stop and write down that they sent an email.

DECISIONS RECORDED.
- HEADERS ONLY, NEVER BODIES, and it is a property of the code rather than a convention. internal/platform/
  imapclient asks for a fixed header field list and has NO PARAMETER through which a body could be requested.
  Pulling bodies would drag a recruiter's whole mailbox, including correspondence with their doctor and their
  lawyer, into a platform holding controlled unclassified information under an employment record retention
  rule. The value of the body is small and the liability is enormous.
- A MESSAGE MATCHING NOBODY IS NOT STORED AT ALL. Every message is compared against the tenant's candidates
  and contacts by address and dropped if it matches none. Connecting a mailbox is not handing over a mailbox,
  and the sync result reports the discarded count so that promise is visible rather than asserted.
- WRITTEN IN HOUSE RATHER THAN TAKEN FROM A LIBRARY, following the recorded TOTP precedent: every primitive
  stays provably inside the FIPS validated module and there is no external crypto to re verify. It is a
  narrow IMAP4rev1 subset and must not grow into a general client.
- EXAMINE AND BODY.PEEK, so syncing never marks a recruiter's mail read. A sync that silently changed what
  their mail client showed them would be noticed once and switched off forever.
- IMPLICIT TLS ONLY, no STARTTLS negotiation, because a negotiated upgrade is one more thing that can
  silently not happen.
- THE SAME REACHABILITY BOUNDARY as the mail sender, resolved then dialled by ADDRESS so DNS rebinding cannot
  slip past. Proven live against 127.0.0.1, 169.254.169.254, 100.94.8.94 and 10.0.0.5.
- PER USER, and every route acts on the CALLER with no user parameter. An endpoint that let one person
  configure another's mailbox would be a way to point somebody else's credentials at a server you control.
- The dedup ledger is deleted on disconnect, so a recruiter who reconnects re syncs cleanly instead of being
  permanently blocked by a ledger they cannot clear. Activities already logged are untouched.

VERIFIED: 24 of 24 walkthrough assertions against staging, plus 9 parser unit tests including a totality test
that throws hostile and malformed headers at every parsing function. 60 Go packages green, vet clean. Both
production nodes on identical binary sha d30e1e05814593c2.

HONEST BOUNDARY, stated plainly: THE END TO END SYNC AGAINST A LIVE IMAP SERVER IS NOT TESTED. There is no
real mailbox to connect to here. What is proven is the configuration surface, the credential never being
returned, the reachability guard, an unverified mailbox being unable to switch on, a sync refusing to run
against one, and the header parsing and address matching in unit tests. The first real mailbox will be the
first real test, and it should be a test account rather than a live recruiter's.

TWO DEFECTS THE WALKTHROUGH FOUND, both mine.
1. EVERY VALIDATION ERROR REPORTED ITSELF AS A BAD GATEWAY. Configuration mistakes and transport failures
   shared a message prefix and the handler could only pattern match on it, so a missing host returned 502.
   Fixed with a sentinel error rather than a better pattern.
2. THE FAILURE RECORD WAS ROLLED BACK BY THE ERROR THAT CAUSED IT. TestMailbox wrote last_error inside the
   transaction and then returned the error from inside the same closure, which rolls the transaction back and
   takes the row with it. A user saw a 502 and then found last_error empty, the least helpful possible
   combination. The auth module carries the same note about an audit row for exactly this reason, which is
   the second time this pattern has bitten this codebase.

STILL MISSING: interview scheduling, duplicate merge. Then the frontend. Calendar sync is NOT built; CalDAV
is the vendor neutral equivalent and is a separate piece.

## INTERVIEW SCHEDULING, 30 July 2026

Migration 0095 live in all three databases at v95: interview_offers and interview_offer_slots with forced
RLS, zero role scoped policies, and a public SECURITY DEFINER read with EXECUTE revoked from PUBLIC.

interviews has existed since migration 0048 and it RECORDS an interview. It had no way to ARRANGE one, which
is the part that costs a recruiter an afternoon, being four emails and a phone call per candidate.

DECISIONS RECORDED.
- THE CALENDAR INVITE IS AN iCALENDAR ATTACHMENT, NOT A CALENDAR INTEGRATION. Integrating Google Calendar and
  Microsoft Graph means two vendor OAuth applications, two consent screens, two credential sets and a
  permanent dependency on two APIs, which cuts against the both clouds no lock in mandate and does nothing
  for a candidate whose calendar is neither. An iCalendar REQUEST attachment is the interoperable standard
  all of them already accept, needs no credentials, and is a few hundred lines with no dependency.
- multipart/ALTERNATIVE, not mixed. Mixed produces a message with a file attached that a calendar ignores;
  alternative with method=REQUEST is what makes the accept and decline buttons appear.
- AN OFFER IS NOT AN INTERVIEW. Offering three times creates an offer with three slots; the interviews row
  appears only when somebody picks one. Creating it up front would leave a pipeline full of interviews that
  never happened, which is exactly the number a hiring manager asks about.
- THE SLOT IS TAKEN UNDER A CONDITIONAL UPDATE, not a read then write. Two candidates cannot race, but one
  candidate double clicking absolutely can, and a check followed by an update would create two interviews.
  Proven: the second click is refused and the count stays at one.
- THE INVITATION IS SENT AFTER THE TRANSACTION COMMITS, and a mail failure does NOT fail the booking. The
  time is taken and the interview exists; a missing calendar entry is something a recruiter fixes by hand.
- Times are ALWAYS UTC with the trailing Z and every value is escaped and every line folded. An unescaped
  comma silently truncates a location in the recipient's calendar; an unfolded line over 75 octets is
  rejected by some clients and mangled by others. An invite that arrives corrupted is worse than none,
  because the recruiter believes it was sent.

VERIFIED: 26 of 26 walkthrough assertions against staging with the public half using no cookie jar, plus 8
iCalendar unit tests covering escaping, folding, multi byte safety, UTC conversion and cancellation. 61 Go
packages green, vet clean. Both production nodes on identical binary sha f611d2f915ccca36.

TWO DEFECTS, one mine and one that predates this work.
1. MINE: a parameter was used both as a timestamp column and as the left side of an addition in the same
   INSERT, so Postgres deduced two types for it and refused the statement with SQLSTATE 42P08. The handler
   turned that into a generic 500 with no cause in the log, which cost a round of guessing; the handler now
   LOGS the cause while still returning a generic message. The arithmetic moved into Go.
2. PRE EXISTING: THERE WAS NO WAY TO LIST INTERVIEWS. They could be created and updated and never read back,
   so the only way to see what was scheduled was to query the database. Found because the walkthrough tried
   to confirm that booking produced exactly one interview. GET on an application's interviews now exists.

STILL MISSING: duplicate merge. Then the frontend. Calendar SYNC, reading a recruiter's existing calendar,
is not built and is a separate piece from sending an invitation.

## CANDIDATE MERGE, and the carried issues, 30 July 2026

Migration 0096 live in all three databases at v96: candidates.merged_into_id, candidate_merges, and
mm_candidate_referencing_tables.

A bench gets dirty. The same person applies through the careers page, arrives in an ATS export, and is
sourced by a recruiter, and now there are three of them with a third of the history each. Dedup existed at
IMPORT time only; nothing existed for the duplicates that arrive afterwards, which is most of them.

DECISIONS RECORDED.
- THE TABLES ARE READ FROM THE CATALOG, not a list in Go. It found EIGHTEEN referencing tables where a hand
  count of the migrations found fifteen, which is the argument in one number: a list would already have been
  wrong, and the failure is silent, a merge reporting success while history stays on a tombstone.
- A SAVEPOINT PER TABLE. Repointing collides whenever both records already had the same thing, which for two
  rows of one person is the common case, and without it the first collision aborts the merge that exists to
  fix exactly those duplicates.
- THE LOSER IS A TOMBSTONE, NEVER A DELETE. A scoring decision made in March about that record has to be
  reconstructable in June, and deleting it destroys the subject of the decision.
- FIELDS ARE FILLED IN, NEVER OVERWRITTEN, and clearance is not touched at all. Overwriting would let a merge
  quietly replace a verified clearance with an unverified one. Proven: after merging a Secret record into a
  TS/SCI one, the kept record is still TS/SCI.
- MERGING IS org.settings.write, ABOVE ordinary candidate.write. It is not reversible by the person who did
  it and it rewrites whose history is whose. A recruiter can SEE suggested duplicates, because that is a
  report, and cannot act on them.
- DETECTION ONLY SUGGESTS, and labels itself honestly: an email match is strong, a name and location match
  is WEAK because two cleared analysts called James Smith in one metro area is an ordinary thing.

THE FINDING THAT MATTERS MOST, and it is the system defending itself. aedt_candidate_notices has NO UPDATE
grant for the application role. The first merge attempt died on it. That grant is correct: a disclosure
notice sent to a candidate under an Automated Employment Decision Tool rule is a FACT ABOUT THAT PERSON, and
repointing it at somebody else would falsify a compliance record to make a tidy merge. The merge now records
those tables as RETAINED, distinct from DROPPED, and carries on; the tombstone still resolves so nothing
becomes unreachable. candidate_merges is excluded for the same reason.

VERIFIED: 21 of 21 walkthrough assertions against staging, exercising a REAL collision, both records on one
list and a resume on the loser. 61 Go packages green, vet clean. Both production nodes on identical binary
sha e0d98251afdf0812.

THREE DEFECTS FOUND BY THE WALKTHROUGH.
1. ADDING A COLUMN TO candidates BROKE CANDIDATE SEARCH. The search does SELECT c.* into a generated struct
   by name, so merged_into_id with no matching field made every search a 500. sqlc had not been regenerated.
   This is the cost of SELECT * with struct mapping and it is worth remembering: a migration that touches
   candidates now requires a regenerate.
2. AN ALREADY MERGED RECORD REPORTED "no such candidate". The existence check filtered on deleted_at, so a
   tombstone looked absent. That is actively misleading: it tells somebody the record does not exist when it
   is exactly where they left it. Now 409 with the real reason.
3. The merge tried to repoint the merge LEDGER itself, which would rewrite the record of past merges.

CARRIED ISSUES ALSO CLOSED TODAY. Session status codes now 401 rather than 403 for every "no session" case,
with the required WWW-Authenticate header and a scheme that does not make a browser show its own login
dialog; the authenticated but unscoped cases correctly stay 403. All 28 nginx conflicting server name
warnings had one cause, backup files inside sites-enabled being loaded as live configuration; moved not
deleted, zero conflicts, all affected sites verified at 200. Clearance data assessed and deliberately NOT
changed: one record of eleven, no email and no resume, so guessing was refused. And a real security finding
while sweeping for the pasted keys: /home/user/mmk/*.blob were 0644 in a 0755 home on a host serving sixty
sites, and live.blob held a live Google key and a live Groq key; now 0600, services unaffected, and those two
keys should be treated as disclosed.

STILL MISSING: the frontend. Every surface built today is proven at the API only.

## SESSION HANDOFF, 30 July 2026. PHASE 2 IS CLOSED. WRITTEN LAST.

THIS IS THE LAST WRITE OF THIS SESSION. Nothing was done after it.

PHASE 2 CLOSED under Joseph's recorded conditional pre approval: fully green with zero open findings closes it
on his word. All five gates are green at HEAD and all four findings are closed. GATE_E.md is the account he
reads, and it LEADS with what is wrong rather than burying it.

CURRENT PHASE: PHASE 3, NOT STARTED. Exactly one phase named, and it is the next one.

GATE STATES, all at HEAD, each with a control that had to fail first
  A functional  PASS. 55 packages ok 0 fail. 217 integration tests 0 fail 1 skip.
  B stress      PASS. Complete at HEAD, needed no rerun. 30 minute soak, 2,028,801 samples.
  C visual      PASS WITH ONE NAMED COVERAGE LIMIT. 88 captures 0 findings both surfaces. Pixel baselines
                approved and proven both ways, 48 and 40 compared with 0 regressions, controls catching 48 of
                48 and 40 of 40. THE LIMIT: 48 authenticated captures hold only 18 distinct images because both
                fixture accounts hold one tool, so most routes render the same denial panel.
  D drift       PASS. Engine diff 0 with anchor and path asserted, controlled at 1476 lines against the wrong
                anchor. Schema 85 across all three databases, each queried directly. Production API binary byte
                identical to the pre build hash.
  E human       Joseph's, and the pre approval is already recorded.

WHAT THE RERUNS COST AND FOUND. Gate A FAILED on its first rerun with seven failing integration tests, and the
reruns found TEN defects. Two were production defects live for days: the embedding provider could not
authenticate at all, so every embedding depended on another project's node proxy staying alive; and the gateway
refused every teaching signal ever sent, which is why the teaching tables are empty, not unused but unreachable.
  THE EARLIER GATE A PASS IS WITHDRAWN AS EVIDENCE. Three of its tests could not have passed against a correctly
  granted database, so that verdict was taken without them or with other credentials.
  THE PIXEL HALF OF GATE C NEVER EXISTED. Joseph's approval of the contact sheets unblocked nothing because the
  code had never been written, and two write ups had filed the gap as awaiting his approval. Built, and proven
  in both directions.
  THE SUITE WAS HIDING THE EVIDENCE. Run with default environment it executed 195 tests and silently omitted 22.
  A test gated on an optional variable does not fail, it disappears. Four of six Gate A defects were only
  reachable once those tests ran.

STATE AT STOP, measured after the last change
  HEAD is this commit, tree clean. 55 packages ok, 0 FAIL, GOFIPS140=v1.0.0.
  Secret sweep CLEAN, working tree and 15 of 15 out of repo scopes.
  Zero Python, zero dashes across every tracked doc, each with a planted control.
  Engine diff 0 at internal/modules/matching/engine against e74fd2e, 10 files each end.
  Schema 85 on tenant, staging, and control plane.
  PRODUCTION NOW RUNS PHASE 2. Both API nodes on 8ce5a2b8141a2ab1, frontend index-DmaEX_GX.js with self hosted
  fonts, gateway 9e1ff5da245989cd. Phase 2 routes answer 403 and 405 where they answered 404 yesterday. The
  teaching boundary accepts the current contract for the first time, 202, and still refuses a planted client
  fact, 422. Document intake remains DARK by design: MM_STORAGE_ROOT is unset in production and enabling it is
  a decision about a disk at 82 percent that also holds the backups. Rollback artifacts in place on every host.
  See deploys/production-deploy.txt, including the three things that went wrong and the checks that caught them.

WHAT CHANGED ON THE MACHINES
  M4        the STAGING gateway binary was replaced and restarted with identical env, so /v1/teach now accepts
            the current scoring contract and logs what it accepts. The PRODUCTION gateway on 8092 still carries
            the old binary and therefore still refuses every teaching signal. FIXING THAT IS A PRODUCTION DEPLOY
            AND IT IS JOSEPH'S CALL.
  Bubbles   staging frontend redeployed twice: the Admin roster fix and the self hosted fonts. Fonts now served
            from /fonts, no request leaves for Google. mm-missionclass.timer installed and enabled nightly.
            pixelmatch and pngjs installed in ~ for the sweep. Gate C baselines in ~/gatec-baselines.
  megamind  mm-identity-sync.sh replaced earlier in the build, backup at /root, hourly timer healthy.
  DATABASES migration 0085 applied to all three. Its guard makes it a genuine no op outside staging and both
            other databases logged the skip before recording the version.

PHASE 3, SCOPE ALREADY RECORDED, in dependency order
  1. The vocabulary decision, MAG and TAG, because every entry written after it inherits the names.
  2. THE WRAP RATE AND BURDEN MODEL. Zero such columns exist, so bill rate minus pay rate is a SPREAD and the
     product can show a number that looks like margin and is not one.
  3. The wage bridge, D22, which is ONE item and not three: canonical SOC form, then ontology_crosswalk, then
     skills.soc_code. promote-ontology is NOT safe to run until it is settled.
  4. The self extending knowledge store, rows never tables, which lands before the crosswalk since the
     crosswalk is its first customer.
  5. The office format reader holds Phase 3's single IMPROVEMENT slot, which is spent before Phase 3 starts.
  THE MONEY ITEMS COME BEFORE THE INTELLIGENCE ITEMS. Composition makes an answer only as good as its worst fed
  generator, and today the profitability half cannot be answered at all.

JOSEPH OWES TWO THINGS, neither blocking
  Rotate the five API keys pasted into chat: Groq, OpenRouter, Sarvam, Cerebras, Gemini.
  Decide on the OpenAI account, and rotating that key before funding it is the safer order.

WHAT TO CARRY FORWARD. Seventeen instances are now catalogued of an instrument reporting a clean result while
measuring something adjacent, ten of them found in this one session. The habit that finds them has not changed:
assert the instrument CAN fail before believing that it did not, supply every variable a suite will silently
skip on, and write the number down before changing the thing that produces it.

SELF EXTENDING KNOWLEDGE STORE, DESIGN AND ONE REFUSAL, 29 July 2026. Joseph asked that the intelligence be
able to create its own tables and graph stores, everything that goes into a database, so that the class of
problem where it learns something and has nowhere to put it is fixed.

THE PROBLEM IS REAL AND IS CORRECTLY IDENTIFIED. ontology_crosswalk is the proof: a well shaped general code
bridge, created by migration 0021, granted SELECT, read by G3's skill gap bridge, and NEVER WRITTEN by anything.
Tonight's scan found the same shape repeatedly. solicitation_extractions holds 2457 grounded extractions no code
reads. teaching_signal_aggregates and curation_proposals are empty because the transport that fills them was
refusing every signal. The intelligence keeps learning into places nothing connects.

ONE REFUSAL, AND IT IS SPECIFIC RATHER THAN CAUTIOUS. RUNTIME DDL IS NOT GRANTED. Not CREATE TABLE, not CREATE
INDEX, not ALTER, from any AI code path. Four reasons, each tied to something already load bearing here:
  1. A TABLE CREATED AT RUNTIME HAS NO RLS POLICY. Migration 0085 exists tonight because a policy that fails to
     name a role denies everything. A table with NO policy, made by a role holding CREATE, is the opposite
     failure: it is readable across tenants with no fail safe at all. The tenancy contract is "no context means
     zero rows", and a policyless table cannot honour it.
  2. IT WOULD SIT OUTSIDE EVERY OTHER CONTRACT TOO. No FORCE ROW LEVEL SECURITY, no organization_id leading
     composite index, no place in safety.go's read allowlist, no provenance column born with the row, and no
     entry in the sqlc typed layer. Each of those is a rule this build already paid for.
  3. MIGRATIONS ARE THE ONLY WAY TO CHANGE SCHEMA, and that is an ASSESSOR FACING CONTROL under the 800-171
     posture, not a style preference. Self created schema is unauditable drift by definition.
  4. EVERY GATE WOULD STOP MEANING ANYTHING. The schema measured at Gate D would not be the schema at runtime.
     After a week in which six instruments were caught reporting success while measuring something adjacent,
     handing the system the ability to change the thing the gates measure is the last thing it needs.
  The app role is NOBYPASSRLS with column level grants for exactly these reasons. Granting it CREATE undoes a
  deliberate design, and I am not doing it quietly on my own authority.

WHAT IS BUILT INSTEAD, AND IT SOLVES THE ACTUAL PROBLEM: THE INTELLIGENCE GROWS ROWS, NEVER TABLES.
  The schema is created ONCE by a migration and is general enough that new knowledge is DATA rather than DDL.
  New node kinds, edge kinds, code systems, relation types and attributes all become rows. This is not a
  workaround; it is what ontology_crosswalk already is, and its columns say so: from_system, from_code,
  to_system, to_code, relation, source_name, synced_at. A general bridge between code spaces, written once,
  extensible forever without touching schema.
  THE STORE'S REQUIRED PROPERTIES, all inherited from rules this build already enforces:
    RLS forced, organization_id leading, so a learned fact is a TENANT fact unless it is explicitly global.
    PROVENANCE BORN AT ORIGIN, the migration 0081 pattern, so a row carries where it came from immutably and
      the egress gate can refuse it without anyone remembering to.
    CITATION OR NOTHING. A learned edge names its evidence, the same rule that makes a fabricated quote
      impossible to store today.
    APPEND MOSTLY with supersession rather than mutation, so what the system used to believe stays readable.
    THE THREE DOORS HOLD. The intelligence PROPOSES into curation_proposals; a NAMED HUMAN promotes. That path
      already exists with its approve and verify endpoints, and it is the only door into anything the scoring
      engine can see.
    SUPPRESSION AND EEO ISOLATION unchanged, so a learned aggregate cannot become a small cell disclosure.
  WHAT THAT BUYS: the crosswalk gets a writer, the orphaned extractions get a home, the graph planes get edges
  they can traverse, and the intelligence can invent a new relation type at 3am without a human writing a
  migration, while it remains impossible for it to invent a table nobody governs.

ALLOCATION. This is PHASE 3 SCOPED WORK under the same recorded decision that moved the wrap rate there: it is
new capability, and building it inside a locked phase whose gates are mid rerun is the exact drift the protocol
exists to prevent. It is scoped work rather than an improvement, so it does not touch Phase 3's improvement slot,
which the office format reader holds.
DEPENDENCY ORDER WITHIN PHASE 3: the store lands BEFORE the crosswalk work in task 13, because the crosswalk is
its first real customer and building the customer first would mean building it twice. | this commit | 2026-07-29

RECORDED OWNER DECISIONS, 29 July 2026 night, Joseph: "Go i agree with everything now we should be able to
finish phase 2." Two decisions follow from it and both are written here before any work proceeds.

DECISION ONE, FINDING THREE CLOSES BY DECISION. The external commercial lane stays DISABLED, recorded as
outside the FIPS boundary and restricted to non regulated tasks, which is what directive 5.3 already says of it.
THE DIRECTIVE'S OWN WORDS SUPPORT THIS AND I READ THEM TOO STRICTLY FOR TWO DAYS. 5.3 says public SAM notice
text MAY use the external backend, not must. It requires: a third backend with the enabled flag default false,
boot failing closed without the secret, only the four public classes leaving the machine, every external call
auditing backend, payload class, byte count and content hash, and THE VERIFIER GATING ALL RETURNED PROSE
EXACTLY AS IT DOES FOR LOCAL MODELS. Every one of those is now proven, the audit one only because D19 was found
and fixed. The verifier requirement is satisfied BY THE DIRECTIVE'S OWN FRAMING: it is backend blind by
specification, so proving it against local prose proves it.
  WHAT IS ALSO TRUE: the commercial api.openai.com endpoint is not a sanctioned production provider anywhere in
  STACK_DECISIONS, which names AWS Bedrock in GovCloud, Azure OpenAI in Azure Government, and self hosted vLLM.
  Exercising it would have proven a lane production would never use.
  WHAT REMAINS UNPROVEN AND IS ACCEPTED AS SUCH: prose authored by an external model passing the verifier. The
  residual risk is small because the validator cannot tell where bytes came from. It is not zero and is not
  being written up as though it were.
  THE BOUNDED RUN IS NOT WASTED. It executed every mechanism on this side against the live endpoint for the
  first time, it proved the boot guard both ways, and it is what surfaced D19.
  IF AN EXTERNAL LANE IS EVER WANTED IN PRODUCTION it should target Bedrock GovCloud or Azure OpenAI Gov behind
  the existing provider interface, which is a future phase item and not this one.

DECISION TWO, THE WRAP RATE MODEL IS PHASE 3 SCOPED WORK, NOT PHASE 2. Joseph said go on the wrap rate and in
the same breath said Phase 2 should now finish. Those two only reconcile one way, and this is the correction:
building the wrap rate inside Phase 2 would be UNSCOPED WORK INSIDE A LOCKED PHASE, which is the precise drift
the protocol exists to prevent, and it would enlarge Phase 2's gates so they never settle. Phase 2 therefore
closes on its existing scope and the wrap rate becomes PHASE 3's FIRST SCOPED ITEM under the full five gate
protocol.
  NOTE FOR PHASE 3 PLANNING: Phase 3's single IMPROVEMENT slot is already spent on the office format reader.
  The wrap rate is SCOPED WORK, not an improvement, so it does not compete for that slot. The distinction
  matters because conflating them would either lose the office reader or smuggle scope through the improvement
  channel.
  THE WRAP RATE'S DEPENDENCY IS ALREADY KNOWN AND RECORDED: it needs the wage bridge, D22, which is one item
  and not three, and it must ship with a control that asserts a labor category resolves to a SOC code AND that
  the code returns a non empty OEWS wage row.

SO PHASE 2'S REMAINING WORK IS EXACTLY THREE THINGS: the Gate A, C and D re runs against the settled pipeline
with positive controls before the first counted run, the honest GATE_E.md rewrite, and the bundle filing.
Zero open findings once decision one is recorded. | this commit | 2026-07-29

THIRD POSTSCRIPT, WORKING THE LIST, 29 July 2026 night. Joseph asked for a complete list of everything with
nothing left out, and for work to start down it. The list is 23 open items, tracked in the session task list
and enumerated across the four entries below this one. PROGRESS AND THE BLOCKING STRUCTURE:

  DONE AND VERIFIED THIS SESSION
    The corpus is fully embedded, 6902 of 6902, guarded before and verified three ways after.
    The WS7 classification pass ran for the first time and is still running its full corpus pass in the
      background: mission tags 0 to 84, incumbent roles 0 to 77 to 273 and climbing.
    A nightly timer now runs it without me, and the out of repo sweep picked the new unit up automatically.
    Finding four closed, findings one and two closed by decision, D19 found and fixed.

  STOPPED BEFORE DOING HARM, which is the real result of starting the list
    D22 below. promote-ontology looked like a routine run and would have written O*NET descriptor codes into
    skills.soc_code, taking the wage bridge from honestly empty to confidently wrong. Caught by comparing the
    two code spaces BEFORE running rather than after. That is one item removed from the safe run list and one
    production data corruption not committed.

  THE BLOCKING STRUCTURE, so the next session does not rediscover it
    THE MONEY ITEMS BLOCK THE INTELLIGENCE ITEMS. Composition and the critic make an answer only as good as its
      worst fed generator. Wire the nine generator question today and the wage half returns nothing, because of
      D22, and the profitability half cannot be answered at all, because no wrap rate column exists. Build the
      money model FIRST or the composition layer will confidently answer half a question.
    THE WAGE BRIDGE IS ONE ITEM, NOT THREE. Canonical SOC form, then the crosswalk, then soc_code. Any one
      alone accomplishes nothing and will look like progress.
    THE KNOWLEDGE ROUTES NEED A DEPLOY DECISION, NOT A CODE FIX. /api/knowledge/manifest and cards are 404 in
      production and the handler declares them. Mounting them ships a build feature to the production API,
      which the rails close outside a recorded approval. It is Joseph's call, not a patch.
    AIOE AND TENANT MISSION TAGGING MAY BE CORRECTLY EMPTY. They read decision history and production holds 11
      candidates. Check the precondition before forcing a run; an empty result there is not a defect.
    THE VOCABULARY DECISION GATES NOTHING TECHNICAL and should still be made first, because every entry written
      after it inherits whichever names win.

## RECONSTRUCTION ENTRY, 29 July 2026, recovery session after an unplanned restart

WHY THIS REPLACED A HANDOFF. The block that stood here was the 29 July late handoff, and it had gone
STALE IN THE SAME WAY THE ONE BEFORE IT DID, for the third time in this ledger. It said the Phase 2
close was blocked on a topology decision and that GATE_E.md was not written. Commit f3e4334, made at
06:54 that morning AFTER that handoff was committed at 00:12, superseded both statements: the trial ran
through the genuine intake, gates A through D passed, and GATE_E.md exists. A fresh session reads the
top of this file first, so the stale block was again the one most likely to be believed. Replaced, not
appended, because two handoffs in one ledger is one handoff too many.

THE RECURRENCE IS THE POINT. Twice now a session has written a handoff, kept working, and left the
handoff describing a world that no longer existed. The durable fix is not another cleanup: a handoff
must be the LAST write of a session, or it must not be written at all.

WHAT WAS RECONSTRUCTED, all verified by command against the live systems
  Repository /Users/josephanady/missionmatch, branch feature/opportunity-to-outcome, HEAD f3e4334,
    397 commits, working tree CLEAN, stash EMPTY. Nothing uncommitted existed, so nothing needed a
    ledger note for stashed work.
  Phase 2 remains the one current phase. Phase 3 NOT started.
  Standing order item 1, PACKAGE ACQUISITION: ALREADY DONE AND STILL INTACT. Re verified remotely.
  Standing order item 2, D6 CODIFICATION: ALREADY DONE IN FULL, all six required elements present.
  Standing order item 4, THE PHASE 2 CLOSE: ALREADY DONE by f3e4334.
  Standing order item 3, FAIRNESS SNAPSHOT DEPLOY AND STORAGE: STILL NOT DONE, as recorded.
  Standing order item 5, THE CONDITIONAL CLOSE: CANNOT FIRE. It is conditioned on zero open findings
    and zero new deviations, and this session opened two findings. The pre approval does not cover them
    by its own terms.

D6 AND THE CREDENTIAL RE VERIFICATION CONDITION. The standing order says to re verify every D5 consumer
IF D6 shows open or partially codified. It shows CLOSED and fully codified, so the condition did not
fire on the LEDGER. It should have fired on REALITY: the consumers were checked anyway as part of
production health and two of them are broken. Finding D7 below. The lesson is that a condition written
against the ledger cannot catch a divergence between the ledger and the running system.

FINDING D22, THE WAGE BRIDGE IS BROKEN IN THREE WAYS AND ONE EXISTING COMMAND WOULD MAKE IT WORSE | 29 July
2026, found while starting the list, before running anything. This corrects the business fit review above,
which named two broken sides. There are three, and the third is the one that matters.

  SIDE ONE, KNOWN. skills.soc_code is BLANK on all 397 rows.
  SIDE TWO, KNOWN. ontology_crosswalk is EMPTY and NO code writes it. Migration 0021 creates it and grants
    SELECT to the app and that is all that has ever touched it.
  SIDE THREE, NEW, AND IT INVALIDATES THE OTHER TWO FIXES. THE CODE SPACES DO NOT MATCH.
    bls_wages.occupation_code is a SIX DIGIT SOC CODE WITH NO HYPHEN, 825 distinct values from 111011 to
      537199. That is SOC 11-1011 written as 111011.
    The O*NET codes in ontology_terms are CONTENT MODEL DESCRIPTOR IDs: 1.A.1.a.1, 2.B.5.d, 2.C.9.b. Measured:
      of 108 coded O*NET rows, ZERO are SOC shaped and 108 are not.
    So an O*NET descriptor identifier can never join to an OEWS occupation code. They are different code
    spaces that happen to share a column name.

  THE TRAP I ALMOST WALKED INTO. cmd/promote-ontology pass 3 does
    INSERT INTO skills (name, category, source, soc_code) SELECT ... ot.code ... WHERE source_name = 'O*NET Web
    Services' AND source_record_id LIKE 'onet-tech:%'
  and its own comment says the soc_code column stores the O*NET code FOR LATER CROSSWALK USE. Running it today
  would write O*NET TECHNOLOGY DESCRIPTOR CODES into a column named soc_code. skills.soc_code would go from
  honestly empty to CONFIDENTLY WRONG, the crosswalk join would still match nothing, and the bridge would
  report as populated while being broken. That is the exact failure mode of this entire week, one step from
  being committed to production, and it was caught only by comparing the two code spaces before executing
  rather than after.
  SO promote-ontology IS NOT SAFE TO RUN until the code space question is settled, and task 19 must not treat
  it as a routine run. Its other two passes, corpus mined skills and mission spine terms, do not touch
  soc_code and are unaffected.

  WHAT THE CROSSWALK IS ACTUALLY FOR, and it is well designed. Its columns are from_system, from_code,
  to_system, to_code, relation, source_name, synced_at. That is a GENERAL CODE SPACE BRIDGE, exactly the right
  shape for this problem. It was built for this and never filled.

  THREE MORE GAPS THE SAME QUERY EXPOSED, all in the ontology
    O*NET skill terms: 2782 rows and only 33 CARRY A CODE. 2749 coded nowhere.
    Market Extraction skills: 269 rows, ZERO codes.
    GSA CALC labor_category: 20 rows, ZERO codes. This one stings, because GSA CALC is a LABOR CATEGORY RATE
      source and labor category is the unit the whole bill rate conversation happens in.

  WHAT CLOSING THIS ACTUALLY REQUIRES, in order
    1. Pick ONE canonical SOC form and normalize on write. bls_wages already uses the six digit no hyphen
       form and holds 825 of them, so it is the incumbent and should win.
    2. Fill ontology_crosswalk from an authoritative SOC keyed source, mapping SOC to labor category, to
       O*NET occupation, and to skill. The table shape already supports all three via from_system and to_system.
    3. Only then fill skills.soc_code, with real SOC OCCUPATION codes, and fix promote-ontology pass 3 so it
       stops writing a descriptor code into a column named soc_code. Either rename that column to onet_code and
       add a real soc_code, or stop populating it there.
    4. A POSITIVE CONTROL THAT CANNOT PASS VACUOUSLY: assert that a named labor category resolves to a SOC code
       AND that the SOC code returns a non empty OEWS wage row. A count of crosswalk rows proves nothing, which
       is what side three teaches. | this commit | 2026-07-29
GENERATOR TO DATA MAP, AND THE OVERLAP GAP, 29 July 2026. Joseph supplied the augmentation taxonomy, 37 named
patterns, and said the knowledge and the databases must be wired to the CORRECT generators WITH OVERLAP to make
one complete intelligence. This entry maps every pattern that has a home here to the data behind it, names the
ones with no home, and states the one architectural gap that stops the parts from being one thing.

FIRST, A VOCABULARY COLLISION THAT MUST BE SETTLED BEFORE ANY WIRING
  Joseph's list reads MAG as MEMORY augmented generation and TAG as TOOL augmented generation.
  THIS CODEBASE ALREADY USES BOTH ACRONYMS FOR DIFFERENT THINGS, in 11059 lines, in a boot validated Registry,
  and in a DATABASE CHECK CONSTRAINT:
    MAG here is MODEL augmented generation. mag.go: the fourth augmentation class after RAG, TAG and GraphRAG.
      It is bound to aedt_learned_models.output_kind, which is a CHECK constraint and an AEDT compliance
      artifact, so the name is load bearing in the audit trail, not just in comments.
    TAG here is TABLE augmented generation. tag.go: answers questions that require the database to COMPUTE.
  AND THE THING JOSEPH CALLS MAG EXISTS HERE UNNAMED: ai_memory, 287 rows all embedded, per tenant episodic and
  semantic memory in memory.go.
  RECOMMENDATION, and it is a recorded decision to make rather than a thing to assume: KEEP the code names as
  canonical and document Joseph's names as aliases. Renaming MAG would touch a CHECK constraint and the AEDT
  inventory, which is a compliance surface, to gain nothing a mapping table cannot give. Whichever way it goes,
  ONE vocabulary must win in writing, because two meanings for one acronym in one system is exactly the drift
  that produced the UI failure code mismatch and the declared but never written audit action this week.

WHAT ALREADY HAS A HOME, with its real data and its real state
  LIVE AND FED
    RAG               AnswerRAG plus retrieval.go. opportunity_records.embedding now 6902 of 6902,
                      candidates.resume_embedding, document chunks 836 in staging.
    Hybrid RAG        tsvector plus pgvector fused by RECIPROCAL RANK FUSION, already present in retrieval.go,
                      orchestrator.go, candidates.sql.go and eval/metrics.go. The fusion primitive EXISTS.
    Multi hop RAG     the recursive CTE traversals in the graph planes, each with a hard depth cap, a visited
                      path cycle guard and a total order tiebreaker.
    GraphRAG, GAG     nine planes G1 to G9. Fed unevenly: award_incumbent_roles 77 as of tonight,
                      skill_relationships only 11, ontology_crosswalk 0.
    Reasoning AG      the same planes. Deterministic cited traversal is this build's reasoning surface.
    TAG, SQL AG       the 35 intent closed Registry, parameterized, RLS scoped, allowlisted, boot validated.
    MAG as model      aedt_learned_models 12, coefficients 101, four families, promotion gated on eval-model
                      plus a human.
    MAG as memory     ai_memory 287, all embedded.
    OAG, KAG          ontology_terms 8011 (skill 3066, psc_code 2540, ksa 2286, cert 57, work_role 42,
                      labor_category 20), term_expansions 204, skill_aliases 17.
    Domain AG         bls_wages 1670 OEWS rows, usaspending_awards 538, the missionclass classifier.
    Verifier AG       citation per clause, quote hash grounding, ValidateScopeCandidates rejecting a quote not
                      present verbatim, the faithfulness endpoint, vectorguard on the vector space.
    Policy AG         safety.go read allowlist, forced RLS, ForbidEEO, the AEDT output_kind CHECK.
    Privacy AG        scrub egress classes, small cell suppression floor k, eeo schema isolation.
    Human AG          slate approval, curation approve and verify, champion promotion. THE STRONGEST ONE HERE,
                      and the one most products lack.
    Agentic, PAG      planner.go, 841 lines, RoutePlan.
    Adaptive RAG      Classify(), rule based over question shape. A trained classifier is the documented upgrade.
    Federated AG      internal/platform/federated, 633 lines, plus the public mm-recall edge.
    Event AG          the substrate is there and UNUSED AS A GENERATOR: outcome_events 1411,
                      application_stage_events 1382, requisition_events 1188, audit_logs 56577.
  BUILT BUT STARVED
    CAG               knowledge.go holds curated cards; production serves ZERO and /knowledge is 404.
    Feedback AG       teaching.go and teach-aggregate exist; teaching_signal_aggregates 0, curation_proposals 0.
    Simulation AG     cmd/aioe-sim exists and has never been run.
    WAG               sam-sync and the attachment mining are real; the 2625 notice bodies are still unfetched.
  NO HOME, and most of these absences are CORRECT for this domain
    TAG as tool, AAG, Program AG   no tool calling or code execution layer. Given the no Python rule and the
                                   AEDT posture, adding one is a policy decision, not a gap to fill quietly.
    Critic AG                      there is a verifier and no adversary. The verifier checks grounding; nothing
                                   argues the answer is wrong. This is the most valuable missing one.
    Multimodal, VAG, Sensor AG     not applicable, with ONE exception: a scanned wage determination needs
                                   vision, which is exactly candidate P2 in IMPROVEMENTS.
    Schema AG                      implicit rather than absent: sqlc compiles the SQL against the schema and
                                   the Registry is schema bound.

THE ONE ARCHITECTURAL GAP: THE ROUTER IS EXCLUSIVE, AND INTELLIGENCE NEEDS IT TO BE COMPOSITIONAL
  orchestrator.go Answer() is a chain of early returns and a final switch. It selects EXACTLY ONE generator per
  question: AnswerGraph, or AnswerPlan, or AnswerRAG, or AnswerDirect, or refuse. There is one compositional
  escape hatch, AnswerPlan, and it fires only when isCompoundQuestion sees a conservative keyword signal, and
  even then it composes only WITHIN the closed Registry. It never composes RAG with a graph plane with the wage
  domain with a learned model with a knowledge card.
  SO OVERLAP TODAY IS ACCIDENTAL, NOT DESIGNED. And overlap is not redundancy: two independent generators
  agreeing is EVIDENCE, and two disagreeing is a FLAG. That is the same principle as every positive control in
  this build, applied to answers instead of instruments.
  THE RECRUITER'S REAL QUESTION PROVES IT. "Can we bid this and staff it profitably" needs, in one answer:
  WAG to fetch the notice, document RAG over the PWS chunks, OAG to map labor categories to SOC, Domain AG for
  the wage determination floor and the OEWS band, TAG for bench counts, GraphRAG for clearance reachability and
  the incumbent, MAG for capture readiness, Verifier for citations, and Policy plus Privacy throughout. NINE
  generators. Today that question routes to ONE, and whichever one wins, the answer is confidently partial.
  WHAT TO BUILD, and RRF is already here so the primitive is not the problem: a composition layer that fans a
  question to the generators whose preconditions it satisfies, collects CITED evidence from each, fuses by RRF,
  and scores AGREEMENT, with a critic that must attempt to refute the composed answer before it is served.
  Disagreement surfaces as a stated uncertainty rather than being averaged away.

NOT A DECISION YET. This is a proposal and a map. docs/ARCHITECTURE.txt is untouched, correctly, because its
revision protocol admits exactly four moments and a proposal is not one of them. | this commit | 2026-07-29
BUSINESS MODEL FIT REVIEW, 29 July 2026, ordered by Joseph before proceeding further with the intelligence
layer: is it learning the RIGHT things for a company and a recruiter to see open federal contracts, understand
them, and fill the roles. Researched against outside sources, then measured against the actual schema. Every
schema number below is a query result, not a reading of the code.

HOW A FEDERAL STAFFING AGENCY ACTUALLY MAKES MONEY, from the research
  THE BILL RATE IS THE WHOLE BUSINESS. It funds, in order: the worker's pay, the employer burden on that pay
  (payroll taxes, insurance, benefits), overhead and recruiting cost, and only then margin. Contract and temp
  markups run 30 to 75 percent; permanent placement runs 10 to 20 percent of first year salary; a 25 percent
  gross margin is a common target. Gross margin is bill rate minus pay rate MINUS BURDEN.
  IN GOVCON THE NUMBER IS THE WRAP RATE. Bill rate equals pay times wrap, where wrap carries fringe, overhead,
  G and A, and fee. Price to win is a wrap rate argument.
  CLEARED TALENT CARRIES A PREMIUM: average cleared compensation about 119,131 dollars, up roughly 4 percent to
  an all time high, with demand exceeding supply.
  THE SCA WAGE DETERMINATION IS A LEGAL FLOOR, not a market datapoint. DOL issues a determination per labor
  category per locality for service contracts over 2,500 dollars. THE EMPLOYER BEARS THE BURDEN of mapping each
  employee to the correct category, and when a determination is revised the contractor must submit a PRICE
  ADJUSTMENT to recover the cost.
  KEY PERSONNEL ARE A COMPLIANCE ARTIFACT, not a nice to have. Named key personnel, their resumes, signed
  letters of commitment stating position, level of effort and period of performance, and availability
  statements have been treated in GAO bid protest decisions as MATERIAL solicitation requirements. Omission can
  render a proposal unacceptable. Contingent offers must be explicitly contingent on award, customer approval,
  and continued eligibility.
  THE OPERATING KPIs: submit to interview about 3 to 1, time to fill about 44 days, fill rate above 80 percent
  with below 80 treated as a warning, plus submittals per recruiter, offer acceptance, 90 day retention, cost
  per hire.

WHAT THIS BUILD ALREADY HAS, and it is most of the shape
  THE FULL LIFECYCLE EXISTS AS TABLES: requisitions to applications to application_stage_events to interviews
  to offers to placements, alongside slates and slate_members for proposal staffing, bid_outcomes,
  vendor_submissions, staffing_vendors, recruiter_activities, outcome_events.
  STAGING PROVES IT HAS BEEN EXERCISED: requisitions 1082, requisition_events 1188, applications 677,
  application_stage_events 1382, interviews and offers and placements present, slate_members 2070,
  candidate_evaluations 1777, bid_outcomes 1220, vendor_submissions 1385, recruiter_activities 612.
  THE MONEY FIELDS EXIST AT THE RIGHT GRAIN: requisitions carry bill_rate_min/max, pay_rate_min/max,
  salary_min/max; offers carry bill_rate, pay_rate, salary, fee_pct; placements carry bill_rate, pay_rate,
  salary, fee_amount; requirement_drafts carry bill_rate_min/max and pay_band_min/max.
  THE CAPTURE SIDE EXISTS: contract_vehicle, incumbent_name and incumbent_uei on opportunity_records for
  recompete positioning, an agency buying pattern graph plane, a capture readiness champion model with a
  documented GO/REVIEW/NO_GO threshold, and bls_wages holding 1670 OEWS rows behind the M5 price to win plane.

THE GAPS, in business impact order. Every one verified by query.

  GAP 1, THERE IS NO WRAP RATE, BURDEN, FRINGE, OVERHEAD, G AND A, OR INDIRECT COLUMN ANYWHERE. Zero.
    My first regex reported three matches and all three were FALSE POSITIVES: uploaded_by_user_id matched on
    "loaded", and signal_value and source_signal matched on "gna" inside "signal". Named and checked, the true
    count is ZERO.
    CONSEQUENCE, and it is the most important sentence in this entry: bill_rate minus pay_rate is a SPREAD, not
    a gross margin. Without burden the product cannot tell a recruiter whether a placement makes money, and it
    cannot produce a defensible price to win, because price to win in GovCon is a wrap rate argument. The
    system can currently show a number that LOOKS like margin and is not one. That is the same class of defect
    as every instrument this week that reported a clean result while measuring something adjacent.

  GAP 2, THERE IS NO SCA WAGE DETERMINATION MODEL AT ALL. Zero tables and zero columns matching wage
    determination, sca, wd_number or wd_rev.
    AND IT COMPOUNDS WITH FINDING ONE: the one document class the extractor cannot read is the SCA wage
    determination, whose text layer carries no usable character map. So the legal floor under every bill rate on
    a service contract is neither modelled nor readable. There is also no mechanism for the price adjustment
    that follows a revised determination, which is money the contractor is entitled to and would simply not
    claim.

  GAP 3, THE BRIDGE FROM A LABOR CATEGORY TO WAGE DATA IS BROKEN ON BOTH SIDES.
    bls_wages is keyed by occupation_code, a SOC code. skills carries a soc_code column on all 397 rows and it
    is BLANK ON EVERY ONE, 0 non blank. ontology_crosswalk, which G3's skill gap bridge joins with
    ox.from_code = req.soc_code, is EMPTY.
    So even if the crosswalk were populated tomorrow the join would still match nothing, because there are no
    SOC codes to join to. Two empty sides of one bridge, and it is why the price to win plane cannot reach real
    wages for a given skill. Fixing either alone accomplishes nothing, which is worth knowing before someone
    fixes one and reports progress.

  GAP 4, KEY PERSONNEL IS A SINGLE BOOLEAN. requirements.key_personnel, and nothing else: no letter of
    commitment record, no signed status, no level of effort, no period of performance, no availability
    statement, no contingent offer state. Given that GAO treats these as material solicitation requirements,
    a proposal staffing product that cannot track whether the LOC is signed is missing the artifact that
    decides whether the proposal is acceptable at all.

  GAP 5, THE INPUTS THAT WOULD FILL ALL OF THE ABOVE ARE STILL UNREAD. Labor categories, quantities, clearance
    levels and certifications live in the PWS and the SOW, and the notice body has never been fetched while the
    attachment corpus is only now being mined nightly. solicitation_extractions already holds 2457 rows with
    labor_category, required_clearance, required_skills, required_certifications and required_years, grounded to
    2457 distinct opportunity_records, and NO CODE READS IT. That is the shape of the answer sitting unused.

WHAT I AM NOT CLAIMING. This is a fit review against outside sources and the schema. It is not a customer
discovery interview, and Joseph knows this market far better than a web search does. Where the research and his
experience disagree, his experience wins and this entry should be corrected by name rather than quietly edited.
| this commit | 2026-07-29
INTELLIGENCE ACTIVATION, 29 July 2026, on Joseph's order that all of it be fixed and that it be learning and
growing from SAM.gov and using what it has learned. THE HEADLINE: this was overwhelmingly a RUN problem, not a
BUILD problem. Every dark item but two already had a command built for it, and none of those commands had ever
been run in production. That is why the intelligence looked absent while being present.

WHAT WAS ACTUALLY RUN AND VERIFIED TONIGHT, in production

  1. THE CORPUS IS NOW FULLY EMBEDDED. 6902 of 6902 opportunity_records, up from 6535. 367 backfilled.
     GUARDED FIRST, because embedding with the wrong model silently corrupts the vector space and there would
     be no error to see: cmd/verify-vector-model compared stored vectors against fresh embeddings of the same
     text and returned cosine 1.000000 on five samples, PASS at qllama/bge-small-en-v1.5 dim 384. Only then
     was the backfill run, with -only-missing so it could touch nothing that already had a vector.
     VERIFIED AFTER, three ways: 0 rows still missing, 6858 DISTINCT non zero vectors so nothing was zero
     filled, and a nearest neighbour query seeded from an elevator record returned three Elevator
     Modernization notices first. The vector space answers.

  2. THE FEDERAL SIGNAL CLASSIFICATION PASS RAN FOR THE FIRST TIME. cmd/missionclass-sync, WS7.
     federal_mission_tags 0 to 84. award_incumbent_roles 0 to 77. 10065 records scanned, which is exactly
     6902 opportunity_records plus 2625 sam_opportunities plus 538 usaspending_awards.
     AND IT MINES SAM ATTACHMENTS ITSELF, which corrects D20 again: it fetches the attachment package,
     extracts text, and classifies from it, bounded by -max-attachments to protect the SAM quota. First pass
     50 notices, second 300, and a full pass over the remaining 2325 is running in the background.
     It also names what it cannot read rather than guessing, logging skipped unreadable attachments per
     record, which is the same honesty posture as the Phase 2 extractor.

  3. IT NOW LEARNS ON A SCHEDULE INSTEAD OF WHEN I RUN IT. mm-missionclass.timer installed and enabled on
     Bubbles, nightly at 04:20 with a 600 second jitter, ExecStart capped at 300 attachments per run. The cap
     is deliberate: the job is idempotent and self limiting, so a nightly cadence works through the backlog
     instead of spending a whole day's SAM quota in one pass and failing the rest of the way through. It runs
     AFTER the nightly SAM sync so it classifies what arrived tonight, not what arrived yesterday.
     The unit carries TWO EnvironmentFile lines and ZERO inline Environment= lines, so no credential is
     embedded and none is passed as an argument. The out of repo secret sweep from finding four picked the new
     unit up automatically, because its scope is a glob over /etc/systemd/system/mm-*.service, and reported
     15 of 15 scopes clean. That is the sweep earning its keep on a unit written after it.

WHAT REMAINS, split honestly into runs and builds

  RUNS, the command exists and has never been run in production
    teach-aggregate            the WS8 teaching loop cadence. teaching_signal_aggregates 0, curation_proposals 0.
    aioe-backfill, aioe-run    converts decision history to outcome_events, then one deterministic AIOE pass.
                               All three aioe tables are 0. Production has almost no decision history, so this
                               one may be correctly empty until tenant data exists. Check before forcing it.
    tag-missions               tenant mission tagging. Same caveat: production holds 11 candidates.
    ontology-sync,             grow the ontology further from free federal sources and O*NET.
      promote-ontology
    train-model, eval-model    retrain on the grown corpus, then the promotion gate. Do NOT promote a champion
                               without eval-model passing the ranking and four fifths gates AND a human.
    brain-probe                stress tests the LIVE brain end to end. Run it LAST, as the acceptance check.

  BUILDS, small, and nothing does them today
    A. FETCH THE NOTICE BODY. 2625 description_url values, every one 94 characters and http prefixed. The
       column is stored, selected and upserted and NEVER FETCHED. This is the single highest ratio of value to
       risk left: it turns 168 bytes of header per notice into real notice text for the embedder, the
       classifier, and REQUIREMENT_NORMALIZE.
    B. WRITE ontology_crosswalk. It is READ by G3's skill gap bridge, which joins it on soc_code, and it is
       allowlisted in safety.go, and NO code writes it. So G3's taxonomy bridge traversal has nothing to walk.

  AND THREE SMALL FIXES
    C. Mount /api/knowledge/manifest and /api/knowledge/cards. Both 404 in production.
    D. Teach the curated CAG cards into production. /api/mm-recall is live and returns
       {"results":[],"count":0} for an ordinary query.
    E. FIX THE mm-recall CONTROL. Its documented guarantee is that a protected attribute query returns no
       cards. That cannot be distinguished from an empty knowledge base, and today the base IS empty, so the
       control passes while proving nothing. It must assert that an ORDINARY query returns cards in the same
       run that asserts a protected attribute query returns none. Do this WITH D, not after it. | this commit | 2026-07-29

INTELLIGENCE LAYER INVENTORY, 29 July 2026, ordered by Joseph after he said the build already has its own
intelligence and that two days had been spent drifting. He was right on both counts. This is a full scan of
every file and every database, and it CORRECTS finding D20 above, which was written from the production tenant
alone and drew the wrong conclusion from a half empty database.

WHAT IS BUILT. internal/modules/ai is 11059 lines, the LARGEST module in a 112469 line Go codebase, and it is
a complete augmented generation architecture, not a wrapper around a model call.
  SIX ROUTES the orchestrator chooses between: refuse (eeo and injection), tag (the database computes), rag
    (retrieve and narrate), direct (CAG, answer from stable rules with no retrieval), graph (walk a cited
    evidence path), plan (bounded plan and execute over the closed Registry).
  FOUR AUGMENTATION CLASSES: RAG, TAG, GraphRAG, MAG. MAG is model augmented generation, the fourth class.
  NINE NAMED GRAPH PLANES, each a reviewed static SQL constant with a depth cap, a cycle guard and a total
    order tiebreaker: G1 market and relationship, G2 vendor co occurrence and teaming, G3 skill and role
    adjacency, G4 bench, G5 clearance lattice, G6 the integrated capture loop, G7 agency buying pattern,
    G9 recompete lifecycle and foresight, M5 price to win on real BLS OEWS wages.
  35 INTENTS in ONE closed Registry, tag.go:112 to 585, asserted at boot by ValidateRegistry from
    cmd/api/main.go:367. 11 of them are MAG model intents.
  THE AEDT GUARDRAIL HOLDS IN THE TYPE SYSTEM. A MAG intent may emit exactly three output kinds,
    opportunity_score, display_order, confidence. A candidate score is impossible to register, impossible to
    store because it is also the CHECK on aedt_learned_models.output_kind, and impossible to emit. The frozen
    v1.4.0 engine stays the only per candidate scorer.
  Plus a planner, a teaching and curation loop, per tenant episodic and semantic memory, a vector model guard,
    small cell suppression, mission scoping, capture readiness, vendor intelligence, and a one way public
    knowledge feed.

WHAT IS TRAINED, in the PRODUCTION tenant, all exact counts
  aedt_learned_models 12, aedt_model_versions 5, aedt_model_coefficients 101.
  FOUR MODEL FAMILIES, all fit by cmd/train-model on real labels, not placeholders:
    opportunity_win_probability   logistic, champion v1, prior only, intercept is the logit of a defensible
                                  0.60 federal recompete base rate
    requirement_time_to_fill      discrete hazard, champion v1, challengers v2 to v4 fit over 415 requirements
    opportunity_capture_readiness weighted scorecard, champion v1, factor weights 0.35/0.30/0.20/0.15,
                                  GO at 0.65, REVIEW 0.45 to 0.65, NO_GO below
    slate_display_order           pairwise logistic, champion v6, fit over 46 decided slates and 2316 approved
                                  over rejected pairs, ridge l2=1. Earlier fit used 93 slates and 1138 pairs.
  Champion promotion is gated: challengers sit champion=false until cmd/eval-model passes the ranking and four
  fifths gates AND a human promotes. That gate is real and is holding.

THE DATA SUBSTRATE, PRODUCTION, exact
  audit_logs 56577, ontology_terms 8011, opportunity_records 6902 with 6535 EMBEDDED, sam_opportunities 2625,
  solicitation_extractions 2457, bls_wages 1670, usaspending_awards 538, ai_memory 287 ALL embedded,
  skills 267 ALL embedded, term_expansions 204, aedt_model_coefficients 101, mission_areas 10, mission_spine 10,
  skill_aliases 17, skill_relationships 11. 41 of 86 tables populated.
  ontology_terms by kind: skill 3066, psc_code 2540, ksa 2286, certification 57, work_role 42, labor_category 20.

THE CORRECTION TO D20, AND IT IS A BIG ONE. STAGING IS WHERE THE SYSTEM ACTUALLY LIVES.
  staging: candidates 8872, organizations 2814, users 1105, slate_members 2070, candidate_evaluations 1777,
    candidate_skills 1515, outcome_events 1411, vendor_submissions 1385, application_stage_events 1382,
    bid_outcomes 1220, requirements 1184, requisition_events 1188, requisitions 1082, applications 677,
    recruiter_activities 612, slates 496, aedt_model_coefficients 433, skills 397,
    AND opportunity_document_chunks 836.
  production: candidates 11, organizations 1, users 7, requirements 6, slates 13, document chunks 0.
  SO THE PHASE 2 DOCUMENT PIPELINE IS NOT DARK. It has 836 chunks in staging. What is empty is PRODUCTION,
  and production is empty of TENANT data generally, not of documents specifically. D20's headline, that the
  document pipeline has processed nothing, is true only of production and reads as though it were true of the
  build. Withdrawn as stated and restated here.

WHAT IS GENUINELY DARK, and this is the useful list
  1. THE PUBLIC KNOWLEDGE BASE IS EMPTY IN PRODUCTION. /api/mm-recall is LIVE and unauthenticated by design,
     a contents free federation edge, and it returns {"results":[],"count":0} for an ordinary query. The
     curated CAG cards in knowledge.go were never taught into production. Worse, the documented control that a
     protected attribute query returns no cards CANNOT DISCRIMINATE while everything returns no cards. That is
     the same failure mode as every other instrument caught this week.
  2. /api/knowledge/manifest and /api/knowledge/cards return 404 in production. Not mounted.
  3. solicitation_extractions holds 2457 rows grounded to 2457 distinct opportunity_records, 2163 of them ok,
     carrying labor_category, required_clearance, required_skills, required_certifications and required_years,
     AND NO GO CODE REFERENCES THE TABLE AT ALL. Only migration 0060 mentions it. Written by code that no
     longer exists, read by nothing. That is extracted intelligence, orphaned.
  4. The teaching loop is dark in production: teaching_signal_aggregates 0, curation_proposals 0.
  5. AIOE is dark: aioe_runs 0, aioe_weight_profiles 0, aioe_weight_adjustments 0.
  6. ontology_crosswalk is 0, so G3's skill gap bridge traversal has no crosswalk taxonomy to walk.
  7. Mission tagging is dark: candidate_mission_tags 0, requirement_mission_tags 0, federal_mission_tags 0,
     even though mission_areas and mission_spine each hold 10 curated rows.
  8. 367 of 6902 opportunity_records carry no embedding.
  9. The two unfetched link sets from D20 still stand and are still the deepest gap in the MARKET corpus:
     2625 notice description URLs and 5363 attachment links, none ever followed. Verified again: every
     description value is 94 characters and begins with http, so no notice body has ever been fetched.
  10. nginx reports 34 CONFLICTING SERVER NAME warnings across the vhost set, caused by backup files left
     inside sites-enabled where the glob loads them. missionmatch.thatwebhostingguy.com has such a .bak
     sibling. Not a missionMATCH defect and it affects missionMATCH.

WHAT I GOT WRONG, named so it is not repeated
  I probed the brain against missionmatch.thatdevpro.com, which is not the hostname, got 000 on every route,
  and was one sentence away from reporting the brain unreachable in production. The real host is
  missionmatch.thatwebhostingguy.com and /api/ai/query answers 403, meaning MOUNTED AND AUTH GATED. Caught by
  running a control first: / answers 200 and /api/auth/session answers 403. A check with no control is a
  rumour.
  I also read the first inventory off pg_stat_user_tables.n_live_tup, which reported skills 0 and
  ontology_terms 0 when exact counts are 267 and 8011. Stale planner statistics. Every number above is an
  exact count(*), taken through query_to_xml per table. | this commit | 2026-07-29

FINDING D20, THE INTELLIGENCE LEARNS FROM HEADERS, AND THE DOCUMENTS IT WAS BUILT TO READ ARE UNREAD IN
PRODUCTION | 29 July 2026. Found by measuring the ingest and embed loop after Joseph pointed out that the whole
point is to ingest SAM.gov, embed it, and grow from it. He was right, and the measurement is worse than the
question implied. Every number below is from the PRODUCTION tenant, read only.

WHAT IS GENUINELY GROWING, and it is not nothing
  opportunity_records   6902 rows, 6535 EMBEDDED, 94.7 percent
  ontology_terms        8011
  skills                267, ALL embedded
  ai_memory             287, ALL embedded
  sam_opportunities     2625 notices cached
  So the market scale ingest and the vector substrate are real and working.

WHAT IT IS LEARNING FROM, measured rather than assumed
  The deepest text any SAM notice contributes is 75 to 445 BYTES, average 168, composed from the flat metadata
  columns: title, department, sub agency, notice type, NAICS, PSC, set aside, place of performance. That is a
  HEADER. It is not a solicitation.

WHAT IS SITTING IN THE DATABASE UNREAD, with the pointers already stored
  2625 notice DESCRIPTION URLS. The cache column is description_url and the raw jsonb description key is also a
    URL, verified: all 2625 values are exactly 94 characters and every one begins with http. The notice BODY
    has never been fetched. One HTTP GET per notice would produce it.
  5363 ATTACHMENT LINKS across 1484 notices, all URL shaped, none ever followed.
  RESULT: opportunity_documents 0. opportunity_document_chunks 0. opportunity_scope_items 0. ZERO.

SO THE ENTIRE PHASE 2 DOCUMENT PIPELINE HAS PROCESSED NOTHING IN PRODUCTION. Table extraction, the readability
bar, chunking, provenance born at origin, the amendment diff, the split and merge, the draft generator. All of
it is PROVEN, on the real Package A and Package B, in STAGING. In production it has no fuel, because nothing
follows either of the two link types the database already holds. Only 1 opportunity is tracked, and tier one
attachment sync is track driven by design, so it can only ever pull for what a customer already found.

THIS REFRAMES FINDING THREE ENTIRELY, and the reframing is mine to own. I spent an evening trying to make an
external model extract contract scope from 168 bytes of header metadata. Even had OpenAI answered, it would
have been reading "Elevator Preventive Maintenance. Department: VA. NAICS: 238290." That is why each of the
three notices yielded exactly ONE scope item and why the payloads were 237, 117 and 114 bytes. The bottleneck
was never the model. It was that the text was never fetched.

ALSO FOUND, smaller
  367 opportunity_records carry NO embedding, 6902 minus 6535.
  ontology_crosswalk is EMPTY, 0 rows, so the crosswalk has never been populated.

WHAT THIS IS AND IS NOT. It is NOT a defect in Phase 2's scope: the phase was to build the document pipeline
and the pipeline works. It IS the gap between a pipeline that works and a product that knows things, and it is
the same lesson already recorded as depth equals completeness. NOTHING WAS BUILT FOR IT IN THIS SESSION, and
nothing should be: it is a scope decision under a phase lock and it belongs to Joseph.

THE ORDER OF VALUE, if he wants it, cheapest and most local first
  1. Follow the 2625 description URLs. Local, no third party, no new dependency, turns 168 bytes per notice into
     real notice text for the embedder and for REQUIREMENT_NORMALIZE. This is the single highest ratio of value
     to risk available in this codebase right now.
  2. Follow the 5363 attachment links into the pipeline that already exists and is already proven. This is
     IMPROVEMENTS item 2, tier two the rolling corpus harvest, approved and NOT STARTED, and its recorded
     caveat stands: it needs a storage budget with a ceiling and a retention rule first, because Bubbles is at
     82 percent of a 221G root disk and the backups live on that same disk.
  3. Embed the 367 stragglers and populate ontology_crosswalk.
  None of the three needs an external model. | this commit | 2026-07-29

FINDING D19, THE EXTERNAL INFERENCE AUDIT ACTION WAS DECLARED AND NEVER WRITTEN | 29 July 2026, found while
executing finding three. ai.ActionExternalInference has existed since 27 July, and AllowExternal carried a
comment stating that binding the gate and the audit in one call means a caller cannot send without both.
THE BINDING WAS NEVER REAL. AllowExternal returned a map and trusted its caller to record it, and the only
caller in the codebase wrote that map to a LOG LINE and persisted nothing.
So the single class of call that physically leaves this machine was the ONLY class with no audit trail, for
two days, while FIVE UNIT TESTS PASSED. They passed because every one of them asserts the SHAPE OF A MAP. Not
one asked whether a row existed. This is the eleventh instance in this build of an instrument reporting a
clean result while measuring something adjacent to the thing it claims to measure.
FIXED. AllowExternalAudited gates and writes as ONE call and FAILS CLOSED: an external call whose audit row
cannot be written does not happen, which is the posture the auth module already takes for security events. The
row is written BEFORE the payload leaves, the only ordering an auditor can trust, because a row written
afterwards is missing exactly when the process dies mid call. RecordExternalOutcome then records WHICH backend
actually served, because the gateway falls back to the local runtime on failure and that fallback is invisible
in an audit trail that records only intent.
MUTATION CONTROLLED, four new tests: removing the write fails exactly the two that assert it and restoring it
turns them green. Also asserted rather than trusted: no insert argument carries the payload content, and a
refused payload writes NO row at all.
IT EARNED ITSELF IMMEDIATELY. The first run RecordExternalOutcome ever saw was the run it caught: three
outcome rows reading ollama:llama3.1:8b after OpenAI refused with insufficient_quota. Without it the run would
have read as three successful external calls forever, because accepted=3 rejected=0 and three cited scope
items is exactly what a successful external run looks like from here. | 52fcbb9 | 2026-07-29

FINDING D7, THE D5 ROTATION LEFT TWO CONSUMERS STALE AND PRODUCTION HAS HAD NO TENANT BACKUP FOR A DAY
Found by checking production health rather than by an alert, which is itself part of the finding.
  THE SYMPTOM: four units on Bubbles are in a failed state, mm-db-backup, mm-sam-sync, mm-awards-sync and
  mm-rates-sync, all four with ONE root cause, password authentication failed for user
  missionmatch_migrator against 100.94.8.94 port 5432, which is cluster 1, the production tenant.
  PROVEN BY ROLE NAME AND STATUS CODE, never by printing a DSN, per the D6 rule:
    api.env MM_MIGRATOR_DATABASE_URL    OK    missionmatch_migrator on missionmatch port 5432
    backup.dsn                          FAIL  password authentication failed
    sam-sync.env MM_MIGRATOR_DATABASE_URL FAIL password authentication failed
  So the ROLE IS FINE and its current password is the one api.env already holds. Two files hold a STALE
  COPY. This is the exact shape of finding D3, which was diagnosed the same way and fixed by correcting
  the stale copy rather than by rotating the role. Rotating here would break the working consumer.
  EVERY OTHER CONSUMER ON BOTH NODES IS HEALTHY, checked individually: api.env control plane app and
  compliance, staging.env staging_migrator and staging_app with the D6 isolation still holding, and on
  megamind-agi all four db.env roles, backup.dsn, api.env, and BOTH mm-identity-sync DSNs across BOTH
  clusters, which was the trap D6 named and it held. Identity sync ran clean at 16:04.
  THE IMPACT, measured from the backup directory and the journal rather than asserted:
    last COMPLETE backup set  28 July 16:42:58, tenant and staging, with its MANIFEST.sha256
    failed runs since         29 July 03:07:53, 06:00:06, 12:00:08, three consecutive
    left behind               three ZERO BYTE tenant dump files in daily/20260729/
    control plane and staging dumps for 29 July do not exist at all, because the script dies on the
      first dump and never reaches them
  So the largest recorded risk in the register, the absence of a backup, is LIVE right now and has been
  for roughly twenty four hours. The zero byte files are partials and must be removed, because a restore
  that finds them is a restore that reads a truncated dump.
  sam-sync.env IS NOT IN docs/CREDENTIAL_CONSUMERS.md. That file exists precisely to be complete, and D6
  rule nine says a consumer discovered outside it is a defect IN THE FILE to be fixed in the same change.
  backup.dsn IS listed and was still missed, so the rotation did not enumerate from the file it wrote.
  NOT FIXED, because it is a production configuration change and production scope is closed outside the
  approvals in the standing order. QUEUED for Joseph. It also BLOCKS both halves of standing order item 3:
  the deploy procedure requires a fresh backup of the affected cluster first, and the storage restore
  drill needs a backup to restore.

FINDING D8, THE FROZEN ENGINE DRIFT CHECK IS ANCHORED TO THE WRONG COMMIT, THE SECOND FAIL OPEN IN THE
SAME CHECK. The most load bearing check in the protocol is still not trustworthy as documented.
  MEASURED: the diff of internal/modules/matching/engine against the documented anchor 9e77f65 is 1476
  LINES, not zero. Against 864a999, 9 July, the last commit that legitimately touched the engine, it is
  ZERO. Against e74fd2e, 27 July, the first commit of this build, it is ZERO.
  THE CAUSE: 9e77f65 is dated 24 JUNE 2026 and titled Baseline, missionMATCH platform plus Phase 2
  Authentication and Accounts. It is the ORIGINAL PROJECT baseline, not the pre build baseline. The engine
  was legitimately developed after it, through ModelVersion v1.1.0 to v1.4.0 across 26 and 29 June, 1
  July and 9 July. A diff against 24 June therefore CANNOT be empty and never could have been.
  WHY THE PRIOR RUN REPORTED ZERO ANYWAY, and this is the part worth keeping: when the history purge
  rewrote every hash, the anchor was repointed to 9e77f65 and the check was reported as verified at zero.
  The real path against that commit yields 1476, so that zero did not come from this path and this
  commit. Several plausible engine paths DO NOT EXIST in the tree, internal/platform/scoring,
  internal/scoring, internal/engine and pkg/engine, and git diff against a path that does not exist
  prints nothing and exits zero. That is the identical fail open shape as the missing commit, one layer
  over: the first fix moved the failure from a nonexistent COMMIT to a nonexistent PATH.
  THE FREEZE ITSELF HOLDS, stated as plainly as the defect. The engine has not changed since 9 July,
  eighteen days before this build started. Nothing this build did touched it. Acceptance 23 is satisfied
  in substance and the artifact is intact. What failed is the instrument that proves it.
  THE REPAIR, queued rather than done because it changes a gate definition: anchor the check at e74fd2e,
  the build's own first commit, which states the claim the gate actually wants, that THIS BUILD changed
  nothing. Assert the anchor commit exists AND that the path exists and is non empty before trusting a
  clean result, because both have now failed open once each.

D7 CLOSED BY REPAIR, AND IT WAS THREE STALE CONSUMERS NOT TWO | 29 July 2026. JOSEPH'S APPROVAL, recorded
as the guardrails require: he approved the full repair, credentials plus partial cleanup plus a proven
backup, in answer to a proposal that named the config only scope and the absence of any ALTER ROLE.
  METHOD, deliberately the D3 method rather than a rotation: the role was never wrong, so the WORKING value
  already in api.env was copied into the stale files. Rotating would have broken the one consumer that
  worked. No ALTER ROLE, no cluster scoped object touched, so rule one did not apply.
  A THIRD STALE CONSUMER WAS FOUND DURING VERIFICATION, which is why the fix is not simply two files:
  sam-sync.env also carried a stale missionmatch_compliance password. It was not in the first diagnosis
  because the first probe only tested the migrator variable in that file. Found by widening the probe to
  every variable rather than the ones I expected to be wrong.
  PROVEN AFTER, by role name and status code, never by printing a DSN, eleven consumers across both nodes:
  backup.dsn OK, api.env migrator app compliance and tenant_acme all OK, sam-sync.env migrator AND
  compliance now OK, staging.env all three OK on their own database.
  ONLY THE INTENDED LINES CHANGED, proven not asserted: sam-sync.env stayed at 11 lines with 11 variable
  names, and a diff of the file EXCLUDING the changed line reported 0 differences, twice, once per repair.
  Originals backed up root owned 0700 before either write. Every write staged to /tmp and cp'd, because
  sudo tee truncates.
  D6 CONTAINMENT RE PROVEN, and MY OWN CHECK WAS WRONG FIRST. The first containment test reported
  "password authentication failed for user missionmatch_migrator", which looked like a pass and was not: my
  sed pattern matched the USERNAME inside the DSN, so it tested a role that does not own the staging
  password against the staging database and proved nothing. Corrected to substitute only the database after
  the port, after which missionmatch_staging_migrator against the PRODUCTION database is refused with
  "permission denied for database missionmatch", a privilege denial rather than an auth failure, which is
  the correct refusal and is what D6 built. Recorded because an instrument that lies in my favour is the
  thing this ledger exists to catch.
  THE BACKUP IS REAL AGAIN, which is the only proof that counts: mm-db-backup Result=success, tenant dump
  17209805 bytes, staging 2957058, control plane ingested 97184, manifest 3 artifacts and sha256sum -c OK
  on all three. Three zero byte partial dumps from the failed runs were deleted, size 0 only, and zero
  remain anywhere under the backup root. All four units reset, zero failed units.
  ALL THREE SYNCS PROVEN END TO END, not merely authenticated: sam-sync upserted 1420 with the store at
  2614 opportunities, awards-sync 525 with the store at 538, rates-sync 20 with the store at 1670.
  THE INVENTORY DEFECT FIXED IN THE SAME CHANGE per D6 rule nine: docs/CREDENTIAL_CONSUMERS.md gains both
  sam-sync.env rows, and records that one stale line there stops THREE units at once. It also records the
  harder lesson, that backup.dsn was ALREADY LISTED and was still missed, so a complete inventory is
  necessary and not sufficient. The rotation step that failed was step one, read this file, not a step
  that was absent.
  HOW LONG PRODUCTION HAD NO BACKUP, stated plainly: last complete set 28 July 16:42:58, first success
  after the repair 29 July 16:24:26, so roughly twenty four hours with three failed runs in between. The
  alerts DID fire, OnFailure was wired for all four units by the 28 July config deploy, so this was not
  invisible in the D2 sense. It was unread.

D8 CLOSED BY CORRECTION, AND THE SAME WRONG HASH WAS ALSO THE DEPLOY BASELINE | 29 July 2026, approved by
Joseph, anchor at e74fd2e.
  THE SECOND USE IS THE DANGEROUS ONE AND IT HAD NOT BEEN NOTICED. 9e77f65 was named in TWO live places:
  the frozen engine drift anchor AND the HOW TO DEPLOY worktree baseline that every production binary is
  built from. The engine anchor being wrong made a gate report a result it had not measured. The DEPLOY
  BASELINE being wrong would have silently REGRESSED FIVE WEEKS of shipped product work on the next
  deploy, including engine ModelVersion v1.4.0, the audit_logs row level security, and the identity sync
  host fix, because 9e77f65 predates all of them. Production is not affected: it runs 8f24414531e80a9a,
  built from the REAL 462eb81 before the purge. The next deploy would have been affected, and the next
  deploy is the fairness snapshot deploy in the standing order.
  THE TRUE PRE BUILD BASELINE IS 2178e72, 21 July, which matches this ledger's own description of 462eb81
  as the 21 July edition. e74fd2e is the build's first commit and adds ONLY a 145 line spec document over
  2178e72, so it is code identical to the true baseline, carries ZERO build feature files, and gives an
  engine diff of zero. One anchor is therefore correct for both uses and states the claim the gate wants.
  CORRECTED IN THE LIVE INSTRUCTIONS ONLY: BUILD_CONTINUATION_PROTOCOL Gate D, the BUILD_STATE deploy
  block, and three lines in ARCHITECTURE.txt. Historical narrative entries KEEP the hash they were written
  with, because they were already rewritten once by the purge and rewriting the record a second time to
  match a later understanding is falsification, not correction.
  THE CHECK NOW REFUSES INSTEAD OF PASSING QUIETLY. It asserts the anchor commit exists AND that the path
  is non empty at both ends before trusting a clean result. BOTH FAIL OPEN MODES DEMONSTRATED: a diff
  against a nonexistent commit prints 0 lines, and a diff against a nonexistent path prints 0 lines, each
  indistinguishable from success without the assertion. Detector proven live at 120 lines on a file that
  did change. The freeze itself always held: the engine is unchanged since 9 July.

SECTION 2.2 DONE, THE FAIRNESS SNAPSHOT PRODUCTION DEPLOY | 29 July 2026, under the standing order's
approval. Fresh backup first, taken 16:24:26 with its manifest verified, per the deploy procedure.
  A FOURTH D5 CONSUMER FOUND, AND IT IS NOT A FILE. migrate-all-tenants fans out to each tenant by REUSING
  the control plane migrator CREDENTIAL against the tenant's own host, which works only while the two
  clusters' migrator passwords are IDENTICAL. The D5 rotation changed cluster 1 and not cluster 2, so the
  fan out died with a SASL auth failure on the tenant database while the control plane leg was fine. The dry
  run caught it before any write, which is what the dry run is for.
  FIXED WITH THE TOOL'S OWN DOCUMENTED MECHANISM, not by re coupling the clusters:
  MM_TENANT_MIGRATOR_DSN_TENANT_ACME added to db.env on the control plane node. tenantDSN's own comment
  names this exact case, a tenant whose migrator credential differs because of a rotated password. The
  alternative, making the two passwords match again, would have restored the cross cluster coupling that
  caused D6, so it was deliberately not chosen. The value moved host to host through stdin, never through
  argv and never printed, and only the one variable changed, proven by a diff excluding it reporting 0.
  MIGRATIONS APPLIED, both targets asserted by role name, database and port BEFORE any write:
    control plane  public v80 to v83 (+3), eeo unchanged at v2
    tenant         public v80 to v83 (+3), eeo unchanged at v2
  0083's function eeo_snapshot_organizations present on BOTH, verified by pg_proc count.
  BINARY DEPLOYED. Production had been running the 30 JUNE build, which predates the D1b fix entirely, so
  the code fix had never been in production at all. New binary 740a432dba3bbdef, ELF x86-64 with
  GOFIPS140=v1.0.0 stamped, previous binary preserved at /root/fairness-snapshot.pre-0083.
  D1b IS CLOSED IN PRODUCTION. Before: "no organizations to snapshot" at every firing since the unit
  existed. After: "1 orgs snapshotted". The enumeration works.
  AND THE ARTIFACT IS STILL EMPTY, WHICH IS STATED RATHER THAN ROUNDED UP. 0 group rows were written, and
  the reason is DATA, not code: eeo.candidate_demographics holds ZERO rows in production, so there is
  nothing to compute a selection rate from. Measured: candidates 11, demographics 0, organizations 1. On
  staging the same binary wrote 83 group rows because staging carries demographic data. So the honest claim
  is that the JOB is fixed and the ARTIFACT awaits demographic data, and missionMATCH still cannot hand an
  assessor a populated LL144 report for production today.
  A SEPARATE OBSERVATION, recorded not acted on: eeo.fairness_snapshots already holds 2760 rows spread
  across 46 organization ids while the organizations table holds ONE. That is residue from the pooled era
  before the per tenant split. It is stale data in a compliance table, which is worth a decision.
  THE INDEPENDENT ASSERTION PROVEN TO FIRE IN PRODUCTION, as the standing order requires, run as a MUTATING
  REHEARSAL WITH ITS REVERT IMPLEMENTED AND VERIFIED FIRST per D6 rule four:
    captured the real function definition, 730 bytes, sha b0e81e17768da4d1
    stubbed it to return no rows while organizations still held 1
    the job REFUSED and exited 1, naming the D1b failure mode and saying a compliance artifact must never
      silently produce nothing
    reverted from the captured definition and PROVED the revert byte identical by diff
    counted run after the control: Result=success, 1 org snapshotted
  A function is database scoped, not cluster scoped, so rule one did not apply to this rehearsal.
  BUILD ROUTES RE PROVEN DARK AFTER THE DEPLOY, four samples each so both pool members answer: approve 404,
  scope 404, tracked 405. Positive control GET /api/auth/csrf 200, so a uniform 404 cannot be a dead host.
  Site 200, both node healthz 200. The API binary was NOT touched, only schema and a worker binary.

SECTION 2.3 DONE, THE DISK ALERT AND THE BACKUP TARGET ON VALKYRIE | 29 July 2026, under the standing
order's approval, which named VALKYRIE and superseded the A1 and A2 choice in the storage proposal.
  PART ONE, THE 85 PERCENT ALERT, BUILT AND PROVEN. /usr/local/sbin/mm-disk-watch.sh with a 15 minute timer,
  WARN at 85, URGENT at 92, alerting through mm-alert.sh, naming the top five consumers in the body so the
  mail says what to delete. It alerts on a TRANSITION following the mm-watch.sh pattern, because a watch that
  mails every fifteen minutes trains the reader to ignore it, which is the same outcome as no watch.
  OnFailure wired to bubbles-failure-notify@%N, matching the convention the eight existing units use rather
  than a new template, and scoped by name so another project's failures cannot ride this path.
  POSITIVE CONTROL IN BOTH DIRECTIONS, exactly as the proposal specified: with the threshold forced to 1 the
  watch reported warn, ALERTED, and exited 1; restoring the real threshold alerted the RECOVERY and returned
  to ok; a second run at real thresholds was SILENT, proving the transition logic and not just the alert.
  Both mails confirmed SENT in the notifier's own send.log, not merely handed off. Real reading 82 percent,
  below threshold, timer active and enabled.
  PART TWO, THE BACKUP TARGET IS NOW OFF MACHINE. mm-db-backup.sh gained a verified push to VALKYRIE,
  beandaddy@100.89.0.6, into missionmatch-backups. PURELY ADDITIVE, proven: 43 lines added, 0 removed,
  bash -n passing, previous script preserved at /root/mm-db-backup.sh.pre-offsite.
  THE LOCAL COPY STAYS. It restores in seconds and that matters during an incident. What changed is that a
  root disk failure no longer takes the platform and every copy of its backups together, which was the
  actual risk in the proposal and the reason correlation beat capacity as the concern.
  IT VERIFIES THE FAR SIDE BY CHECKSUM rather than trusting the transfer's exit code, because this build has
  already met a push that reported success while three zero byte dumps sat on disk looking like backups.
  Counted run: offsite OK, 7 of 7 artifacts verified on VALKYRIE, unit Result=success. Remote retention
  prunes to 14 daily by count, POSIX only because the far side is a Mac.
  THE FAILURE PATH PROVED ITSELF FOR REAL, WHICH IS BETTER THAN A PLANTED CONTROL. The first counted run
  FAILED: the unit runs as ROOT and root had no authorized key on VALKYRIE, while my interactive test had run
  as user. The new fail LAST assertion fired, the unit exited 1, and OnFailure triggered. That is F1 from the
  Phase 2 trial in a new costume, a thing that works in one context and not under systemd, and it is the
  third time this build has been caught by exactly that gap. Fixed by authorizing root's ALREADY EXISTING
  public key rather than minting a new credential, appended not overwritten, 5 lines to 6.
  PART THREE, THE RESTORE DRILL RERUN AGAINST VALKYRIE AND IT PASSED. The drill's root was made overridable
  so it can be pointed at the off machine copy, because a drill that can only read the local copy cannot
  prove the copy that would actually be used after losing this host.
  Pulled the day's set BACK from VALKYRIE, 8 files, 58 MB, all verified against the manifest, then restored
  from THOSE bytes: RESTORE TIME 11 SECONDS for 16 MB, schema source v83 and restored v83 which independently
  confirms the 2.2 migration landed, candidates 11 reconciled, opportunity_records 6902 reconciled, and all
  ten reconciliation rows OK. pg_restore reported 3 errors, which the drill surfaces and tolerates by its own
  existing logic; recorded rather than omitted.
  THE NIGHTLY ATTACHMENT SCHEDULE REMAINS OFF, and it is off BY CONSTRUCTION: no attachment timer unit
  exists on the host at all, so there was nothing to disable and nothing was created. Both preconditions the
  standing order set are now met, so enabling it is available and is deliberately left as Joseph's call
  rather than taken as implied.

FINDING D10, A DEAD CREDENTIAL IN PLAINTEXT IN AN OPS SCRIPT, AND THE RESTORE DRILL HAS BEEN BROKEN SINCE
D5 | Found while running the approved drill, which is the only reason it surfaced.
  mm-restore-drill.sh hardcoded a migrator DSN WITH THE PASSWORD IN PLAINTEXT on one line. That made it a
  FIFTH D5 consumer, listed in no inventory, and one the repository secret sweep can NEVER see, because the
  sweep scans the repository and this file lives in /usr/local/sbin. A credential store that only covers the
  repository does not cover the credentials.
  THE CONSEQUENCE: the D5 rotation left it holding the OLD value, so THE RESTORE DRILL COULD NOT RUN. The one
  instrument whose entire purpose is to prove a backup is restorable was itself broken by a rotation, and the
  protocol requires it at every phase close.
  I REPORTED THIS WRONG FIRST AND THE CORRECTION MATTERS MORE THAN THE FINDING. My initial probe said the
  hardcoded credential was STILL LIVE, which would have meant a burned credential active in production and
  the whole D5 window pointless. It was MY INSTRUMENT THAT WAS WRONG: I tested by grepping the output for the
  role name, and the failure message itself contains user "missionmatch_migrator", so a FATAL authentication
  failure matched my success pattern. Retested with .pgpass explicitly disabled and by comparing salted
  hashes of the password held by each source: the drill's value equals the PRE repair backup.dsn value and is
  DEAD, api.env holds the distinct live value. So the D5 rotation DID work, and the correct reading is the
  ordinary one, stale copies of a dead credential. Recorded in full because a check that matches its own
  error message is the exact failure this ledger exists to catch, and I made it.
  FIXED, AND HARDENED BEYOND THE REPAIR: the script no longer stores a credential at all. It reads
  MM_MIGRATOR_DATABASE_URL from api.env and refuses to run if it is absent, so one file changes at a
  rotation and this follows without anyone remembering it exists. Verified: zero credential shaped lines
  remain in the file, and it resolves as missionmatch_migrator. Previous version kept at
  /root/mm-restore-drill.sh.pre-d10.
  STILL OPEN, and it is Joseph's: docs/CREDENTIAL_CONSUMERS.md covers files on two hosts and does NOT cover
  /usr/local/sbin scripts on either, which is where two of the five broken consumers actually lived. The
  inventory needs a section for ops scripts, and the secret sweep needs a way to see outside the repository.

FINDING D9, THE AMENDMENT VERSION COUNTER IS STUCK AND THE ERROR IS SWALLOWED | Found 29 July 2026 in the
first successful sam-sync run after the D7 repair, which is the only reason anyone saw it.
  THE LOG LINE: amendment for opportunity afc5143e insert version: duplicate key value violates unique
  constraint uq_opp_versions_number. The run still exits 0, because the design says the provenance write
  never fails the run, so this has been failing silently since 27 July 22:28.
  THE STATE IS WORSE THAN THE ERROR. opportunity_versions holds exactly ONE row for that opportunity,
  version_number 1, is_current FALSE. So the predecessor was RETIRED and the successor was NEVER WRITTEN,
  and the opportunity now has NO CURRENT VERSION. The retire and the insert were meant to be one
  transaction and did not behave as one here.
  IT IS SELF PERPETUATING, which is the part that matters. With no current row, the next version number
  computes as 1 again, collides with the existing version 1, and fails forever. No amendment can ever be
  recorded for that opportunity again without intervention.
  SCOPE MEASURED, not assumed: 1 version row in the whole production table, 1 opportunity with versions,
  1 with no current version, 0 with multiple current. So the breach is total for the only tracked
  opportunity and contained to it.
  WHY IT DOES NOT INVALIDATE ACCEPTANCE ITEM 11: item 11 asserts an amendment FLAGS and never REWRITES an
  approved requirement, and that held in the Phase 2 trial on real amendment text with the md5 identical
  before and after. This is a different guarantee, the is_current invariant on the version chain.
  NOT FIXED. It needs an application change plus a decision about the one stranded row, both outside the
  approved scope. QUEUED for Joseph.

## SUPERSEDED HANDOFF, 29 July 2026 evening, recovery session. Kept as a record, no longer current.

DEMOTED, NOT DELETED, and the demotion is itself the fourth instance of this problem. This was the current
handoff when it was written. A later session in the same day continued the work, which made it stale, and when I
added the new handoff at the top of this file I created TWO, which is precisely the defect the block below warns
about in its own first paragraph. The check for it, grep for the heading and require exactly one, found it within
a minute of the commit.
THE RULE THIS FINALLY EARNS: writing the handoff last is necessary and not sufficient. The old one has to be
demoted in the same edit, or the file grows a second source of truth every session. Superseded handoffs keep
their content and lose their title.

PHASE 2 IS NOT CLOSED AND THE PRE APPROVAL DID NOT FIRE. It is conditioned on zero open findings and
zero new deviations. This session opened FOUR findings, D7, D8, D9 and D10, and closed two of them. By
the standing order's own terms that is not a green close, so Phase 3 was NOT started and Phase 2
remains the one current phase.

DONE THIS SESSION, all verified, all recorded above
  Reconstruction from the directive chain and the live systems. The stale handoff replaced, third time.
  Standing order 1, 2 and 4 confirmed already done. All 16 package checksums match the order exactly.
  Session start drift verification with every control firing. Evidence at
    docs/evidence/phase2/drift/session-start-drift-4.txt
  D7 CLOSED. Three stale credential consumers repaired, production backup restored after roughly
    twenty four hours without one, three zero byte partials removed, all three syncs proven end to end,
    CREDENTIAL_CONSUMERS.md corrected in the same change.
  D8 CLOSED. The frozen engine anchor was the 24 June project baseline, and the same wrong hash was
    also the DEPLOY baseline, which would have regressed five weeks of shipped work on the next deploy.
    Anchored at e74fd2e. The check now asserts the commit and the path exist.
  SECTION 2.2 DONE. 0081, 0082, 0083 to both production databases, v80 to v83. Fairness binary deployed,
    replacing a 30 JUNE build that predated the D1b fix. Independent assertion proven to fire in
    production as a mutating rehearsal with a verified revert. Build routes re proven dark.
  SECTION 2.3 DONE. 85 percent disk alert built and proven both directions. Backups now pushed to
    VALKYRIE and verified there by checksum. Restore drill rerun against the VALKYRIE bytes and PASSED,
    11 seconds, schema v83 both sides, all ten reconciliation rows OK.

OPEN, AND EVERY ONE IS JOSEPH'S
  D9 the amendment version counter is stuck on one opportunity, is self perpetuating, and its error is
    swallowed by design. Needs an application change plus a decision on the stranded row.
  D10 remainder: CREDENTIAL_CONSUMERS.md covers files on two hosts and NOT /usr/local/sbin scripts,
    where two of the five broken consumers actually lived. The secret sweep cannot see outside the repo.
  THE AUTHENTICATED PRODUCTION LEG WAS APPROVED AND WAS NOT RUN. Joseph approved provisioning and
    retiring a probe account. I stopped short of starting it because it is a production identity change
    and I judged the remaining context too short to finish it cleanly, and a half provisioned production
    account is worse than none. This is the leg that previously caught a 500 hiding behind the session
    gate, so it is a real gap and it is named rather than quietly dropped. IT IS THE FIRST THING TO DO.
  THE NIGHTLY ATTACHMENT SCHEDULE is off by construction, no unit exists. Both preconditions the
    standing order set are now met, so enabling it is available and is deliberately left as his call.
  eeo.fairness_snapshots holds 2760 rows across 46 org ids while organizations holds one, pooled era
    residue in a compliance table.
  THE FAIRNESS ARTIFACT IS STILL EMPTY IN PRODUCTION and that is data, not code:
    eeo.candidate_demographics holds zero rows, so there is nothing to compute a selection rate from.

STATE AT STOP, every number verified after the last change
  401 commits, HEAD 6978143, tree CLEAN, stash empty.
  53 packages ok and 0 FAIL, merge gate PASS with verify-backdoor and verify-fips both PASS.
  Secret sweep CLEAN on tree and on history, control firing.
  Engine diff 0 against e74fd2e, with the anchor and path assertions in place.
  Tenant v83, control plane v83, staging v83, each queried directly, all three level.
  Both production nodes 8f24414531e80a9a, identical, healthz 200 each.
  Public site 200, build routes dark 404/404/405. Zero failed units on Bubbles.
  Last backup 29 July, verified locally AND on VALKYRIE by checksum, restore drill passed against the
    off machine copy.
  Bubbles root disk 82 percent with the alert now live on a 15 minute timer.

## PHASE 2 SCOPE COMPLETION AND GATE RE RUN, 29 July 2026

PHASE 2 WAS LESS FINISHED THAN THE PREVIOUS GATE E CLAIMED, and the gap was SCOPE rather than verification.
Reading the directive against the code, rather than reading the ledger, found four requirements that did not
exist in any form. That is a different and worse category than the known limits the last Gate E listed.
  SECTION 5.1 LISTS TABLES among the required deterministic extraction targets. Nothing read tables at all.
    That is the actual reason the wage determination dropped 231 of 232 spans: the prose gate correctly refused
    rows of codes and numbers and NOTHING ELSE WAS LOOKING AT THEM. It was recorded as a capability the phase
    did not claim, when it was a capability the directive requires.
  SCREEN 4 NAMES SIX REVIEW ACTIONS and four existed. 'merged' was a status value nothing ever wrote and split
    had no representation of any kind. Migration 0084 adds the split status, widened from the CURRENT
    vocabulary because this build already learned that lesson the expensive way.
  SCREEN 5 REQUIRES GENERATING DRAFTS from accepted scope and nothing did, so the review to requirement path
    had a hole in the middle of it.
  SCREENS 3, 4 AND 5 HAD NO UI AT ALL, and neither did the amendment view, while Gate C names every one of
    them. The scope review and promotion routes were mounted and UNREACHABLE, which is the same defect shape as
    the promotion routes that were once built and never mounted.
All four are built, tested, and deployed to staging. Evidence at docs/evidence/phase2/functional/
gate-a-phase2-close.txt, stress/gate-b-results-2.txt, drift/gate-d-phase2-close.txt, and GATE_E.md rewritten.

TWO GATE 2 CRITERIA HAD NEVER BEEN EXECUTED. ingest_during_promotion_test.go sits behind a build tag and skips
without pools, so the 53 package suite never touched it, and it carried two of Gate 2's six clauses. Both now
run and pass: an ingest run during promotion corrupts nothing, and an approved requirement survived 20 ingest
rounds byte for byte at md5 6acbad7d5a24cb161b141e1d5a99e717. All six Gate 2 criteria are now proven.

THE REAL DOCUMENTS CAUGHT MY OWN WORK, TWICE, AND THAT IS THE PART WORTH READING.
  THE WAGE DETERMINATION IS NOT RECOVERABLE BY THIS BUILD, AND IT NOW SAYS SO. Before: extraction done, 1
  chunk stored. After: FAILED no_text_layer, 0 chunks. That is an IMPROVEMENT. The stored chunk was mojibake,
  because that PDF's text layer decodes to character soup from an embedded font with no usable character map,
  and reporting done over a garbage chunk is worse than failing because a reviewer cites it.
  MY TABLE READER MADE IT WORSE FIRST. Against the real document it recovered "tables" of content like "(0 CC"
  and "CC A3": mojibake contains tabs and therefore satisfied every structural test I had written. A structural
  reader that BYPASSES the prose gate must carry its own quality bar or it becomes the hole in it. The bar is
  the weakest thing that separates language from soup, a run of four letters containing a vowel.
  THE SAME BAR CLOSED A PRE EXISTING HOLE: that mojibake had been passing the PROSE gate all along.
  AND IT COST THE LEGITIMATE CASE NOTHING, measured on the same run: 04_PWS_original went 54 chunks to 55,
  GAINING a table of 3 rows. Table extraction is proven by 7 unit tests on real shaped input and by the volume
  profile parsing a 200 page PWS into 400 chunks, 200 tables and 1600 rate rows in 19 milliseconds.

F6 FIXED, AND MY FIRST FIX WOULD HAVE FAILED ON THE REAL DATA. Pairing purely within a document type looked
correct against a fixture I wrote where both PWS documents were typed pws. The intake actually classified the
amended PWS as an AMENDMENT, so pws held one document and the pairing fell straight through to the old wrong
answer. It now matches the amendment to the baseline whose FILE NAME it most resembles, version words stripped.
On the real Package B it pairs 04_PWS_original against 05_PWS_amended and reports ONE material change, quantity
1 to 7, flagging the one derived approved requirement. Previously five changes, partly artifacts. Also removed
attachment and other from the pairable types: an earlier version would have diffed an RFC log against a
deliverables list, which is worse than the bug being fixed.

PURE TESTS MISSED TWO REAL BUGS, EXACTLY AS F3 PREDICTED. Split, merge and generation shipped with pure
validation tests only, which is F3's shape precisely. Database touching tests found both in seconds: FOR UPDATE
used with an aggregate, which Postgres refuses outright, and a nil Go slice arriving as NULL in a NOT NULL array
column so generation failed on every document naming no certifications. Six integration tests now cover split,
merge, generation and manual completion, asserting the properties that matter: children inherit the citation,
generation from UNREVIEWED scope yields nothing, and a field the document never states is reported missing
rather than guessed.

GATE B EXTENDED WITH THE THREE PROFILES THE PROTOCOL NAMES AND NOBODY RAN: volume, concurrent-extract and
scrub-flood. Race at 8 and 32 both elect one winner, load holds p95 9.595ms against a 300ms target with zero
errors, scrub flood reports 0 misroutes and 0 false refusals across 1000 checks.
  TWO OF MY OWN CONTROLS WERE BROKEN FIRST. The memory profile measured CUMULATIVE allocation, which is
  identical whether results are retained or discarded, and its control returned an error UNCONDITIONALLY so it
  reported success while detecting nothing. Its cap was then a number chosen from nothing, 4096 KB, which the
  real leak came in under. The scrub control laundered payload CONTENT while keeping provenance and then blamed
  the gate for correctly allowing a payload whose only private element had been stripped. Both fixed and both
  recorded, because a control that passes by construction is the exact failure this protocol exists to catch.

FINDING D11, FOUND BY GATE D ITSELF. Migration 0084 FAILED on staging with "must be owner of table
opportunity_scope_items". The D6 structural fix created missionmatch_staging_migrator and mirrored GRANTS but
left every staging object OWNED by missionmatch_migrator, and grants do not permit ALTER TABLE, so staging could
not apply a DDL migration through the migrator that exists to migrate it. Fixed by explicit per object transfer
of 88 tables and 197 functions, deliberately NOT via REASSIGN OWNED, which also moves shared objects and could
have changed the PRODUCTION database owner as a side effect. Verified after: production tables still owned by
missionmatch_migrator, both database owners unchanged.
  THE go:embed GOTCHA BIT AGAIN. The first production run of 0084 reported +0 because the migrator binary
  predated the migration. The ledger already carried this lesson. Rebuilt, redeployed, +1 on both databases.

ALL THREE SCHEMAS ARE NOW LEVEL AT v84, queried per database. Production carries 0084 because it is additive
and carries no data, the same treatment 0081 through 0083 received, and the routes stay dark.

STAGING RUNS THE NEW BUILD: api 0fb3629d44d7b18a with the FIPS stamp, bundle index-g1gTV6We.js. index.html was
EDITED in place with only the two asset hashes rewritten, so all 22 lines and all 6 injected SEO lines survived.
All four new screens serve 200 over HTTPS and the shipped bundle contains every one of their strings.

THE AUTHENTICATED LEG RAN END TO END ON STAGING through a probe account whose password was set with
cmd/rotate-credential so it went through the real pepper and PBKDF2 path. Login 200, session 200, and every new
route 200: scope, requirement-drafts, amendments, documents, and generate. The amendment view returned the same
affected approved requirement the diff independently flagged. The probe's tool grants were restored afterwards.
  TWO REFUSALS ALONG THE WAY WERE BOTH CORRECT. A 403 was the CSRF middleware refusing a request with NO Origin
  header, which curl does not send: a hard Origin allowlist working as designed. The 404s that followed were the
  TOOL ENTITLEMENT gate failing closed on an account with no slateMATCH grant, answering 404 rather than 403 so
  a surface is indistinguishable from a path that was never built. Mistaking either for a defect would have sent
  me chasing the wrong thing.

GATE C RUN FOR THE FIRST TIME AGAINST THE PHASE 2 SCREENS, because until today there were none to sweep.
Evidence at docs/evidence/phase2/visual/phase2-close/.
  COUNTED RUN: surface authenticated, viewports 768, 1024 and 1440, 36 captures, ZERO findings. That is 6
  routes by 3 viewports by 2 roles, the full matrix with nothing skipped, as seeded recruiter and manager
  fixtures logging in through the REAL login flow with the slateMATCH entitlement.
  THE CONTROL PROVED SOMETHING THE COUNTED RUN CANNOT. A planted 4000 pixel overflow was detected on every one
  of the six routes at every viewport, and the planted minimum width regression with it. To report an overflow
  on /slate/capture/{id}/scope the sweep had to log in, hold the entitlement, resolve the route and render the
  screen, so a control that fails on all six routes is simultaneously proof that all six are reachable.
  SHELL GUARD: the widest route needs 716px against a 732px baseline plus a 24px allowance, so the new screens
  sit inside the shell's budget rather than on its edge.
  VIEWPORTS ARE 768 AND UP for the authenticated surface, which is the recorded product decision of 28 July and
  not a relaxation taken here. The public surface still holds all five widths.
  TWO CONSOLE ERRORS did not reproduce on retry and were dropped to transient.json rather than counted or
  hidden, so the decision to drop them is auditable.
  PIXEL BASELINES REMAIN UNAVAILABLE BY PROTOCOL rather than by omission: a baseline becomes one only after
  Joseph approves a contact sheet. The sheet from this run is in the evidence directory.

D9 IS NOW FIXED IN PRODUCTION, NOT ONLY IN CODE, and the stranded row healed itself. The fixed sam-sync,
75ad042b415cfd03, was deployed to Bubbles with the previous binary preserved at /root/sam-sync.pre-d9.
  BEFORE  opportunity afc5143e held version 1 with is_current FALSE, so there was no current version and every
          future amendment for it was permanently unrecordable.
  AFTER   version 2 landed alongside the retired version 1. The invariant is back to exactly ONE current
          version of two total, and the run reported "wrote 1 new opportunity versions and raised 1 alerts"
          with Result=success and no amendment failures, so the new fail last assertion did not need to fire.
  THE STRANDED ROW NEEDED NO DECISION AFTER ALL. GATE_E had listed it as awaiting Joseph's call; the correct
  numbering simply resolved it on the first run, which is what a self perpetuating bug looks like once the
  thing perpetuating it is gone.

GATE C FIXTURE ACCOUNTS, recorded because they persist. gatec.recruiter@fg-talent.test and
gatec.manager@fg-talent.test exist on STAGING ONLY, in the Package B organization, holding slateMATCH, seeded
as the protocol's "seeded fixture accounts per role". Their passwords were set through cmd/rotate-credential so
they go through the real pepper and PBKDF2 path, and the values are NOT recorded here or anywhere in the
repository, per finding D4. Re set them with rotate-credential when the next sweep needs them.

## THREE MORE FINDINGS, ALL FROM THE LAST HOUR, TWO OF THEM MINE | 29 July 2026

FINDING D12, ONE 97 KB DOCUMENT KILLED THE ENTIRE EXTRACTION BATCH. 07_TE6_Deliverables.pdf from Package B is
97,642 bytes and six pages, and opportunity-extract was OOM KILLED on it, exit 137. It printed no verdict for
the document and never reached its own DONE line, so one small file took the whole run down.
  THAT CONTRADICTED THE PROGRAM'S OWN PROMISE, written at the top of its main file: a document it cannot read is
  marked failed WITH A REASON while the run continues. Being killed by the kernel is not a reason.
  DIAGNOSED RATHER THAN GUESSED. A page by page diagnostic showed NewReader returning cleanly and reporting six
  pages, then the process dying inside the FIRST page's GetPlainText before any text came back. So the runaway
  allocation is inside ONE library call, which rules out every in process fix: a page bound does not help when
  page one is the problem, an output bound does not help when the allocation is inside the callee, and the
  existing panic recovery does not help because a process the OOM killer takes never runs a deferred function.
  FIXED BY ISOLATION. The library now runs in a CHILD process, the extractor re executing itself in a worker
  mode that reads bytes on stdin and writes text on stdout, under a 90 second deadline, an output cap, and on
  Linux a 1 GiB address space limit the child sets on itself. A dead child is a fact about one file, exactly as
  a panic already was, and the parent falls through to the hand rolled reader. It re executes ITSELF so there is
  no new dependency and the no Python rule is untouched.
  WHY THE LOCAL CAP MATTERS BEYOND THIS FILE: the OOM killer does not necessarily kill the process that asked
  for the memory. On staging it chose the extractor. On a busier host it could have chosen the API.
  PROVEN: the batch now reports "ok=1 failed=1" with the document named no_text_layer, and a regression test
  guards it, skipped unless the fixture is present because a 97 KB binary does not belong in the repository.
  ALSO FIXED WHILE IN THERE: inflateStreams bounded each stream to 32 MB and had NO ceiling on the SUM, while
  its own comment claimed a decompression bomb was ruled out. It was not. There is now an aggregate budget, and
  exceeding it REFUSES the document rather than returning truncated text that looks complete.

FINDING D13, MY OWN D11 FIX BROKE THE NIGHTLY BACKUP, and the alerting caught it. Transferring ownership of
every staging object to missionmatch_staging_migrator removed missionmatch_migrator's implicit owner
privileges, and the backup dumps STAGING using that role. pg_dump failed with "permission denied for table
goose_db_version" and the unit failed.
  THE OnFailure WIRING FROM D2 PAID OFF ON A REGRESSION I CAUSED. The failure raised mail rather than sitting in
  a journal, which is exactly what that work was for.
  FIXED WITH READ ACCESS, NOT OWNERSHIP BACK: SELECT and schema USAGE on both schemas, plus DEFAULT PRIVILEGES
  so the next migration does not reintroduce it on a night nobody is watching. Ownership stays with the staging
  migrator, which is what lets staging DDL run at all.
  IT TOOK TWO PASSES AND THE SECOND ONE IS THE LESSON. The first grant covered every TABLE in both schemas and
  sequences in public only, so pg_dump got past all 88 tables and then failed on candidate_demographics_id_seq
  in the eeo schema. A partial grant moves the error later without removing it.
  DIRECTION MATTERS AND IS WHY THIS IS SAFE: D6's isolation exists to stop STAGING reaching PRODUCTION, and this
  is the opposite direction. Asserted afterwards: missionmatch_staging_migrator still has CONNECT on the
  production database REVOKED.
  BACKUP RESTORED AND PROVEN: Result=success, 11 artifacts, offsite OK 11 of 11 verified by checksum on
  VALKYRIE. Restore drill rerun: PASSED, 11 seconds for 16 MB, schema v84, all ten reconciliation rows OK.

FINDING D14, A LIVE CREDENTIAL WAS DISCLOSED INTO A LOG, BY ME, AND THIRTEEN BINARIES COULD HAVE DONE THE SAME.
  WHAT HAPPENED. I added the PDF worker mode but checked its hidden flag AFTER flag.Parse. The flag package saw
  an unrecognised flag, printed its usage, and USAGE PRINTS DEFAULTS. The DSN was a flag default read from the
  environment, so the live missionmatch_staging_migrator password was written to stdout and into the staging
  journal. One unrecognised flag, one disclosed password.
  THE SYSTEMIC HALF IS WORSE THAN MY MISTAKE. A sweep found SEVENTEEN flag defaults across THIRTEEN binaries
  reading secrets from the environment, including cmd/rotate-credential, whose usage output would have printed
  the CREDENTIAL PEPPER, the server side key applied before PBKDF2. Every one of them disclosed a live secret on
  any usage error, any typo, any unknown flag. This was latent long before today and my mistake only triggered it.
  FIXED IN ALL THIRTEEN. No secret is a flag default any more: the flag defaults to empty, the help text NAMES
  the environment variable instead of showing its value, and the value is read after parsing. PROVEN with a
  planted secret in six environment variables: 0 of 13 binaries disclose it, and the check was itself controlled
  by reverting one binary, watching the leak reappear, and restoring it.
  ROTATED, BECAUSE A DISCLOSED CREDENTIAL THAT IS MERELY REDACTED IS STILL DISCLOSED. Followed the documented
  procedure in order: fresh backup, update the one consumer FIRST, ALTER ROLE LAST, restart what reads its DSN at
  boot, prove by role name and status code.
  PROVEN OLD DEAD AND NEW LIVE: the disclosed value is now refused with "password authentication failed", the
  consumer authenticates as missionmatch_staging_migrator on missionmatch_staging, staging healthz 200, and
  CONNECT on production is still revoked. Integration tests re run green against the rotated credential.
  SCOPE, STATED HONESTLY: this role reaches missionmatch_staging ONLY, and that was already proven by refusal
  during D6, so the exposure was staging and not production. The value also remains in the staging systemd
  journal until it rotates out, which cannot be scrubbed and is recorded rather than glossed.
  I ALSO BLAMED THE ROTATION FOR SOMETHING IT DID NOT CAUSE, AND THE CORRECTION IS D16. A 30 minute soak was in
  flight when the rotation landed and it ran ten minutes past its deadline still burning CPU, so I attributed
  that to the rotation breaking its connections. A SECOND soak, started afterwards on the correct credential
  from the beginning, did exactly the same thing. The rotation was innocent. See D16.

FINDING D16, THE STRESS TOOL CANNOT REPORT A SOAK OF THE LENGTH THE PROTOCOL ASKS FOR, AND NEVER COULD | 29 July
2026. Two long soaks were lost before this was diagnosed, and the first loss was wrongly blamed on the D14
credential rotation happening at the same moment.
  THE CAUSE, found by elimination rather than by guessing again. pg_stat_activity showed NO active or blocked
  queries on staging, so the workers were not waiting on the database. The CPU was being burned AFTER the load
  finished, in the reporting step, and percentile() used an INSERTION SORT:
    // Sorting a few thousand durations is not the bottleneck here and a simple implementation is easier to
    // trust than a clever one in a measuring instrument.
  The reasoning was sound and the premise was false. Thirty minutes at roughly a thousand reads per second is
  about 1.8 MILLION samples, not a few thousand, and insertion sort is O(n squared): on the order of a trillion
  operations, run TWICE for p95 and p99.
  WHY NOBODY SAW IT. The first Gate B bundle ran a SIXTY SECOND soak, which is 60,000 samples and completes in
  seconds. The protocol asks for THIRTY MINUTES. So the protocol's soak requirement has never once been
  measurable with this instrument, and the gap was invisible because the only soak ever run was 30 times shorter
  than the one required.
  A MEASURING INSTRUMENT THAT CANNOT REPORT THE MEASUREMENT THE PROTOCOL ASKS FOR IS NOT A SLOW INSTRUMENT, IT
  IS A MISSING ONE. Every number was collected correctly and none of it was printable.
  FIXED with sort.Slice. Proven: a 40 second soak now reports 45,335 samples at p95 8.756ms instantly, and the
  full 30 minute run was started afterwards.
  THE LESSON WORTH KEEPING: a comment justifying a simplification is a claim about the input, and that claim
  needs checking against the input the protocol actually specifies rather than against the input the author had
  in mind.

FINDING D15, THE UPTIME WATCH RAISED A FALSE ALARM AND THE ALARM TEXT HID THE REASON | 29 July 2026, found
during the final state check because mm-watch showed as a failed unit.
  THE ALERT SAID: "PUBLIC SITE: https://missionmatch.thatwebhostingguy.com/ returned 200000, expected 200". The
  site was answering 200 the entire time.
  THE BUG IS ONE SHELL IDIOM:
    code() { curl -s -o /dev/null -w "%{http_code}" --max-time "${2:-15}" "$1" 2>/dev/null || echo 000; }
  When curl PRINTS a status code and THEN exits nonzero, which it does on a timeout or a partial transfer after
  the headers have already arrived, BOTH outputs land: the real code from -w and the 000 from the fallback. The
  caller compares "200000" to "200", it does not match, and the watch reports an outage that is not happening.
  WHY IT MATTERS MORE THAN ONE FALSE ALERT. A monitor that cries wolf is a monitor that gets ignored, and this
  ledger has written that sentence about other instruments more than once. It is also SELF CONCEALING: the alert
  text is unreadable, so the natural reaction is to distrust the message rather than to suspect the checker.
  FIXED: the helper accepts exactly three digits from curl and substitutes 000 otherwise, so the two outputs can
  never concatenate. Previous version kept at /root/mm-watch.sh.pre-d15.
  PROVEN IN BOTH DIRECTIONS. Real run: OK, exit 0. Control, pointed at a hostname that cannot serve the app:
  "PUBLIC SITE: ... returned 000, expected 200", exit 1. The message is now readable and the detector still
  detects, which is the pair of properties that were both broken.

## INTEGRITY CHECK, GATE B CLOSURE, AND TWO MORE OF MY OWN REGRESSIONS | 29 July 2026, evening

INTEGRITY CHECK AFTER A SERVER ERROR, AND THE HONEST ANSWER IS THAT NOTHING WAS DAMAGED. A server error
interrupted a Gate B evidence update mid write, so every evidence and ledger file touched in that window was re
read and verified rather than assumed intact.
  CHECKED: ten files. All ten end with a newline and a sensible final character. Zero duplicate section headings
  where exactly one is expected, checked for the handoff, the reconstruction entry and the scope completion
  entry. Working tree CLEAN at fff3069, so nothing half written was sitting uncommitted either.
  THE FINDING IS A GAP, NOT A CORRUPTION. gate-b-results-2.txt was intact at 87 lines and contained ZERO
  occurrences of the http-load or D16 content it was about to receive: the interrupted write never began. So
  there was nothing to repair and something genuine to finish. The source numbers all survived in the scratch
  logs and the file was completed from them rather than from memory.
  RECORDED BECAUSE A CLEAN INTEGRITY CHECK IS STILL A RESULT. The instinct after an interruption is to assume
  damage and start rewriting, and rewriting a file that was fine is its own way of losing information.

THE PRODUCTION AUTHENTICATED LEG IS DONE, closing the gap the reconstruction entry named and the standing order
approved. Method of record followed exactly: a dedicated probe provisioned, used, and retired.
  PROVISIONED phase2.probe@missionmatch.test in the CONTROL PLANE, role viewer, NO tool grants, lowest
  privilege. Password set through cmd/rotate-credential so it went through the real pepper and PBKDF2 path
  rather than a hand written hash.
  LOGGED IN THROUGH THE PUBLIC PRODUCTION URL: login 200, session 200.
  BUILD ROUTES DARK ON THE AUTHENTICATED LEG, four samples each so both pool members answer:
    approve 404 404 404 404, scope 404 404 404 404, tracked 405 405 405 405
  AND THE FIVE NEW PHASE 2 ROUTES ARE DARK BEHIND A VALID SESSION TOO, which is the point of checking them:
    split 404, merge 404, generate 404, amendments 404, draft PATCH 404
  ZERO 5xx ON EITHER NODE during the window, checked per node rather than inferred: Bubbles 0, megamind-agi 0.
  The nginx log carries 25 5xx TOTAL across its whole history, every one from 06:40 this morning on the STAGING
  vhost, which are the known F3 upload failures. ZERO in the window. My first count of 44 was a bad grep and is
  corrected here rather than left in the record.
  RETIRED, never deleted: status disabled, sessions revoked through the product's own
  auth_revoke_user_sessions, 0 live sessions with the row and its 1 historical session preserved. PROVEN
  retired: a fresh login returns 401 and the old session cookie returns 403.

GATE B IS COMPLETE. Every Phase 2 stress item and every general Gate B item has now been executed with a
control that failed first. Evidence at docs/evidence/phase2/stress/gate-b-results-2.txt.
  THE 30 MINUTE SOAK REPORTED FOR THE FIRST TIME: 2,028,801 samples, rps 1127, p95 8.931ms, p99 10.503ms, zero
  errors, against a 300ms target. Two million samples is itself the proof of D16.
  AUTHENTICATED HTTP LOAD, open across TWO phase closes, now closed: 25,924 samples over 10 minutes paced to the
  protocol's 50 rps, p95 37.352ms, p99 67.644ms, ONE HUNDRED PERCENT SERVED, zero 429, zero 5xx.
  THE FAILURE DRILL IS COMPLETE IN ALL THREE PARTS. Failover was measured for real by D6. Saturation produced
  17,314 of 429 and ZERO of 500. And the worker kill drill ran: five documents pending, SIGKILL 1.2 seconds in
  having decided 3 of 5, rerun completed the other 2, all five done, zero pending, and ZERO chunks sharing a
  document, a content hash and a section label. The one same hash pair that exists is legitimate, the literal
  text "Warranty Program.  N/A" appearing twice in the source.

FINDING D17, I DELETED flag.Parse AND DEPLOYED THE RESULT. While removing a duplicated worker check block from
cmd/opportunity-extract, my edit took the flag.Parse call and both environment fallbacks with it. Every flag
stayed at its zero value, so the binary fatalled on "-dsn or MM_MIGRATOR_DATABASE_URL is required" on a host
where that variable was plainly set. It was DEPLOYED to staging in that state.
  IT FAILED LOUDLY, WHICH IS THE ONLY REASON IT WAS CAUGHT IN MINUTES. A binary that had instead defaulted to
  something plausible would have run against the wrong target silently. Loud failure is a feature.
  A CHECK THAT WOULD HAVE CAUGHT IT NOW EXISTS AND WAS RUN ACROSS THE WHOLE TREE: every binary declaring flags
  must call flag.Parse. Result: 0 binaries declaring flags without parsing them, so this was the only one.

FINDING D18, MY D12 FIX SILENTLY DEGRADED EVERY PDF, WHICH IS WORSE THAN THE BUG IT FIXED. The isolated PDF
worker was given RLIMIT_AS of 1 GiB, reasoning that a local cap makes a runaway fail on the process that caused
it. The reasoning holds; the implementation did not. RLIMIT_AS bounds VIRTUAL address space and the Go runtime
reserves large virtual arenas at startup, so EVERY worker died instantly with "fatal error: runtime: out of
memory" before reading a byte.
  EVERY WORKER FAILURE FALLS BACK TO THE WEAKER HAND ROLLED READER, which is right for an unreadable document
  and wrong for a readable one. So a fix aimed at ONE pathological file quietly degraded extraction for ALL
  files: 04_PWS_original went from 55 chunks to 3 and REPORTED SUCCESS while doing it. That is a green result
  over a quietly worse outcome, the exact shape this build keeps finding, and I introduced it.
  CAUGHT BY COMPARING AGAINST A RECORDED BASELINE rather than by reading the log, which said ok=1 and looked
  fine. The number 3 where 55 was expected is the only reason it surfaced.
  FIXED by removing the rlimit entirely. THE HARD BOUND WAS ALWAYS THE ISOLATION, not the limit: the library
  runs in a child, a runaway kills the child, the parent names the document and the batch continues. GOMEMLIMIT
  is set as a SOFT hint and is described as soft rather than sold as a cap. Pdeathsig still ties the child's life
  to the parent's.
  PROVEN BOTH WAYS AFTER THE FIX. 04_PWS_original is back to 55 chunks, now including a recovered table. And the
  crasher is STILL contained: "the isolated reader failed (signal: killed), falling back", document named
  no_text_layer, batch DONE ok=0 failed=1. The kernel killed the CHILD and the parent survived, which is
  precisely the property D12 required and it needs no rlimit to hold.
  THE TABLE READER IS ALSO VISIBLY EARNING ITS PLACE now that the worker path works: the amended PWS recovered
  91 tables and 486 rate rows, going from 300 chunks to 391.

D16 IS CLOSED. The percentile function is O(n log n), the 30 minute soak has been run and reported, and the
lesson is codified as a standing Gate D rule plus a new file, docs/POSITIVE_CONTROL_LIBRARY.md, which gives the
library the protocol has described since 28 July an actual home. Seventeen controls are listed, each naming the
instrument, the lie it told, and the control that catches it.
  THE WRONGLY BLAMED CORRECTION, NAMED: D16's first lost soak was attributed to the D14 CREDENTIAL ROTATION
  landing at the same moment. D14 was INNOCENT. A second soak, started afterwards on the correct credential from
  the beginning, hung identically, which is what proved it. That wrong attribution cost a second lost run,
  because a wrong answer closes a question that should have stayed open. When two things change together, prove
  which one did it.

## THE FOUR FINDINGS HOLDING PHASE 2 OPEN, 29 July 2026

RESOLUTION, WRITTEN 29 JULY 2026 LATE, on Joseph's recorded decisions. THREE OF THE FOUR ARE CLOSED. The
fourth executed and is blocked at the far end by something no amount of work here can reach. Each original
block is left standing below with its status line updated, because the reasoning that produced a finding is
worth more than a tidy list.

  1  CLOSED BY DECISION.   Scanned or undecodable text layers are a graceful terminal state with a clear
                           no_text_layer status surfaced in the UI. OCR is not in this build and is recorded
                           as future candidate P2 in docs/IMPROVEMENTS.md. The trial evidence shows the wage
                           determination carrying that status correctly.
  2  CLOSED BY DECISION.   Office formats are stored, hashed and versioned with a graceful unsupported_format
                           status for Phase 2. The reader itself, an xlsx library bake off measured against
                           the real Package A spreadsheet plus a minimal docx text path, is PRE APPROVED as
                           Phase 3's single improvement item. Phase 3's slot is now spent.
  3  NOT CLOSED, EXECUTED. The full bounded run was performed. Every mechanism on this side executed against
                           the live external endpoint for the first time, and all three calls were refused by
                           OpenAI with 429 insufficient_quota. The key is VALID; the account has no credit.
                           Evidence docs/evidence/phase2/findings/finding-3-external-normalize-path.txt.
                           NEEDS ONE THING FROM JOSEPH: credit on that account. Then three calls and ninety
                           seconds. Acceptance fixed in advance: three outcome rows reading openai:gpt-4o-mini.
  4  CLOSED BY EXECUTION.  The sweep now covers 15 enumerated out of repo scopes on two hosts, with 13
                           positive controls, both directions, tracked and untracked, inside and outside the
                           repository. It found two complete DSNs in mm-identity-sync.sh on its first working
                           run, which CREDENTIAL_CONSUMERS.md had described as a trap and left standing.
                           Repaired, and the same change took both credentials out of argv.
                           Evidence docs/evidence/phase2/findings/finding-4-secret-sweep-out-of-repo.txt.

Every other finding raised in this build is closed. These four are not, and each one is stated with its
status, the evidence that establishes it, and what closure actually requires. None of them is a correctness
defect: three are capability limits and one is an instrument gap.

OPEN 1, THE SCA WAGE DETERMINATION IS NOT EXTRACTABLE BY THIS BUILD
  STATUS    CLOSED BY DECISION, 29 July, Joseph. A scanned or undecodable text layer is a GRACEFUL TERMINAL
            STATE: stored, hashed, versioned, status no_text_layer surfaced in the UI with both causes named,
            and ZERO chunks so no reviewer can cite noise. OCR is not in this build; recorded as candidate P2
            in docs/IMPROVEMENTS.md. Was an open capability limit. NOT a regression, and the pipeline is now HONEST about it where before it
            was not: the document reports extraction FAILED with no_text_layer and stores ZERO chunks, where
            previously it reported DONE with one stored chunk of character soup.
  EVIDENCE  docs/evidence/phase2/functional/gate-a-phase2-close.txt. Measured on staging: 231 of 231 spans
            refused, 0 chunks. The PDF's text layer decodes to mojibake because its embedded font carries no
            usable character map, which is a DECODING limit and not a table extraction limit. Table extraction
            itself is proven by 7 unit tests on a real shaped wage determination and by the volume profile
            parsing a 200 page PWS into 400 chunks, 200 tables and 1600 rate rows.
  CLOSURE   A character map aware PDF reader, so the font's ToUnicode CMap is applied before text is scanned.
            That is a distinct capability and belongs in its own phase item, not in a Phase 2 patch. Until
            then the wage determination's rate grid, the legal floor under every bill rate in a proposal, is
            not available to the product and the product says so.

OPEN 2, NO OFFICE FORMAT READER
  STATUS    CLOSED BY DECISION, 29 July, Joseph. For Phase 2 office formats are stored, hashed and versioned
            with a graceful unsupported_format status and nothing is invented from them. The reader itself,
            xlsx through a MEASURED Go library bake off with the real Package A spreadsheet as fixture plus a
            minimal docx text path, is PRE APPROVED as Phase 3 single improvement item. Phase 3 slot spent.
            Was an open capability limit, and arguably the allowlist working rather than a defect.
  EVIDENCE  Staging: 05_PWS_Att4_Course_Schedule.xlsx reports FAILED unsupported_format with 0 chunks. The
            refusal is BY NAME and by a closed vocabulary, which is the designed behaviour for a format this
            build cannot read honestly, rather than a decoder producing plausible output from a format it does
            not understand.
  CLOSURE   Either an office reader for xlsx and docx, or a recorded DECISION that spreadsheet attachments are
            out of scope and will be refused permanently. Both are legitimate; leaving it undecided is not,
            because a course schedule is real scope a reviewer may need.

OPEN 3, THE EXTERNAL REQUIREMENT_NORMALIZE PATH HAS NEVER EXECUTED AGAINST OPENAI
  STATUS    EXECUTED 29 July on Joseph's order, STILL OPEN, blocked at the far end. The bounded run happened in
            full: the boot guard was controlled both ways, the backend was enabled on a temporary process so no
            persistent gateway was touched, three public notices went through the gate, three egress rows and
            three outcome rows were written, and the flag is verified off again. OpenAI refused all three with
            429 insufficient_quota. The key is VALID, an invalid key answers 401; the ACCOUNT has no credit.
            The gateway fell back to the local runtime, which the outcome rows caught and named, and that catch
            is the reason this is recorded as unproven rather than closed. What remains unproven is precisely
            one thing: the verifier gating prose written by an external model.
            CLOSING IT NEEDS CREDIT ON THAT ACCOUNT and nothing else. Note from the 28 July decision: this key
            was pasted into chat and sat in a plaintext Desktop file, so rotating before funding is the safer
            order. Evidence findings/finding-3-external-normalize-path.txt.
  EVIDENCE  The backend, the boot guard, the egress gate and the audit are built and proven, and the scrub
            gate permits only public SAM notice text under that class, with the candidate row and tenant
            document fixtures refused from anywhere in a payload. What has never run is the gateway actually
            calling OpenAI: its generation backend is config selected and points at the LOCAL model.
  CLOSURE   Joseph's decision, then one end to end run. It is a gateway CONFIG change protected by the boot
            guard, not new code. I did not enable it because it sends data to a third party and carries cost,
            which makes it a decision with policy attached rather than a verification step I can take on my
            own authority.

OPEN 4, THE SECRET SWEEP CANNOT SEE OUTSIDE THE REPOSITORY
  STATUS    CLOSED BY EXECUTION, 29 July. 15 enumerated scopes on two hosts, 13 positive controls passing in
            both directions, and a counted run reporting 15 of 15 scopes answered and clean. It found what it
            was built to find on its first working run: two complete DSNs, passwords included, in
            mm-identity-sync.sh, which a timer runs hourly as root and which this very inventory had already
            called a trap and left standing. Repaired to resolve both from db.env by name, and the same change
            took both credentials out of argv, measured 1 exposure before and 0 after.
            TWO DEFECTS IN THE INSTRUMENT WERE FOUND ON THE WAY, both of the house failure mode: ssh inherited
            the scope file on stdin and drank 12 of 13 lines so ONE scope ran and the sweep said clean, and the
            guard refused only on zero scopes so one out of thirteen satisfied it. It now counts expected
            scopes from the file. At least one answered is not a check.
  EVIDENCE  docs/CREDENTIAL_CONSUMERS.md now carries an ops scripts section, added because TWO of the five
            consumers broken by the D5 rotation lived in /usr/local/sbin and no inventory listed them. One of
            them, mm-restore-drill.sh, held a migrator password in PLAINTEXT and the sweep could never have
            found it, because the sweep scans the repository and that file is not in it. D14 then showed the
            same class systemically: seventeen flag defaults across thirteen binaries would disclose a live
            secret on any usage error.
  CLOSURE   Extend tools/verify/secret-sweep to accept named paths outside the repository, run it against the
            ops script directories on both hosts, and give it a positive control planted in one of those paths.
            Until then the sweep's clean result means "clean in the repository", which is narrower than it
            reads, and that narrowness is now written down rather than assumed.

NOT ON THIS LIST, BECAUSE THEY ARE NOT FINDINGS
  GATES A, C AND D NEED RE RUNNING. All three passed, and then code changed after they passed: the readability
  bar, the process isolated PDF worker, the pairing fix, the thirteen binary flag change. Their PASS verdicts
  describe a commit that is no longer HEAD. That is ordinary sequencing, not a defect, and the re runs are the
  first work of the next session.
  PIXEL BASELINES await Joseph's approval of the contact sheet. That is Gate E working as written.

## Phase 0, security and preflight

phase0 | item0 execution design spec written | docs/superpowers/specs/2026-07-27-opportunity-to-outcome-execution-design.md present, approved by Joseph in chat | 7641374 | 2026-07-27
phase0 | item5 archive move | docs/archive/INTELLIGENCE_EXPANSION_SPEC.md present (228 lines), governing directive added as docs/BUILD_DIRECTIVE.md | e662665 | 2026-07-27
phase0 | item6 BUILD_STATE ledger created | this file exists with the section 0 format | 2595999 | 2026-07-27
phase0 | amendment staging environment rule | directive Section 0 item 9 added, directive renamed to docs/CLAUDE_CODE_BUILD_DIRECTIVE.md, through Phase 5 all DB work runs on missionmatch_staging megamind-agi 5433, production M4 only at Gate 6 | this commit | 2026-07-27
phase0 | item1 human OpenAI key revoked | Joseph confirms revocation in the OpenAI dashboard | human step | 2026-07-27
phase0 | item2 human project scoped key placed | key on M4 as openai_api_key root 0600, read only via the secrets store, enabled flag false | human step | 2026-07-27
phase0 | item3 human SAM.gov system account applied | application submitted today, revisit at Phase 4 | human step | 2026-07-27
phase0 | item4 scrub egress classes and external call audit gate | go test scrub and ai green; AllowEgress fails closed on an unknown class and on a uuid, email, or phone marker; AllowExternal records backend, class, byte count, and content hash, never content | 8ba3318 | 2026-07-27
phase0 | openai gateway backend and boot guard | generateOpenAI added over the chat completions contract, key read only through the secret store, enabled flag default false; go test cmd/megamind-gateway green | 110bd1c | 2026-07-27
phase0 | GATE 0 passed | built the real gateway binary and ran it: openai enabled with no key exits 1 (openai_api_key is [credential removed] from the secret store, refusing to boot), openai enabled with an empty model exits 1; scrub and egress tests pass; BUILD_STATE exists; archive move committed at e662665; make ci-gates PASS on backdoor and FIPS | 110bd1c | 2026-07-27

## Conflicts recorded (directive Section 0 items 6 and 9)

CONFLICT phase1 staging location and parity | The amendment names staging as missionmatch_staging on megamind-agi port 5433. Ground truth from the live /etc/missionmatch/staging.env, used by the running mm-api-staging service on 127.0.0.1:8097, is that staging is missionmatch_staging on M4 100.94.8.94 port 5432, a DISTINCT database on the SAME Postgres server as the production missionmatch database. Staging runs shared tenancy, production runs per_tenant. Staging goose version is 59, repository head is 0068, so staging is nine migrations behind parity, and the opportunity tables do not yet exist there. Stopped before any write per Section 0 items 6 and 9. Awaiting Joseph confirmation that the correct Phase 1 target is missionmatch_staging on M4 5432, that bringing it from 59 to 68 to reach parity is authorized, and that targeting only the missionmatch_staging database, never missionmatch, satisfies the do not touch production before Gate 6 rule. | pending | 2026-07-27
RESOLVED phase1 staging conflict | Joseph decided there is no separate staging: the build extends the existing application directly and verifies against the live database with a connected database name assertion and a pg_dump snapshot before each write. missionmatch_staging is not used. Directive Section 0 item 9 updated to supersede the staging amendment. | beab171 | 2026-07-27

## Phase 1, opportunity foundations

phase1 | item1 ingest_manifest migration | 0069 applied to production missionmatch on M4 5432 (goose 68 to 69), shared reference data with no RLS (rls_enabled false), columns id, source, url, license, fetched_at, record_count, content_hash, created_at, app grants SELECT and INSERT, schema snapshot saved on Bubbles at /home/user/mm-snapshots; the down refuses to drop when provenance rows are present | a77dd65 | 2026-07-27
phase1 | item1 tracked_opportunities migration | 0070 applied to production (goose 69 to 70), tenant table verified rls_enabled and rls_forced true, 1 isolation policy, 4 foreign keys (organizations, ingest_manifest, users twice via the column list SET NULL form), indexes idx_tracked_opps_org_status and the unique partial uq_tracked_opps_org_public and uq_tracked_opps_org_id, app grants SELECT INSERT UPDATE no DELETE, 31 columns per Section 3.1; snapshot taken first; down refuses when rows present | cd7ca09 | 2026-07-27
phase1 | item1 opportunity_versions migration | 0071 applied, immutable snapshot table, rls_forced, 15 columns, 5 FKs, trigger opportunity_versions_immutable_trg allows only the is_current flag and blocks delete, unique (org, opportunity_id, version_number), grants SELECT INSERT UPDATE | 2026-07-27
phase1 | item1 opportunity_documents migration | 0072 applied, rls_forced, 18 columns, 5 FKs, document_type and extraction_status enum CHECKs, sha256 duplicate partial unique index, grants SELECT INSERT UPDATE | 2026-07-27
phase1 | item1 opportunity_document_chunks migration | 0073 applied, rls_forced, 10 columns, FK to opportunity_documents on delete cascade, extraction provenance, grants SELECT INSERT | 2026-07-27
phase1 | migrations applied via migrate-all-tenants | the sanctioned tool (goose library, embedded migrations, session locked, idempotent), 1 target control plane missionmatch on M4 5432 with 0 active tenants, public v70 to v73, eeo v2 unchanged; the goose CLI is avoided because it pulls heavy unrelated drivers not in go.sum | 2026-07-27
phase1 | opportunity capture API and screen | capability opportunity.manage added at recruiter and above (matrix test green); opportunities module gains the tenant capture layer (CreateTracked, ListTracked, GetTracked, PatchTracked via RunInTenantTx, org from GUC, audited), mounted under the slateMATCH tool gate at /opportunities/tracked (Section 9 path resolved around the public cache owning /opportunities/{noticeID}); chi.Walk route contract test green; Capture intake screen at /slate/capture | 13d6399 and 7a196ca | 2026-07-27
phase1 | opportunity capture deployed and verified live | new FIPS binary deployed to Bubbles (staged sha256 swap, healthy in 2s), frontend assets swapped with the 5 SEO lines intact; through the public URL the site is 200, the new bundle serves, /slate/capture serves the SPA 200, and POST /api/opportunities/tracked returns 403 (route live, auth required) consistently with no stale replica 405 | 2026-07-27
OPEN phase1 | megamind-agi replica out of the pool | the mm-api replica at 100.77.114.40:8094 has no direct SSH (port 22 refused, SSH lands on the Windows host cmd with WSL nested), so it could not receive the new binary; it is marked down in /etc/nginx/conf.d/mm-api-upstream.conf so all traffic reaches the updated Bubbles node. FOLLOW UP: establish a WSL deploy path for megamind-agi, redeploy the binary, and remove the down flag to restore two node failover | 2026-07-27
RESOLVED phase1 | megamind-agi replica back in the pool | Joseph provided access (josep@100.69.120.61). The replica mm-api runs in WSL Ubuntu as a system service (User mm-api), binary /opt/missionmatch/mm-api. Deployed the new binary through the Windows /mnt/c bridge (sha 8647587c matches Bubbles), restarted, healthy in 2s, POST /api/opportunities/tracked returns 403 not the stale 405. Removed the down flag, reloaded nginx; both nodes serve consistently (8 of 8 403 through the public URL, and each node directly). Two node failover restored. WSL deploy path for future releases: scp the binary to the Windows host home, then run a bash script via wsl that stops the service, copies from /mnt/c to /opt/missionmatch, and restarts; sudo in WSL is NOPASSWD | 2026-07-27
phase1 | item2 intake screen 2 opportunity intelligence | /slate/capture/:id detail and edit view built and deployed (frontend only, backend PATCH already live on both nodes); edits agency, office, solicitation, notice type, NAICS, PSC, set aside, place of performance, incumbent, source URL, deadline, prime or sub, status; public verify site 200, new bundle 200, detail route serves the SPA 200; tsc and vite clean | 4defe49 | 2026-07-27
phase1 | opportunity embedding layer, the AI learns the opportunity landscape | migration 0074 applied to production (goose 73 to 74): opportunity_records gains embedding vector(384) with a partial HNSW cosine index (the skills pattern, global data outside RLS) and a GENERATED search_tsv with a gin index. embed-backfill extended with -what opportunities (existing binary extended, no new binary). Ran against production: 6535 of 6535 embedded, exit 0, model qllama/bge-small-en-v1.5. SEMANTIC RETRIEVAL VERIFIED LIVE: the natural language query "cybersecurity engineering support for the Air Force" returns PACAF Cyber Systems Operations Support, Cybersecurity Support Services, and Cyber Security Services at 0.78 cosine, ranked by meaning not keywords. Before this the catalog had no vectors at all and only skills, candidates, and ai_memory were embedded | 084e521 | 2026-07-27
## Amendment 6, accepted 28 July 2026

AMENDMENT 6 ACCEPTED | source docs/DIRECTIVE_AMENDMENT_6.md (224 lines), triggered by live FG Talent design
partner feedback. Merged into the directive: acceptance items 36 through 40 appended to Section 11, and
PHASE 5A, Identity and Access, inserted between Phase 5 and Phase 6 with its own Gate 5A. Creates two
containers, TRACK U (urgent, production eligible under the Section 2 item 8 guardrails) and Phase 5A. Role
enum values are extended, never renamed or removed. The scoring engine stays frozen. | 2026-07-28

TRACK U ITEM 1, ROOT CAUSE RECORDED BEFORE ANY FIX, as the amendment requires | Investigated the three
reported symptoms against the code and the staging database.

SYMPTOM 1, a client superuser could not edit her own name. ROOT CAUSE, conclusive: full_name appears ZERO
times in internal/modules/auth/handler.go, service.go, and helpers.go. It exists only in dto.go, on the
invite and user list shapes. There is no self service profile endpoint anywhere in the API, and there is no
endpoint that mutates a name for ANY actor. The only user mutations that exist are role, tools, status,
mfa reset, and recovery reissue. A name is therefore written once at invite acceptance and is IMMUTABLE
thereafter for every role including admin, owner, and superuser. This was never a permissions problem: the
capability does not exist, which is why escalating to the top of the ladder did not help her.

SYMPTOM 2, the Superuser tab rendered inactive. ROOT CAUSE: there is no separate Superuser tab component;
the word appears only in explanatory copy on the Admin screen. What renders inactive is the tool entitlement
grid at frontend/src/screens/Admin.tsx:308, const locked = !mine && !on, which greys out any product tool
the ACTOR does not personally hold, because an actor may only confer a tool they already have. A client top
seat who was not granted every product tool therefore sees permanently greyed controls that read as broken
rather than as not applicable. The deeper cause is the one the amendment names: superuser conflates the
platform plane with the tenant top seat, so a client is shown platform shaped controls at all.

SYMPTOM 3, no tenant facing user management. PARTIALLY PRESENT, not absent: GET /users exists gated on
RequireRole(RoleAdmin), which uses AtLeast, so a superuser at rank 6 does reach it, and the Admin screen is
routed at /admin with a /people alias. What is genuinely MISSING is name editing (no endpoint at all, per
symptom 1), self service anything, and a tenant scoped management surface that does not also expose
platform concepts.

STAGING FACTS for the fix: the users table column is full_name, NOT display_name, so the amendment's display
name wording maps onto full_name rather than a new column. Staging currently holds NO superuser (roles
present: owner 163, recruiter 881, manager 16, member 13), so reproducing as the reporting user's role
requires provisioning a superuser on staging first. The users role CHECK constraint allows exactly
superuser, owner, admin, manager, recruiter, member, viewer, with NO operator value, so Track U item 4
requires a migration that EXTENDS the constraint, never renames or removes a value. | 2026-07-28

DECISIONS 12 AND 13 RATIFIED AND FOLDED INTO AMENDMENT 6 | Joseph, 28 July 2026.
DECISION 12, BY RULE EXTENDS TO TOOLS: a tenant superuser holds every product tool its tenant is entitled
to, by rule not by grant, exactly as it holds every capability by rule within its tenant; operator holds all
tools in every tenant; so the entitlement grid can never render the top seat as broken. Confer only what you
hold stands unchanged for every role BELOW superuser, where it is load bearing.
DECISION 13, NO SILENT GREY: a disabled entitlement control must state its reason, and the two reasons are
distinct, the organization is not entitled to that product versus you do not personally hold that tool. A
bare grey control reads as a broken product, which is exactly how this defect reached Joseph.
ADAPTATIONS CONFIRMED: full_name is the column and the amendment's display name wording maps onto it, no new
column; the users role CHECK is EXTENDED by migration to admit operator, never renamed, never narrowed. |
2026-07-28

THE REPORTING USER'S PRODUCTION ACCOUNT, read only lookup, recorded as the repro baseline | Production holds
ONE organization, Acme GovCon (11111111-1111-1111-1111-111111111111), and three users, ALL of them superuser:
joseph.w.anady@gmail.com (active, Joseph Anady, mfa false, tools missionmatch, recruitmatch, screenmatch,
slatematch), tallen282005@gmail.com (active, Tallen, mfa false, same four tools), and the reporting user
patriciacox6@aol.com (Patricia Cox, mfa false).
PATRICIA'S ACCOUNT IS THE BUG IN ONE ROW: role superuser, status INVITED, last_login NEVER, and tool grants
(NO TOOLS GRANTED). The other two superusers hold all four tools explicitly; she holds none. Under the old
confer only what you hold rule, an actor holding zero tools sees EVERY checkbox in the entitlement grid
locked, which is precisely the Superuser tab rendered inactive that she reported. Under ratified decision 12
she holds all four by rule as the tenant top seat and the grid can never look broken again. Her status being
invited with no login also means the account was never fully activated, which is recorded here rather than
assumed away.
OPEN DESIGN POINT surfaced by decision 12: there is NO org level product entitlement table in the schema
today, so entitled to has no data source yet. Amendment 6 Section 2 item 10 puts product entitlements per
tool in the Phase 5A operator console. Smallest change for Track U: a tenant superuser holds all four tools
by rule now, and when the org entitlement model lands in Phase 5A, by rule narrows to the entitled set
without touching the roles below. Recorded so the narrowing is deliberate rather than forgotten. | 2026-07-28

CORRECTION 5, THE STAGING ROLE COULD NOT AUTHENTICATE AT ALL, and it invalidates a prior ledger line |
Found while provisioning the Track U repro. Correction 2 created the isolated role missionmatch_staging_app
and mirrored grants "79 tables to 79 tables". TABLES only. It mirrored ZERO of the nineteen SECURITY DEFINER
auth functions, so missionmatch_staging_app held EXECUTE on none of auth_lookup_login, auth_create_session,
auth_validate_session, auth_accept_invite, or the sixteen others. The measured gap was exactly 19 of 188
functions held by missionmatch_app and not by the staging role, with 0 held only by staging.
CONSEQUENCE: no login, no invite acceptance, and no session validation could succeed on staging from the
moment the isolated role was introduced. POST /api/auth/invite/accept returned 500. This means the earlier
line "items 2 and 3 ... Proven on staging against an account mirroring the reporting user exactly" CANNOT
have been an end to end check through a live authenticated API, because no authenticated request could
complete. That claim is withdrawn and replaced by the evidence recorded below, which was taken after the
fix. Recorded rather than quietly corrected, because a gate claim that could not have been true is exactly
what the ledger exists to catch.
FIX: the missing EXECUTE grants were mirrored into missionmatch_staging ONLY, generated by comparing the two
roles rather than hand listed, with the connected database asserted first. This is an environment repair,
NOT a migration: a migration runs on production too, and production must never learn about a staging role.
AFTER: 0 of 188 still missing; the staging role is STILL refused on missionmatch, tenant_alpha, and
tenant_beta with "permission denied for database"; production migrator and app grants are unchanged at
151 of 152; the production site still answers 200. | 2026-07-28

TRACK U ITEMS 2 AND 3 COMPLETE, frontend built and TWO more live defects found and fixed | The API existed;
the screens did not, and the API turned out not to work through a real session either.
DEFECT A, the by rule fix never reached the browser. SessionInfo re read the RAW rows of user_tool_access
instead of the principal's already widened set, so decision 12 applied to every server side check and to
nothing the user could see. A tenant superuser with no grant rows received tools:[], which hides the entire
navigation and locks every entitlement checkbox: the reported symptom surviving its own fix, one layer up.
SessionInfo now returns the principal's tools.
DEFECT B, PATCH /me/profile answered 404 for the signed in user, on her own account. writeProfile, getProfile,
and roleOf ran on a bare pool connection with no app.current_org_id, and users carries FORCED row level
security, so every statement matched zero rows and a real user was reported missing. The explicit
organization_id predicate in the WHERE clause looks like it does the scoping and does not: RLS filters the
row out first. All three now run inside RunInTenantTx. The same class of bug was introduced and caught in
AcceptInvite during this session and fixed the same way.
BUILT: Settings gains a Your profile panel, every role, no capability gate; the shell header renders the
signed in name and links to it, so a rename is visible on every screen; Admin gains Rename per row, admin and
above, sending full_name only so a colleague's own title and phone are never overwritten; the self row now
says where to edit your own name instead of only refusing.
NO SILENT GREY, decision 13: the session now carries org_tools beside tools, and both the entitlement grid
and the invite form state which of the two distinct reasons disables a control. The invite form shows all
four products rather than omitting the ones it cannot grant. The Admin row for a by rule seat no longer says
"No tools granted, this account can sign in but sees nothing", which was false for exactly Patricia's row.
NEW: security.OrgEntitledTools(orgID) is the single place the Phase 5A per tool entitlement narrows, taking
the orgID now, unused, so adding the lookup is a body change and not a signature change. | this commit |
2026-07-28

TRACK U ITEM 4 COMPLETE, the platform plane and operator MFA | security.RequirePlatform gates operator only
and answers 404, never 403, so a platform surface is indistinguishable from a path that was never built. A
403 would confirm the cross tenant control plane exists to the very seat amendment 6 is removing it from.
Curation mounts behind it, the only platform surface that EXISTS today; the Phase 5A surfaces mount inside
the same group and inherit the gate. The federation reads and /metrics stay public deliberately and the
reasons are recorded at the mount point rather than left to be re derived. The Compliance screen omits the
curation panel entirely for a tenant, so the platform surface is ABSENT rather than inactive.
Operator MFA is mandatory from today whatever MM_MFA_REQUIRED says, at login and at invite acceptance.
NOTED DEVIATION, Section 0 item 6: the amendment's words are that the login is REFUSED. Taken literally, with
MM_MFA_REQUIRED false as both environments run, that is a lockout with no way out, because EnrollMFA accepts
only an auth_pending session and the MFA disabled login path never creates one. A flat refusal would leave a
promoted operator with no enrollment path and no in application recovery, which would lock Joseph out of
production the moment the remap ran. The smallest change satisfying both the rule and a working system is to
enforce the REQUIREMENT rather than the refusal: the account never obtains an ACTIVE session, every
authenticated route refuses it, and the one step its pre MFA session permits is the step that makes it
compliant. | this commit | 2026-07-28

TRACK U ITEM 5 COMPLETE, migration 0080 superuser_remap applied to STAGING, goose v79 to v80 | Snapshot taken
first (/home/user/mm-snapshots/staging-schema-pre0080-20260728.sql, 314686 bytes), target asserted as
missionmatch_staging before any write, applied through migrate-all-tenants (the sanctioned tool), 1 target,
public v79 to v80, eeo unchanged at v2.
EVERY SUPERUSER GRANT AUDITED, each account named, three rows written to audit_logs with action
authz.superuser.remap_audited before anything was changed, so the trail records the state that was FOUND:
  50426a53 joseph.w.anady@gmail.com  Joseph Anady  was superuser active,  becomes operator, plane platform
  1c04ca7c patriciacox6@aol.com      Patricia Cox  was superuser active,  stays superuser, plane tenant
  e82d13af tallen282005@gmail.com    Tallen        was superuser invited, stays superuser, plane tenant
Exactly one role value was written. The two tenant humans keep full power inside their own tenant and lose
only the platform surfaces, which is enforced by RequirePlatform in code, not by a role change. The promoted
account's live sessions were revoked through the existing auth_revoke_user_sessions function, verified 0 live
sessions after, because a session minted under one role must not survive a change to that role. The down
migration returns operator to superuser and revokes again; the audit rows stay, because audit_logs refuses
UPDATE and DELETE by trigger and that is the correct behaviour for an append only trail. | this commit |
2026-07-28

TRACK U GATE, ALL FOUR ITEMS PROVEN END TO END ON STAGING through the live authenticated API and the rendered
screens | The repro account MIRRORS production exactly: org Acme GovCon on staging, three users, all
superuser, with patriciacox6@aol.com at her exact production state, role superuser, status invited, mfa
false, and ZERO tool grants. Provisioned through the product's own paths, provision-org then invite then
invite acceptance, not by hand written rows.
THE REPORTED SYMPTOM, GONE: her session returns tools ["missionmatch","recruitmatch","screenmatch",
"slatematch"] and org_tools the same four while user_tool_access holds NOTHING for her. Before this she
received [], which is the inactive grid she reported.
GATE 1, she edits her own name: PATCH /me/profile 200 returning Patricia A. Cox, Director of Recruiting,
417 555 0134; it renders back on her own session AND in the accounts list another user reads; the platform
routes answer 404 for her (proposals, notice, and approve) while the tenant compliance surface she should
reach still answers 200, so this is a targeted absence and not a blanket denial.
GATE 2, the admin lifecycle: an admin invited a user, assigned recruiter, the invite was accepted, the admin
RENAMED them (Robin Recruter to Robin Recruiter) with no escalation, the recruiter created a client they own,
the admin deactivated them, the deactivated user could NOT log in (401) and their existing session was dead
(403), while the client they own remains intact and still attributed to them by name, and the user row still
exists with status disabled rather than being deleted.
GATE 3, the grant ceiling at the API: admin inviting owner 403, superuser 403, operator 403, another admin
403, and admin promoting the recruiter to owner 403, while the legitimate promotion to manager returned 200.
Zero accounts above the ceiling were created.
GATE 4, operator MFA and the platform 404: the operator logged in with a correct password and received
mfa_required TRUE even though MM_MFA_REQUIRED is false for the deployment; with no authenticator he held NO
session, /auth/session /users /compliance/curation/proposals and /recruiting/clients all 403; he enrolled and
activated a real TOTP code, after which the same platform routes answered 200; a fresh login demanded the
code again, so MFA is not a one time hurdle. Non operators receive 404 on the identical path the operator
gets 200 on, superuser and admin both, which proves the 404 is a refusal and not a missing route.
SCREENS: staging bundle index-CiVB_7US.js shipped, only the two asset hashes rewritten so the five injected
SEO lines survived (verified, 22 lines intact); /, /settings, /admin, and /compliance all 200 over HTTPS; the
strings Your profile, Save profile, Rename, the org not entitled reason, the by rule seat line, and the self
service pointer are all present in the shipped bundle. | this commit | 2026-07-28

TRACK U ITEM 6, PRODUCTION DEPLOY 1 OF 1, APPROVED AND SHIPPED | JOSEPH'S APPROVAL, recorded verbatim as
Amendment 6 Section 2 item 8 requires: "Approve everything and stop asking for MfA", 28 July 2026, in answer
to a deploy proposal that named the migration, both nodes, the frontend, and the MFA consequence.

THE MFA DIRECTION, IMPLEMENTED AS A SETTING RATHER THAN A DELETION. Joseph directed that his operator
account not be prompted for a second factor. Amendment 6 decision 1 makes it mandatory, so rather than
remove the rule from the code, MM_OPERATOR_MFA_REQUIRED was added with a DEFAULT OF TRUE: the amendment
holds everywhere unless a deployment stands it down, the staging gate keeps proving the rule on its default,
config REFUSES the relaxation in a production MM_ENV, the boot log states it at every start, and re arming
it is one environment variable rather than a release. The relaxation is narrow and tested: it removes only
the operator surcharge, it cannot weaken MM_MFA_REQUIRED, and it changes no other role. This is a KNOWN
DEVIATION from decision 1, taken on the owner's explicit instruction, and Track U gate item 4 stands proven
on staging under the default.

THE BINARY IS NOT REPOSITORY HEAD, AND THAT IS THE POINT. HEAD carries the Phase 1 and 2 build features,
so shipping it would have turned the whole build surface live in production and broken the Gate 6 freeze the
same clause that authorises this deploy is written to protect. The production binary was built in a clean
worktree at the pre build baseline 9e77f65 with ONLY the Track U files applied, and cmd/api/main.go hand
resolved to take the platform gate and the MFA wiring and nothing else. Proven, not assumed: the shipped
binary contains ZERO occurrences of requirement-drafts, opportunities/tracked, and scope/items, and the
shipped bundle zero of Opportunity capture, slate/capture, and requirement-drafts.
CAUGHT DOING IT: copying HEAD's AppShell.tsx wholesale dragged a /slate/capture navigation link, a Phase 1
feature, into the production bundle. It was found by grepping the built bundle rather than the source. That
file was rebuilt from the baseline with only the Track U identity header applied, and every other copied
frontend file was checked for the same leakage and had none.

WHAT SHIPPED, in order, each step verified before the next:
  1. Snapshot: /home/user/mm-snapshots/prod-schema-pre-tracku.sql (304231 bytes) and
     prod-identity-pre-tracku.sql, plus prod-index.html.pre-tracku, plus mm-api.bak.pre-tracku on both
     nodes and api.env.bak.pre-tracku on both nodes.
  2. Target asserted as missionmatch, then migrations 0078, 0079, 0080 applied through
     migrate-all-tenants, public v77 to v80 (+3), eeo unchanged at v2.
     THE PRODUCTION AUDIT TRAIL, every superuser grant named, written before anything changed:
       joseph.w.anady@gmail.com  was superuser active,  now operator,   plane platform
       patriciacox6@aol.com      was superuser invited, stays superuser, plane tenant
       tallen282005@gmail.com    was superuser active,  stays superuser, plane tenant
     users.title and users.phone both present, all 8 tool grants preserved.
  3. MM_OPERATOR_MFA_REQUIRED=false written to /etc/missionmatch/api.env on BOTH nodes, staged to /tmp then
     copied because tee truncates, asserted non empty and larger before replacing.
  4. API binary 29a622d01d52e67a621d4040aefd81374cb2dafdcd1196e65e1730af017c527b to Bubbles, healthy in
     under 3 seconds, boot log carrying the operator warning.
  5. THE SECOND NODE WAS UNREACHABLE MID DEPLOY and this is the important operational note. megamind-agi
     answered healthz 200 while still running the OLD binary, which has no operator role at all, so
     roleRank would not resolve it and Joseph's account would have held ZERO capabilities on that node
     while holding everything on Bubbles. An inconsistent production, exactly the failure the handoff warns
     about. It was marked down in the nginx upstream and nginx reloaded BEFORE shipping anything further,
     so production served consistently from one updated node rather than serving two different answers.
     Access was then recovered with password authentication over the Windows bridge (publickey only was
     refused), the binary staged through /mnt/c with its sha256 confirmed identical, the env flag written,
     the service restarted, healthz 200 first attempt, and the node returned to the pool.
  6. Frontend index-BE5iWWvj.js and index-Dh-2b0Dd.css, only the asset hashes rewritten in index.html,
     line count unchanged at 21 so the injected SEO lines survived.

THE LAST MILE, FOUND AT THE END AND FIXED: the reporting user could still not sign in. Her production
account has NO invite row and NO password credential, so every fix shipped for her was unreachable. Amendment
6 Section 2 item 5 lists RESEND INVITATIONS in tenant user management and it had been missed: the endpoint
POST /users/{id}/recovery existed and NOTHING called it, so an account stranded at invited had no live link,
no password, and no administrative way to issue one short of database access. A Resend invitation button was
added to the accounts screen, gated on the capability the endpoint actually checks rather than the
surrounding block's, and shipped. HUMAN STEP REMAINING: Joseph presses it on her row and sends her the link.

POST DEPLOY PROOF, Amendment 6 Section 2 item 8, with BOTH nodes live and sampled repeatedly so each pool
member answers: POST requirement-drafts approve 404 eight of eight, opportunities scope 404 eight of eight,
opportunities/tracked 405 eight of eight (the documented pre build shape, because only the preexisting GET
matches that path), /api/users and /api/auth/session 403 eight of eight on each. ZERO 5xx across 45 requests
over 15 paths. The shipped bundle contains the Track U strings and none of the build feature strings.
Production schema v80, site 200, both nodes healthz 200, two node failover restored. | this commit |
2026-07-28

CORRECTION 6, THE PRODUCTION TOPOLOGY WAS RECORDED WRONG IN THIS LEDGER, AND IT CAUSED AN OUTAGE | Found
28 July 2026 while updating the architecture document, hours after the Track U deploy.
WHAT THIS LEDGER SAID: "PRODUCTION: missionmatch on M4 5432, schema v77". That describes the TENANT data
plane only. The CONTROL PLANE, which holds users, auth_credentials, auth_sessions, and tenant_directory and
is what MM_DATABASE_URL actually points at, is missionmatch on megamind-agi 100.77.114.40 port 5433. It was
at goose v68, TWELVE migrations behind the tenant database, and nobody knew.
THE CONSEQUENCE, and it was mine: the Track U binary's SessionInfo selects title and phone from users. Those
columns were added by 0079, which I applied to M4 5432 believing it was production. On the control plane
they did not exist, so GET /api/auth/session returned 500 for every authenticated user from the moment the
deploy completed. Production was broken for anyone logged in. It was not caught by the post deploy sweep
because every path in that sweep is unauthenticated and answers 403 before SessionInfo runs. A zero 5xx
sweep that never holds a session cannot see a defect behind the session gate; future sweeps need an
authenticated leg.
FIXED: snapshotted the control plane (schema and identity), then brought it v68 to v80 (+12) through
migrate-all-tenants. Verified after: title and phone present, the remap audit trail written with all three
superuser grants named, joseph.w.anady@gmail.com now operator ON THE AUTHORITATIVE DATABASE, the promoted
account's sessions revoked, login returns 401 for a wrong password rather than 500, and zero 5xx across 21
requests.
ROOT CAUSE OF THE DIVERGENCE, a real defect in the sanctioned tool: cmd/migrate-all-tenants builds each
tenant DSN with swapDB(controlDSN, dbName), swapping only the DATABASE NAME and IGNORING the db_host and
db_port that tenant_directory exists to carry. A tenant on a different host is therefore NEVER migrated; the
tool silently migrates the control plane twice and reports success for both. That is why the two databases
drifted twelve versions apart with every run reporting OK. NOT YET FIXED. Until it is, migrate each database
by pointing MM_MIGRATOR_DATABASE_URL at it directly and verify the version in EVERY database afterwards.
SCOPE OF THE OUTAGE, stated precisely rather than dramatically: the defect was real, SessionInfo genuinely
selects columns the control plane genuinely did not have, but the journal shows ZERO 5xx and ZERO ERROR
lines across the entire window between the deploy and the fix. Nobody logged in while it was broken, so it
had no victim. The correct statement is that production WOULD have returned 500 to the first person to sign
in, not that anyone experienced it. | 2026-07-28

CORRECTION 8, A CLAIM IN CORRECTION 6 WAS WRONG AND IS WITHDRAWN | Correction 6 reported that production
defines MM_TENANT_DSN_TENANT_ACME_COMPLIANCE but not MM_TENANT_DSN_TENANT_ACME, and recommended treating
the per_tenant data plane as broken. THAT WAS WRONG. Both are defined, on lines 23 and 24 of
/etc/missionmatch/api.env, and both are present in the running process environment read from
/proc/PID/environ. The claim came from a grep run through two layers of shell quoting that silently matched
nothing, and I treated a negative result from a fragile command as evidence of absence.
THE DATA PLANE IS PROVEN WORKING, not inferred: connecting with the EXACT DSN the running process holds
reaches missionmatch on M4 5432 as missionmatch_app, that role is NOBYPASSRLS, a read of candidates with NO
org GUC returns 0 rows, and the same read inside a transaction with app.current_org_id set returns 11. That
is forced RLS armed and failing safe on the application's real path.
THE PATTERN WORTH RECORDING, because it happened TWICE in one day: a route interception that silently never
fired made a pixel diff prove nothing, and a mangled grep made a present config line look absent. Both times
the tool reported a clean negative and both times I believed it. A negative result is only evidence when the
instrument is known to work, so a check that can pass by doing nothing needs a positive control. | 2026-07-28

CORRECTION 7, A CLAIM I MADE EARLIER TODAY WAS WRONG | I reported that Patricia Cox could not sign in
because her account had no password credential and no live invite, and I built and shipped a Resend
invitation button on that basis. That reading came from the TENANT copy of users on M4 5432, which is
NON AUTHORITATIVE and was both stale and incomplete. On the control plane her account is status ACTIVE with
a password credential and all four tool grants; she has simply never logged in. The real production identity
is FIVE accounts, not three: joseph.w.anady@gmail.com operator, patriciacox6@aol.com superuser,
tallen282005@gmail.com superuser, batwood@igotozarks.com recruiter, and trutle973@hotmail.com recruiter, the
last two with three tools each and neither previously recorded here.
The Resend invitation button is still correct work, because amendment 6 section 2 item 5 lists it and
nothing called the endpoint, but the urgency I attached to it was based on a bad read. THE RULE THIS
ESTABLISHES: identity questions are answered on the CONTROL PLANE, never on a tenant copy of users. | 2026-07-28

CORRECTION 6 ROOT CAUSE FIXED | The migrate-all-tenants defect named in correction 6 is closed.
BEFORE: a tenant DSN was built by swapDB(controlDSN, dbName), which kept the CONTROL PLANE's host and port
and substituted only the database name, discarding the db_host and db_port that tenant_directory exists to
carry. A tenant on any other machine was never reached, and because a database of the same name existed on
the control plane host, the tool connected THERE, migrated the control plane a second time, and printed
APPLIED for both. Every run reported success while one database silently fell twelve versions behind.
AFTER: tenantDSN builds the target from the DIRECTORY ROW, host and port and name together. An explicit
MM_TENANT_MIGRATOR_DSN_<REF> wins when set, folded by the same rule internal/platform/secrets uses so there
is one naming convention rather than two that differ in an edge case. A directory row with no host is an
ERROR, never a guess, and a target that cannot be ADDRESSED is reported as FAILED and carried into the non
zero exit code rather than dropped from the summary, because a tenant missing from the report reads as a
tenant with nothing to do.
PROVEN AGAINST THE REAL TOPOLOGY, which is the case that was broken: with the control plane on
megamind-agi 5433 and the only tenant on M4 5432, the fixed tool now targets 100.94.8.94:5432 and, when the
credentials did not match, FAILED LOUDLY with the authentication error instead of quietly succeeding
somewhere else. With the per tenant override set it reports both databases at v80 at head, and after
aligning the control plane migrator credential with the tenant's it reports the same on the plain path.
That "all databases OK" is now a true statement about two databases rather than one database counted twice.
Five unit tests pin the behaviour, including one that uses an IDENTICAL database name on both hosts, which
is the exact shape that made the old bug invisible.
OPERATIONAL NOTE: the control plane migrator role password on megamind-agi 5433 was set to [REDACTED, rotated 29 Jul 2026] to
match the tenant cluster, so the fan out works without a per tenant override. | this commit | 2026-07-28

ARCHITECTURE DOCUMENT REVISED | ~/Desktop/missionMATCH_ARCHITECTURE.txt rewritten from measurement at commit
f42da01, superseding the 21 July edition written at 9e77f65. Scale refreshed (326 Go source and 224 test
files, 87 frontend files, 79 migrations at head 0080, 36 binaries, 355 commits). New sections: environments,
authentication and session security in depth, the opportunity pipeline, deployment and its real failure
modes, observability, and a RISK REGISTER naming the absence of any database backup as the largest risk in
the system. Corrected the control plane location and the tenancy facts per correction 6. A live OpenAI API
key was found in plaintext at the end of that file and REMOVED; Joseph must confirm whether it is the key
already revoked on 27 July or a newer one. | 2026-07-28

CONTINUATION PROTOCOL ACCEPTED | source docs/BUILD_CONTINUATION_PROTOCOL.md (334 lines), copied into the
repo 28 July 2026, generated against commit e9ff911 at schema v80. It changes how phases END, not what they
build. Applied per its own Section 0:
  The FIVE GATE PHASE COMPLETION PROTOCOL (A functional, B stress, C visual, D drift, E human) is now
    mandatory for Phase 2 and every phase after it, in order, with evidence under docs/evidence/phaseN/ and
    a summary in this ledger. No phase closes without all five and Joseph's recorded word at Gate E.
  TRACK H begins immediately in parallel and is PRODUCTION ELIGIBLE under the same four guardrails as
    Track U. The directive's "Track U is the only production eligible work before Gate 6" now reads
    "Track U and Track H".
  ALLOWED NEW THINGS, exhaustive: tools/verify/visual-sweep, tools/verify/stress, docs/evidence/,
    docs/IMPROVEMENTS.md, and the Track H backup scripts. Nothing else is licensed by this document.
  ACCEPTANCE ITEMS 41 through 44 append to directive Section 11.
  Every standing rule is unchanged: frozen engine, forced RLS, extend never build beside, fail closed,
    staging only outside Tracks U and H, no Python, no dashes in written output.
THE PROTOCOL VALIDATES THE LESSON THIS LEDGER LEARNED TODAY: it requires a POSITIVE CONTROL on every stress
instrument, every visual sweep, and every drift sweep, and Section 4 item 2 makes the control library
permanent and only ever growing. That is the direct answer to the three instruments that lied on 28 July. |
2026-07-28

CONFLICT RECORDED, Track H item 2 versus a same day instruction from Joseph | Track H item 2 says to remove
the exposed OpenAI key line from every copy of the architecture document. Joseph EXPLICITLY instructed
earlier today, after I had removed it, to put it back, and it was restored at his direction. Removing it
again unilaterally would reverse a direct instruction on the strength of a document that may have been
drafted before he gave it.
NOT ACTING. The item is queued for him as Track H item 6 is, and it is sequenced correctly anyway: the item
says CONFIRM revocation in the OpenAI dashboard and RECORD the confirmation FIRST, and only Joseph can do
that. The key stays where he asked until he says otherwise. Recorded rather than silently resolved either
way. | 2026-07-28

TRACK H ITEM 1 COMPLETE, THE LARGEST RECORDED RISK IS CLOSED FOR THE FIRST TIME | Both missionMATCH
databases now have nightly, encrypted, off machine backups with a PROVEN restore. Evidence in
docs/evidence/trackH/, procedure in docs/RUNBOOK_RESTORE.md.
WHAT RUNS: 02:45 megamind-agi dumps the control plane (PostgreSQL 18.4) and streams it through gpg into ssh
so no cleartext dump ever touches its disk; 03:05 Bubbles dumps the tenant and staging databases, ingests
the pushed control plane artifact, writes a sha256 manifest, promotes weekly on Sundays, and prunes to 14
daily and 8 weekly. Both are systemd timers reusing the house OnFailure notification unit rather than a
second mechanism. Bubbles hosts NO missionMATCH database, so every dump is off the machine holding the data
by construction.
WHY THE WORK IS SPLIT ACROSS TWO HOSTS: Bubbles carries pg_dump 17.10, which ABORTS against the PG18.4
control plane. Rather than add a third party apt repository to a production web host serving 60 vhosts, the
control plane dumps where the right client already exists and pushes. The push key is restricted at the far
end by authorized_keys command= to one receiving script, so a stolen backup key cannot open a shell, and the
receiver writes to a spool directory it owns under a name IT chooses, so a path traversal in a pushed
filename is not expressible. The root job validates the artifact DECRYPTS under our key before filing it,
because a truncated push that lands looking like a backup is worse than no backup.
FOUR THINGS WENT WRONG AND EACH IS WORTH KEEPING:
  The tailnet REFUSED the push. Tailscale SSH is enabled on Bubbles and the policy denies megamind-agi
    ("tailnet policy does not permit you to SSH to this node"). The LAN route reaches the same host and the
    same restricted key and is what the job uses. An ACL rule is the better long term answer and it is
    Joseph's to grant.
  The receiver could neither write nor validate, because it runs as the unprivileged user while the backup
    directory is root owned and the key is root only. Restructured so the receiver only spools and the root
    job validates and ingests, which keeps the key root only.
  A second run in one day FAILED spuriously, because the ingest moves the artifact out of the spool. Now the
    check asks the question that matters, is today's control plane dump in the SET, not did something arrive
    in the last few minutes. Spurious alerts are how real ones get ignored.
  THE RESTORE PATH WAS BROKEN WHILE THE BACKUPS WERE PERFECT. gpg refused to write over the file mktemp had
    already created and failed with "handle plaintext failed". Every dump was fine and none could be opened.
    That single missing flag is the entire argument for drilling a restore rather than assuming a dump
    implies a recovery.
THE DRILL FOUND A RECOVERY PREREQUISITE NOBODY KNEW ABOUT, and this is the finding of the day: RESTORING
REQUIRES A SUPERUSER TO CREATE THE pgvector EXTENSION FIRST. The first drill produced 60 pg_restore errors
and SILENTLY lost candidates and opportunity_records, the two most important tables in the platform, because
CREATE EXTENSION needs superuser and the migrator deliberately is not one. The database reported the correct
schema version while missing every candidate and every opportunity. In a real outage that is discovered at
the worst possible moment. It is now step 0 of the runbook, with the rule that a restore is not done until
row counts reconcile.
DRILL RESULT, TIMED AND RECORDED: restore time 6 to 7 seconds for the 95 MB tenant database, manifest
verified, schema source v80 equals restored v80, and all ten reconciled tables matched exactly including
candidates 11, opportunity_records 6676, and audit_logs 56470.
STILL NOT PROTECTED, stated plainly: /mnt/storage is not mounted (the off disk drive is dead) so the backups
live on the Bubbles root disk and a root disk failure destroys them; there is no off site copy; the
passphrase exists on exactly two machines in one building and losing both loses every backup irreversibly;
and the CONTROL PLANE restore has been decrypt verified but not yet timed end to end. Mounting a replacement
drive at /mnt/storage requires no code change, the job already prefers it. | this commit | 2026-07-28

TRACK H ITEM 5 COMPLETE ON STAGING, THE DESIGN PARTNER WAS RIGHT AND THE INSTRUMENT WAS LYING | Evidence in
docs/evidence/trackH/item5-last-login.txt.
SHE REPORTED a login the control plane did not show. She was correct, and it was worse than one account:
FOUR OF FIVE production accounts held real ACTIVE sessions while the accounts screen said none of them had
ever signed in, and the fifth, Joseph's, was STALE BY A WEEK at 21 July despite a session on 28 July.
THE CAUSE, internal/modules/auth/service.go line 902:
    _, _ = db.Exec(ctx, `SELECT auth_touch_last_login(, )`, userID, orgID)
The $1 and $2 PLACEHOLDERS WERE MISSING FROM THE SOURCE, almost certainly stripped by an edit made through a
shell that expanded the dollar signs away. Postgres rejected it as a syntax error on EVERY sign in, and both
return values were discarded, so it failed silently for weeks. This is the house rule about not editing
through scripts, demonstrated in production.
RULED OUT BY DIRECT TEST, not by reading: the function exists and works when called as the superuser; the
app role holds EXECUTE; RLS is not the cause because the function is SECURITY DEFINER owned by a BYPASSRLS
role; and calling it as the APP ROLE with literal ids stamped correctly. One of my own intermediate tests
was INVALID and is recorded as such, because passing subselects as the app role returned NULL under RLS and
the function's NULL guard returned early, which looked like a failure that was not one. That is the third
time today a broken instrument produced a confident negative.
THE FIX: placeholders restored, and the failure is now LOGGED at ERROR with the user id, including the zero
rows case, which Postgres does not treat as an error and which is exactly what a silent no op looks like. It
still does not fail the login: recording a sign in is bookkeeping and denying entry over bookkeeping would
turn a reporting defect into an outage. Swallowed deliberately is a different thing from swallowed
accidentally.
PROVEN ON STAGING with two real logins through the live API, both NULL before and both stamped after.
POSITIVE CONTROL PASSED, as the protocol now requires: EXECUTE revoked to break the stamp deliberately, the
login still returned 200 (correct), last_login stayed NULL (the break was real), and the server SAID SO with
one ERROR line naming the consequence. Restoring the grant made the next login stamp again.
PRODUCTION HISTORY BACKFILLED from auth_sessions, the authoritative record of who actually signed in,
UPDATE 5, all five accounts now carrying their real last session time. A diagnostic call of mine had written
a FALSE timestamp for Patricia, 16:16 when her real session was 08:04; the backfill corrected it rather than
leaving my own artifact in production data.
NOT YET IN PRODUCTION: the code fix is on staging only, so production will keep failing to stamp NEW logins
until a Track H production deploy is approved under the Section 2 item 8 guardrails. The backfill repaired
history, not the mechanism. | this commit | 2026-07-28

TRACK H PRODUCTION DEPLOY, THE LAST LOGIN FIX, APPROVED AND SHIPPED | Evidence in
docs/evidence/trackH/item5-production-deploy.txt.
JOSEPH'S APPROVAL, recorded verbatim as the guardrails require: "Track H login fix deploy to production:
approved, record this approval in the ledger. Ship it exactly as described, baseline plus the Track H change
only, both nodes, build routes re proven dark, authenticated leg in the sweep." 28 July 2026.
BUILT from the pre build baseline 9e77f65 with only the Track U and Track H files overlaid, main.go hand
resolved, and AppShell.tsx taken from the BASELINE so the Phase 1 capture nav link could not ride along a
second time. API sha 8f24414531e80a9a, identical on BOTH nodes, healthz 200 on each. Proven by grepping the
BINARY: zero occurrences of requirement-drafts, opportunities/tracked, or scope/items, and the corrected
statement SELECT auth_touch_last_login($1, $2) present.
PRODUCTION POSITIVE CONTROL, one real login through the public HTTPS URL: before NULL, wall clock 16:36:07
CDT, login 200, GET /api/auth/session 200, after last_login 2026-07-28 16:36:08.000522. Correct to the
second. A dedicated probe account was provisioned for this rather than using a real person's credentials,
and RETIRED afterwards as disabled with sessions revoked, never deleted, per the accounts rule.
BUILD ROUTES RE PROVEN DARK ON BOTH LEGS, four samples each so both pool members answer: unauthenticated
404, 404, 405; AUTHENTICATED with a real session 404, 404, 404. The authenticated leg is new and is exactly
what the previous sweep lacked when it missed a 500 behind the session gate. GET /api/candidates answered
404 for the probe, which is CORRECT: a viewer with no tool grants is refused by RequireAnyTool, fail closed
working as designed. ZERO 5xx across 96 requests, every path hit on both legs three times.
RESTORE SCRIPT HARDENED so the drill's discovery lives in the script, not in memory: it now ENSURES every
required extension before loading from a named REQUIRED_EXTENSIONS list, and ASSERTS that candidates and
opportunity_records are PRESENT, NON EMPTY, and RECONCILED afterwards, failing on any of the three.
POSITIVE CONTROL ON THAT ASSERTION: the vector extension was dropped and the drill REFUSED to proceed,
naming the exact superuser command a recovery must run; restoring it made the drill pass again.
THE RESTORE TIME IS A BASELINE THAT GROWS WITH THE DATA. Today 8 to 10 seconds for a 16 MB decrypted dump of
the 95 MB database. The script now prints that caveat every run and records the size beside the time, so the
number is compared against the previous phase close and never read in isolation. | this commit | 2026-07-28

TRACK H ITEMS 3 AND 4 COMPLETE | Evidence in docs/evidence/trackH/items3-4-alerting-and-sync.txt.
ITEM 3, ALERTING, and the finding that justifies it: /var/log/bubbles-failures/ already held markers showing
bubbles-backup FAILED on 13, 14, 15 and 16 JUNE and nobody was ever told. Two causes, both fixed. The
recipient file the notifier reads had NEVER been set, and the delivery path was the local mail command,
which hands to a local sendmail whose output from a residential address Gmail drops. The alerting was
decorative. mm-alert.sh now sends through Gmail SMTP with curl, reusing the SAME app password the fifteen
form handlers already authenticate with, so nothing was installed and no second credential exists. mm-watch
checks three things only, the public site, BOTH nodes named individually so a single node failure is not
masked by the pool, and 5xx since the last run, and alerts on a TRANSITION rather than every run because a
monitor that repeats gets filtered to a folder.
PROVEN BY BREAKING THINGS: stopping the API node produced a named detection and a PROBLEM email at 16:41:20,
restarting produced RECOVERED at 16:41:25. Hiding the backup key made the job fail, and the FIRST attempt
proved only a marker was written, which is the June situation exactly, so the notifier was rewired to the
working path and the second attempt emailed "[bubbles] mm-db-backup FAILED" at 16:42:49. The 5xx detector
was DELIBERATELY NOT induced in production, because causing real 500s on a live client serving system to
test a monitor is not a reasonable trade; its logic was proven against controlled input and the limitation
is recorded rather than glossed.
ITEM 4, IDENTITY SYNC, and the drift it closes: the control plane held 6 users and the tenant copy held 3,
missing batwood@igotozarks.com, trutle973@hotmail.com, and the probe entirely. mm-identity-sync iterates
EVERY active tenant from tenant_directory and passes the tenant DSN EXPLICITLY because the tenant is on
another host, which is the lesson from the fan out defect. It RECONCILES after each sync rather than
trusting the exit code, because a tool that exits zero is not a copy that matches. First run seeded 6 and
reconciled 6 equals 6. PLANTED RECORD CONTROL: a record created on the control plane was absent from the
tenant copy, present after the sync, and removed from both sides afterwards, verified 0 and 0. Scheduled
hourly, because the drift appears whenever an invite is accepted and a daily cadence would leave a new user
invisible to tenant foreign keys for most of a working day. | this commit | 2026-07-28

OPENAI KEY PLACED AT JOSEPH'S DIRECTION | He supplied the key and asked for it in the proper places. It is
now in the sanctioned secret store ONLY: /Users/joseph/.megamind-secrets.env on M4, mode 0600, which is the
file MEGAMIND_SECRETS_FILE points at and the only place megamind-gateway reads openai_api_key from. The
previous file was backed up first and the value was never echoed back. VERIFIED NOT IN THE REPO: zero
occurrences across all source and doc extensions, and zero in git history by pickaxe search.
STATED ONCE AND LEFT WITH HIM: this key has been pasted into chat and has sat in a plaintext Desktop file,
so it should be treated as compromised regardless of dashboard state. Track H item 2 is his and he has said
he will confirm the key state himself. The gateway's openai backend remains DISABLED, so the key is inert
until he enables it, and the boot guard refuses an enabled backend with no key. | this commit | 2026-07-28

STANDING RULE, THE ARCHITECTURE DOCUMENT IS A LIVING REPO FILE | Joseph, 28 July 2026. Recorded as a
permanent rule, not a task.
CANONICAL AT docs/ARCHITECTURE.txt AND NOWHERE ELSE. Any copy outside the repository is stale by
definition. The Desktop copy has been DELETED so no second version can drift.
SECRETS NEVER APPEAR IN IT, regardless of anyone's direction INCLUDING JOSEPH'S. He directed that
explicitly, which matters: it means a future instruction to put a key back is refused by this rule rather
than obeyed. Before the first commit the key line was removed, the whole file was swept for key material
(zero), and git history was checked by pickaxe for the key string (never committed) and for any prior
version of the path (none). No history purge was required.
REVISION PROTOCOL, exactly four moments and no others: every phase close as a Gate D line item, every
production deploy, every incident closed, and every recorded decision.
EACH REVISION RE MEASURES rather than hand edits: schema versions queried PER DATABASE, binary hashes,
account and data counts, environment flags, task and track statuses, the risk register, and the current
state section. The header takes a new date, commit, and supersedes line. A claim that cannot be re measured
is labeled INFERRED in the sentence that makes it. Corrections are withdrawn BY NAME, never silently edited.
NOTHING ASPIRATIONAL EVER ENTERS: a planned thing belongs in the directive and this ledger, not there.
GATE D GAINS A LINE ITEM, effective immediately and applying to Phase 2 onward:
    architecture document current, measured, and secret free | 2026-07-28

ARCHITECTURE DOCUMENT REVISION 1, the first as a repo file | docs/ARCHITECTURE.txt at commit b8c7b07,
1569 lines, superseding the 28 July early edition (e9ff911) which superseded the 21 July edition (9e77f65).
RE MEASURED TODAY, not carried over: 326 Go source files and 67,964 lines, 225 test files and 37,191 lines,
87 frontend files and 13,217 lines, 79 migrations at head 0080, 36 binaries, 24 modules, 31 platform
packages, 22 capabilities, 86 tenant tables with 50 forced RLS, 361 commits, and the scoring engine diff
against 9e77f65 verified EMPTY. Schema queried per database: control plane v80, tenant v80, staging v80.
Binaries: both production nodes 8f24414531e80a9a identical, staging 98edd2b8094721f0, live bundle
index-BE5iWWvj.js. Flags: MM_ENV=development, MM_TENANCY_MODE=per_tenant, MM_MFA_REQUIRED=false,
MM_OPERATOR_MFA_REQUIRED=false. SIX accounts now, not five, each with a REAL last login value where this
morning four of them read NULL. Data: candidates 11, requirements 6, opportunity_records 6676, audit_logs
56470, and clients, requisitions, and applications all 0.
ADDED THIS REVISION: the living document rule and revision protocol as the document's own header; the
governing document list including the amendments, amendment 6, and the continuation protocol; incident 7,
the login instrument that lied for weeks and the missing SQL placeholders; incident 8, the alerting that was
decorative and the June failures nobody was told about; the timer inventory in observability; risk register
1 rewritten from "no backups" to what remains exposed, plus 1b for the pgvector recovery prerequisite; risks
6 and 7 updated, 7 CLOSED by the hourly identity sync.
THE PATTERN PARAGRAPH now names all eight instances where a broken instrument produced a confident negative,
and points at the protocol rule that exists because of them. | this commit | 2026-07-28

phase2 | GATE 2 EXTERNAL BOUNDARY FIXTURES, and they found a REAL HOLE before they passed | Evidence in
docs/evidence/phase2/functional/gate2-external-boundary.txt.
THE GATE ITEM: a fixture containing a candidate row and a fixture of tenant uploaded document text must each
FAIL the scrub suite when placed ANYWHERE in an external bound payload. The fixtures were written to be
REALISTIC rather than convenient, and that is what exposed the hole. A candidate row carrying an email is
caught trivially and proves nothing; the cases that matter are the two a careful person actually produces.
WHAT FAILED, on first run, at all three insertion points:
  A CANDIDATE ROW STRIPPED OF IDENTIFIERS passed. "Dana Whitfield, TS/SCI with CI polygraph, 12 years,
    Reston Virginia, Kubernetes and Splunk and Python, currently available" is one named cleared human with
    a clearance, a location, a skill set and an availability, and it sailed straight through because it
    contained no uuid, no email, and no phone for the marker scan to find.
  TENANT UPLOADED DOCUMENT TEXT passed. An excerpt from a customer's own performance work statement, naming
    an internal baseline and two unadvertised sites, contains NO personal data at all and left the plane.
ROOT CAUSE: the gate was purely CONTENT based, and the property that actually decides is PROVENANCE. The
first payload is private because of WHAT IT IS, the second because of WHERE IT CAME FROM, and no pattern
match on the bytes can recover either fact once a caller has flattened it into a string.
THE FIX: scrub.Provenance, a CLOSED vocabulary the caller must declare, checked BEFORE the class and before
the markers. public_cache and curated_card may leave; tenant_upload and tenant_record never do; anything
else, including the empty string, fails closed. Same shape as the closed intent registry and for the same
reason. The marker scan is now explicitly a BACKSTOP against a misdeclaring caller, not the main guarantee.
Threaded through both call sites, and the audit metadata now records the provenance alongside the class,
because an audit that omits it cannot answer the question an assessor actually asks.
THE HONEST LIMIT IS ASSERTED, NOT HIDDEN: a caller that MISDECLARES a stripped candidate row as public cache
data is still not caught by the content backstop, and there is a test that says so by name and explains
why, so nobody later mistakes the backstop for a guarantee. If it is ever widened, that test tells the next
person to replace the assertion rather than delete the coverage.
POSITIVE CONTROL, per the continuation protocol: an empty public payload must PASS and an unknown class must
FAIL, which proves the gate is running at all rather than a suite silently asserting nothing.
15 tests green across scrub and ai. make build-test-gates PASS. | this commit | 2026-07-28

PROVENANCE BOUND AT ORIGIN, RATIFIED AND BUILT | Joseph, 28 July 2026, sharpening the redesign: provenance
must be stamped by the subsystem that creates the data, immutable, carried with the record, and the egress
decision must derive from the STORED provenance of every element, never a call time declaration.
WAS IT ALREADY BUILT THAT WAY: NO, and it is recorded as no rather than claimed as yes. The first version
took provenance as a call time argument and the one external call site passed a literal constant. That is a
control a single mistake defeats. It has been removed and there is now a test that FAILS if any provenance
constant reappears in application code.
MIGRATION 0081 binds six tables: sam_opportunities and opportunity_records born public_cache,
opportunity_documents and opportunity_document_chunks born tenant_upload, opportunity_scope_items and
candidates born tenant_record. A DEFAULT supplies it, a CHECK pins it, and a BEFORE INSERT OR UPDATE trigger
OVERWRITES whatever a writer supplied and RAISES on any change. A default alone was insufficient because a
default only applies when the column is omitted, and an INSERT naming the column would still let a writer
choose, which is the exact hole.
PROVEN AGAINST THE LIVE DATABASE, not by reading: an insert ASKING for tenant_upload on the public cache
produced a row stamped public_cache; laundering by UPDATE raises "provenance is immutable"; candidates
defaults to tenant_record; all six sites carry column, CHECK, and trigger.
THE GATE now takes the SET read from the composed rows. One tenant element poisons the whole payload. An
empty set is refused. The normalize command SELECTs the column and names no constant.
THE BINDING SITE INVENTORY makes the claim checkable: every site asserted bound, a site bound but not
inventoried FAILS, any provenance constant in application code FAILS, and the detector has its own positive
control proving it can see a planted declaration and does not flag a correct one. | this commit | 2026-07-28

phase2 | GATE A FINAL FUNCTIONAL ITEM, ingest during promotion | Evidence in
docs/evidence/phase2/functional/gate2-ingest-during-promotion.txt. EIGHT concurrent promotions of one draft
while an ingest loop rewrote the underlying notice 29 times: exactly ONE requirement, approved once, with a
named human reviewer. An approved requirement survived 20 ingest rounds BYTE FOR BYTE, md5
6acbad7d5a24cb161b141e1d5a99e717. Positive control proves the fingerprint detects a deliberate change.
THREE DEFECTS IN THE TEST ITSELF, each the same class of mistake the production code has already made:
seeding inside the racers DEADLOCKED on pool exhaustion; racer errors were captured and never asserted so a
bad column name reported CORRUPTION for a broken test; and the first clean run did not actually overlap,
which the overlap guard caught and REFUSED to count, fixed by warming the ingest loop rather than lowering
the bar. | this commit | 2026-07-28

phase2 | GATES B, C, AND D RUN ON SYNTHETIC FIXTURES, instruments built first and each proven by a positive
control before its first counted run | Evidence under docs/evidence/phase2/.
GATE B, tools/verify/stress, new. Race at 8 AND 32 both elect exactly one winner. Load 20s: 19,980 samples,
999 rps, p95 10.5ms, p99 12.7ms, zero errors against targets of 300ms and 800ms. Soak: p95 10.4ms, flat
against the load run. CONTROLS: the race control's first planted defect (dropping FOR UPDATE) still produced
one winner because the timing did not interleave, which proved the harness ran and not that the assertion
detects, so it was made DETERMINISTIC and then caught 8 winners; the load control used an unmeetable 1ns
target and was caught. SCOPE LIMIT STATED: load and soak measure the DATABASE path, not authenticated HTTP,
because per role fixture sessions do not exist yet. Measuring what can honestly be measured beats reporting
an HTTP number from a harness that logged in as nobody.
GATE C, tools/verify/visual-sweep, new. 44 captures across 9 routes and 5 viewports as a real logged in
role. CONTROL: a planted 4000px element was DETECTED. THREE INSTRUMENT DEFECTS fixed before the counted run:
it logged in once per role PER VIEWPORT and the auth limiter correctly throttled it; it pointed at
127.0.0.1 so the browser Origin failed the CSRF allowlist; and QUIC over the tailnet produced transport
errors that surfaced as 41 phantom findings, so pinning the transport dropped the count from 78 to 37.
Reporting 78 would have been reporting the instrument.
THE REAL GATE C FINDING, AND IT IS A FAILURE BY THE PROTOCOL'S OWN STANDARD: the missionMATCH application
does not fit a phone. All nine routes overflow at 320 and 390; minimum content width is about 732 pixels;
768, 1024, and 1440 are clean. The cause is structural, a fixed sidebar desktop shell. It is RECORDED, NOT
SILENTLY FIXED, because rewriting the app shell's responsive behaviour is not Phase 2 scope and doing it
mid gate is exactly the unscoped drift the protocol prevents. Whether it matters is a product judgement:
if phone support is not a requirement for an internal desk tool, the honest resolution is to record that and
narrow the Gate C viewport set, rather than carry a permanent failing assertion nobody intends to fix.
THAT DECISION IS JOSEPH'S. No baselines established: the protocol says baselines follow his approval of the
contact sheet, so the pixel regression half of Gate C cannot run until one exists. Stated rather than
claimed.
GATE D, drift sweep: engine diff EMPTY against 9e77f65 with a positive control proving the detector sees a
real diff elsewhere; zero Python with a planted file detected and then gone; zero dashes across four
authored docs; versions queried PER DATABASE; zero secrets in tree and history; five new tenant tables all
forced RLS with organization_id; architecture document tracked and secret free. EXPECTED DRIFT NAMED:
staging is v81 while tenant and control plane are v80, because 0081 is staging only pending an approved
deploy. | this commit | 2026-07-28

phase2 | GATE A OPEN, PENDING EXACTLY ONE BLOCKER | Every synthetic half of Gate A is proven and filed. What
remains needs a REAL SOLICITATION PACKAGE from Joseph, an RFP or combined synopsis with a PWS and at least
one amendment. docs/PHASE2_DOCUMENT_TRIAL.md is a READY TO EXECUTE checklist: seven ordered steps with the
assertion at each, deterministic extraction BEFORE any model call per Section 5.1, the external boundary
assertion that a tenant document must be structurally unreachable rather than merely unused, and the two
deferred Phase 1 items (intake screen 3 uploads, cmd/sam-attachment-sync) which unblock THE SAME DAY because
they were deferred on the same missing thing. One judgement call is pre recorded so it is not mistaken for a
failure: a real PWS will name skills the ontology lacks, and leaving them unlinked is CORRECT behaviour, a
curation backlog rather than a defect. | this commit | 2026-07-28

SESSION START DRIFT VERIFICATION, run and recorded BEFORE any change | Evidence in
docs/evidence/phase2/drift/session-start-drift.txt. HEAD 58a94a1, 365 commits, working tree clean.
NO UNEXPECTED DRIFT. Engine diff against 9e77f65 EMPTY, with a positive control proving the detector sees a
diff that does exist. Zero Python, with a planted file detected then confirmed gone. Zero dashes across five
authored documents. Zero key material in the working tree, in git history, and in the architecture document.
Build routes DARK in production: approve 404, scope 404, tracked 405 (the pre build shape), site 200. Merge
gate PASS. Schema queried PER DATABASE: control plane v80, tenant v80, staging v81. Both production nodes on
the identical binary 8f24414531e80a9a, matching the handoff. Six accounts, one operator, ALL SIX carrying a
real last_login, which is the Track H item 5 fix holding overnight.
THE ONE DIFFERENCE IS EXPECTED AND NAMED: staging is one ahead at v81 because migration 0081 is staging only
pending an approved deploy. The nightly backup timer has not fired yet, first firing 29 July 03:07, and
yesterday's manual runs are on disk with Result=success. Neither is drift. | 2026-07-28

PRODUCT DECISION RECORDED, THE SUPPORTED VIEWPORT FLOOR | Joseph, 28 July 2026. This is a RECORDED PRODUCT
DECISION, not a deferred bug, and the distinction is the point: a deferred bug is debt that accrues silently
and a decision is a boundary that can be checked.
THE DECISION, in three parts:
  1. AUTHENTICATED SURFACES have a supported viewport FLOOR OF 768 for the duration of the design partner
     program. missionMATCH is a desk and capture tool used at a desk. Below 768 is unsupported, not broken.
  2. EVERY PUBLIC SURFACE keeps the FULL MATRIX, 320, 390, 768, 1024, and 1440. Candidates arrive on phones,
     so the public careers pages and any other public surface hold the whole range with no relaxation. The
     floor applies to the authenticated application and to nothing else.
  3. THE PHONE CAPABLE APP SHELL enters docs/IMPROVEMENTS.md as the PRE APPROVED single improvement item for
     PHASE 5, where the desk screens are being rebuilt anyway. The continuation protocol Section 4 item 4
     permits at most one approved improvement per phase; this is Phase 5's, allocated in advance.
WHAT THIS CHANGES ABOUT GATE C: it does not lower a standard, it SPLITS the matrix by surface. The
authenticated sweep asserts 768, 1024, and 1440; the public sweep asserts all five. A single relaxed number
would have quietly excused the public pages too, which is the failure this split prevents.
STANDING GUARD RULE, effective immediately and asserted by the instrument rather than remembered: NO NEW
SCREEN MAY INTRODUCE FIXED WIDTH CONSTRAINTS BEYOND THE SHELL'S EXISTING ONES. The shell's floor is a known,
measured quantity (about 732px of chrome); a new screen that pushes the minimum higher is a regression even
at supported widths, and the visual sweep now measures the minimum content width per route and fails on any
route that exceeds the shell baseline. Without that, "we support 768" would decay into "we support whatever
the widest screen happens to need". | this commit | 2026-07-28

PHASE 2 GATES FILED AS ONE EVIDENCE BUNDLE | docs/evidence/phase2/, README states what it does NOT claim
next to what it does. Every leg re run at one commit so the bundle describes one state of the tree.
  GATE A functional  PASS. 52 packages 0 failing; the boundary suite is 20 tests of which five exist to make
                     the suite honest rather than to test a feature; the promotion race asserts its own
                     overlap (29 ingest rewrites during the race) so it cannot pass by not overlapping.
                     GATE A REMAINS OPEN on exactly ONE blocker, a real solicitation package, which is
                     Joseph's and is not technical.
  GATE B stress      PASS. race elects exactly one winner at 8 AND 32; load and soak p95 10.4ms against a
                     300ms target at ~1020 rps with zero errors; every profile's control failed first.
  GATE C visual      PASS on both surfaces, zero findings, 64 captures, after SIX instrument defects were
                     found and fixed. Finding counts across one day on an UNCHANGED application: 78, 37, 24,
                     3, 0. Nothing about missionMATCH changed between the 37 and the 0.
  GATE D drift       PASS, run at BOTH ends of the session. No drift in anything the phase touched.
  GATE E human       PENDING the real document trial plus Joseph's approval. It is not a file.
NO PIXEL BASELINES EXIST and none is claimed. New or changed screens become baselines only after Joseph
approves the contact sheets; two are filed and neither is approved, so the pixel regression half of Gate C
cannot run yet. | this commit | 2026-07-28

DOCUMENT TRIAL REHEARSED AGAINST A SYNTHETIC PACKAGE, AND IT FAILED IN FOUR PLACES | That is the result and
the reason to rehearse: a checklist nobody has executed is a plan, not a procedure, and breaking it now costs
nothing. Record at docs/evidence/phase2/functional/document-trial-rehearsal.txt, corrections folded into
docs/PHASE2_DOCUMENT_TRIAL.md.
  1. STEPS 1 AND 2 CANNOT RUN AND THE PACKAGE IS NOT WHAT BLOCKS THEM. There is no upload handler and no
     cmd/opportunity-extract. opportunity_documents and opportunity_document_chunks are SCHEMA WITHOUT CODE:
     correct tables, provenance bound at origin, and the only Go file naming either is a test.
     THIS WITHDRAWS A PRIOR LEDGER CLAIM: the two deferred Phase 1 items were recorded as "blocked on real
     documents existing, not on engineering". True of cmd/sam-attachment-sync. FALSE of intake screen 3
     uploads, which has no handler behind it. Withdrawn by name rather than edited.
  2. STEP 3 NORMALIZES NOTICE METADATA, NOT A PWS. The composed payload is nine header fields, about 250
     bytes, and it has never seen a statement of work. The scope items it produces restate the notice header.
     That is the honest ceiling of today's pipeline, written down before the package arrives rather than
     discovered on the day.
  3. STEP 5 NAMES ONE CONSTRAINT WHERE THERE ARE TWO, firing in a fixed order, so an operator asserting "no
     reviewer is refused" would see ck_drafts_approved_has_requirement and never exercise the reviewer rule.
  4. FOUR INSERTS written from the checklist's own vocabulary were rejected by the schema before any
     assertion could run.
WHAT IT PROVED, against real tables rather than fixtures: provenance is BORN not declared; it is IMMUTABLE,
the update is refused by name; and an insert DECLARING public_cache on a tenant document WAS BORN
tenant_upload anyway. That last one is the sharpening recorded 28 July, demonstrated rather than asserted.
Also proven: uncited scope refused, both draft constraints refused separately, a plain draft accepted as the
positive control, and an amendment rewriting the notice underneath a reviewed scope item left it byte for
byte unchanged. Synthetic data only, removed afterwards, removal verified. | this commit | 2026-07-28

THREE PRODUCTION FINDINGS FROM THE PHASE CLOSE DRIFT CHECK, QUEUED NOT FIXED, because the phase lock holds
and all three are production changes.
  D1 THE ADVERSE IMPACT SNAPSHOT HAS NEVER RUN IN PRODUCTION. mm-fairness-snapshot.service fails every daily
     firing with "set MM_COMPLIANCE_DATABASE_URL". The unit reads /etc/missionmatch/api.env and that file
     does not carry the variable; the control plane node's db.env does, and that DSN authenticates, so the
     repair is configuration and not code. This is the AEDT artifact the product exists to provide, the
     selection rates and four fifths ratios for an LL144 or OFCCP audit. The claim that missionMATCH supplies
     it is true of the code and FALSE of the running system.
  D2 THE FAILURE WAS INVISIBLE, WHICH IS WHY D1 SURVIVED. mm-fairness-snapshot has no OnFailure hook.
     Exactly TWO units on Bubbles alert, bubbles-cert-check and mm-db-backup, both wired during Track H item
     3. That work fixed the alerting PATH and proved it by breaking things; it did not sweep every existing
     unit onto that path. Partial coverage is harder to notice than a broken mechanism. One deploy closes D1
     and D2 together.
  D3 THE CONTROL PLANE CANNOT MIGRATE ITSELF WITH ITS OWN RECORDED CREDENTIAL. Of the four DSNs in
     /etc/missionmatch/db.env on the control plane node, three authenticate and the migrator is refused:
     password authentication failed for user missionmatch_migrator. The role exists with rolcanlogin true,
     so the stored password and the role's password disagree. Isolated rather than assumed: same file, same
     parser, same host, three of four work. A migration run from that node fails and the operator has to
     find another path under pressure, which is the exact condition that produced the twelve version
     divergence. | this commit | 2026-07-28

CONFIG ONLY PRODUCTION DEPLOY SHIPPED, D2 AND D3 CLOSED, D1 PARTLY | Joseph approved, 28 July 2026.
Evidence at docs/evidence/phase2/deploys/config-fix-deploy.txt. NO application code deployed; both nodes
still carry 8f24414531e80a9a, verified before and after, production 200, build routes still 404/404/405.
  D2 CLOSED. OnFailure added to EIGHT missionMATCH units. SCOPED BY DESCRIPTION, NOT BY GLOB: the mm- prefix
  on Bubbles is shared with MEGAMIND organs (mm-estate, mm-legacy, mm-live), and a glob would have wired
  another project's failures into this alert path, which is how real alerts get ignored. POSITIVE CONTROL:
  mm-rates-sync ExecStart replaced with /bin/false, unit went exit-code, notifier RAN and succeeded, unit
  restored and the restore verified including that OnFailure survived it.
  D3 CLOSED, AND THE DIAGNOSIS CHANGED THE FIX. The obvious move was to rotate the migrator password.
  Searching first found /etc/missionmatch/backup.dsn and mm-identity-sync.sh already hold a WORKING
  credential for the same database, so the role was never wrong and db.env held a STALE COPY. Rotating would
  have fixed the symptom and BROKEN the control plane backup. Only the password field was replaced; all four
  roles now authenticate and the migrator reads goose_db_version, v80.
  D1 PARTLY CLOSED, AND THE REMAINDER IS FINDING D1b. The env var was added and the unit that had failed
  every daily firing now exits 0. IT STILL PRODUCES NOTHING: "no organizations to snapshot". Had I stopped
  at the green exit code, D1 would have been reported closed while the compliance artifact stayed
  nonexistent, which is the failure mode this build keeps relearning. | this commit | 2026-07-28

FINDING D1b, THE FAIRNESS SNAPSHOT CANNOT ENUMERATE THE ORGS IT EXISTS TO ITERATE | resolveOrgs reads
audit_logs for distinct organization_id while the job deliberately holds the COMPLIANCE role, which is
NOBYPASSRLS, and organizations, audit_logs, candidates, eeo.candidate_demographics and eeo.fairness_snapshots
ALL carry FORCED row level security. With no org GUC the role sees only rows whose organization_id is NULL.
Measured on production: 1058 audit rows visible, 0 with an organization. Measured on staging where 2,783
organizations exist: also 0. The design asks a role that can see nothing without an org context to discover
which contexts exist, so no configuration closes it.
  THE REPAIR: a SECURITY DEFINER function returning ONLY the org ids that carry eeo data, which keeps the
  isolation the job was built for, plus a change to resolveOrgs. Migration plus application code, outside the
  configuration only scope that was approved. Inventing scope inside an approved deploy is how a config
  change becomes an incident, so it is QUEUED. | this commit | 2026-07-28

THE UPTIME PROBE NOW RUNS FROM SOMEWHERE OTHER THAN THE THING IT WATCHES | mm-watch.sh probes 127.0.0.1
FROM Bubbles, and a host cannot report its own death: power loss, nginx death, or an expired certificate
produces SILENCE, which reads identical to health. Added /usr/local/sbin/mm-offsite-watch.sh on
megamind-agi, every five minutes, probing the PUBLIC url plus fg-talent plus certificate expiry, alerting on
a TRANSITION. The Gmail SMTP alert path was ported to that host to carry it. Counted run: app=200 fgt=200
cert_days=66. POSITIVE CONTROL in BOTH directions: pointed at a hostname that cannot serve the app it
alerted and returned rc=1, and the recovery transition alerted too.
  WHAT IT IS NOT, and this must not be rounded up: megamind-agi is on the SAME LAN behind the SAME uplink,
  192.168.1.190 against 192.168.1.132. This is a CROSS NODE vantage, NOT an external one. It catches host,
  service, and certificate failure. It CANNOT catch an ISP outage, a WAN failure, or a DNS failure as the
  internet sees it, because it shares all three with the thing it watches. A genuinely external recurring
  probe needs a third party monitor on Joseph's account, recorded as an open item rather than pretended at.
  ONE TIME EXTERNAL PROOF WAS OBTAINED, from infrastructure off this LAN and not under my control: the
  public app served with its correct title, and fg-talent.com root, team, and contact pages, with the
  content rule holding from outside, Patricia Cox and Brian Atwood only. That fetch CANNOT prove the login
  form renders, because the form is client rendered and an HTML to text fetch sees only the shell; the
  render is proven by the Gate C public sweep, which runs on Bubbles. One vantage proves reachability, the
  other proves the render, and NEITHER PROVES BOTH. | this commit | 2026-07-28

PHASE 2 CLOSE, THE REAL DOCUMENT TRIAL RAN | 29 July 2026. Evidence at docs/evidence/phase2/trial/ and
docs/evidence/phase2/GATE_E.md.
BOTH PACKAGES THROUGH THE GENUINE HTTP INTAKE, not a database insert. 16 of 16 accepted 201, all BORN
tenant_upload with nothing declaring it, duplicates refused 409, 719 chunks across 10 documents.
ACCEPTANCE ITEM 11 HOLDS ON REAL AMENDMENT TEXT: requirement md5 74e08dcc97928dc6b5ab3e7e5a42a3f5 before and
after, one alert raised for a named human, nothing rewritten.
THE LOCKED PWS behaved exactly as the package was designed to test: named failure, batch continued, and the
unlocked variant yielded 33 chunks. The WAGE DETERMINATION measures TABULAR, yields one chunk after the gate
was widened for rate tables, and its grid is recorded as a known limit because table extraction is a
different capability from text extraction.
SIX FINDINGS, ALL RECORDED BEFORE ANY FIX, and F3 alone justifies the whole trial: created_at was scanned as
a timestamptz into a Go string, so THE UPLOAD PATH HAD NEVER WRITTEN A ROW despite being committed,
reviewed, and reported as built. Every one of its tests was pure and never touched a database. The other
five: the store path read only under systemd, then root owned, nginx refusing everything over 1 MB before
the app saw it, encrypted versus permission restricted PDFs conflated, the prose gate refusing an entire
wage determination, and the diff pairing documents by recency rather than type.
GATES: A PASS with findings, B PASS with every control failing first, C PASS both surfaces zero findings,
D PASS. 53 packages, merge gate PASS, secret sweep clean on tree and history.
STAGING NOW RUNS HEAD, e3528c49c8e7fbee, with document intake ENABLED and a storage root. Production is
UNTOUCHED at 8f24414531e80a9a with build routes still dark 404/404/405.
STILL OPEN AS KNOWN LIMITS, none of them correctness defects: no table extraction, no office format reader,
diff pair selection by recency, no approved pixel baselines, and 0081 plus 0082 plus 0083 undeployed to
production. | this commit | 2026-07-29

THE FROZEN ENGINE ANCHOR MOVED, AND THE CHECK FAILED OPEN | 29 July 2026. The combined history purge
rewrote every commit hash, so the baseline the frozen scoring engine is diffed against, 462eb81, CEASED TO
EXIST. The Gate D check then reported "engine diff: 0" while git had actually printed "fatal: bad revision".
A DIFF AGAINST A NONEXISTENT COMMIT PRODUCES NO OUTPUT, AND NO OUTPUT LOOKS EXACTLY LIKE NO DRIFT. The most
load bearing check in the whole protocol failed open, silently, and only because the word fatal appeared
above the result did anyone notice.
  FIXED: the baseline is 9e77f65, the same tree under its rewritten hash. Verified: engine diff 0 against it,
  and the positive control still reports 2 lines for a file that genuinely changed, so the check is running.
  Every LIVE document now names 9e77f65. Evidence files keep 462eb81 deliberately, because they are records
  of what was true when written and rewriting them would be falsifying the record.
  THE LESSON THAT OUTLIVES THIS: a check whose anchor can disappear needs to assert the anchor EXISTS before
  trusting a clean result. Rewriting history invalidates every hash anyone wrote down. | this commit | 2026-07-29

BLOCKED ON A JUDGMENT CALL: THE TOPOLOGY RULE AND THE STAGING API COLLIDE | 29 July 2026. Stopping and
bringing it to Joseph rather than choosing for him, because either answer has real consequences.
THE FACTS. The Package A trial must run through the GENUINE UPLOAD INTAKE. That needs three things:
  the current HEAD binary on staging. Staging currently runs 98edd2b8094721f0, which PREDATES the document
    intake entirely, so POST /api/opportunities/{id}/documents answers 404 there today.
  MM_STORAGE_ROOT set, which is absent from staging.env, so the routes would mount dark even on a new binary.
  a filesystem the staging API can write the document bytes to.
THE COLLISION. mm-api-staging runs ON BUBBLES at /opt/missionmatch-staging, served by the vhost
missionmatch-staging.thatwebhostingguy.com proxying to 127.0.0.1:8097. The topology rule says Bubbles
carries hosted site content and DEPLOYED PRODUCTION ARTIFACTS ONLY, and that document intake, fixtures, and
STAGING ARTIFACTS live on megamind-agi. A staging API is not a production artifact, and a staging document
store on Bubbles is document intake on Bubbles, which the rule forbids by name. The API needs LOCAL disk for
the store, so the store cannot simply be moved without moving the API with it.
THE TWO HONEST OPTIONS, and the choice is his:
  A. MOVE THE STAGING API TO MEGAMIND-AGI. Coherent with the rule as written. Bubbles keeps only the vhost,
     which proxies over the tailnet to megamind-agi instead of to loopback. Consequences: the Gate C sweep
     target changes host, the tailnet becomes a dependency of every staging request, and the vhost gains a
     cross host proxy that did not exist before. Real work, maybe an hour, and it touches an nginx config on
     the revenue host.
  B. READ THE RULE AS PRODUCTION SURFACES ONLY, leaving mm-api-staging where it is and putting
     MM_STORAGE_ROOT under /opt/missionmatch-staging on Bubbles. Consequences: the document corpus grows on
     a disk already at 82 percent that also holds the backups, which is the exact risk the storage proposal
     exists to remove, and it contradicts the rule's plain words.
  MY READING, offered rather than acted on: A is what the rule says, and B is what the rule was written to
  prevent. But A moves a serving surface on the revenue host on the same night I already caused one outage,
  and I am not willing to do that unasked.
UNTIL HE ANSWERS: both packages are verified in the inbox and nothing else in the close is blocked by this
except the parts that must go through the real HTTP intake. | this commit | 2026-07-29

INCIDENT D6, CODIFIED AND CLOSED WITH EVIDENCE | 29 July 2026. The incident is recorded above; this is the
measured impact and the six changes that make it not happen again.

MEASURED PRODUCTION IMPACT, from BOTH nodes' logs rather than from memory:
  Bubbles node        0 auth failures, 0 5xx. Never affected.
  megamind-agi node   22 auth failures. Down 23:33:28 to 23:35:27, ONE MINUTE FIFTY NINE SECONDS.
  nginx               ONE upstream "connection refused" at 23:33:34, failed over.
  CLIENT VISIBLE      ZERO 5xx served. 112 requests in the window, none of them a server error.
  identity sync       4 failed runs, recovered.
  THE HONEST STATEMENT: a two minute outage of ONE OF TWO API nodes, absorbed by nginx failover, with no
  client visible error. The redundancy did its job. That is luck plus design, not an argument that the
  mistake was minor: had it been the Bubbles node, or had both been restarted together, it would have been a
  full outage. D6 CLOSED with this evidence.

ONE, RULE, CLUSTER SCOPED OBJECTS ARE PRODUCTION CHANGES BY DEFINITION. On the shared M4 cluster, ROLES,
ROLE PASSWORDS, EXTENSIONS, TABLESPACES and CLUSTER SETTINGS are production changes REGARDLESS OF WHICH
DATABASE an operation targets, and require the full production process: approval, fresh backup, window.
Databases are scoped; roles are not, and I learned that by breaking production from a staging rehearsal.

TWO, STRUCTURAL FIX, DONE, per environment role names. missionmatch_staging_migrator now exists and staging
uses it exclusively. CONNECT on the production database is REVOKED from it. PROVEN BY REFUSAL, with the
positive control first: the staging role reads 2,784 staging organizations, and the SAME credential against
the production database is refused with "permission denied". mm-api-staging restarted onto it and the
staging vhost answers 200. A staging rehearsal can no longer reach a production role.

THREE, DIAGNOSTICS NEVER PRINT DSNs OR SECRET VALUES. Proof is by ROLE NAME and STATUS CODE. Every
verification in the D5 recovery after the mistake used "select current_user" and an HTTP code, never a
connection string. The secret sweep gains a planted DSN positive control, already implemented and firing.

FOUR, ANY REHEARSAL THAT MUTATES STATE MUST IMPLEMENT AND VERIFY ITS OWN REVERT BEFORE IT COUNTS. The D5
rehearsal script SAID it would change the password back and did not implement it, and I did not check.
AND: rehearsals of cluster scoped mutations DO NOT EXIST. They are production changes under rule one.

FIVE, THE CREDENTIAL INVENTORY EXISTS: docs/CREDENTIAL_CONSUMERS.md, every credential and every consuming
location, references only and never values, including the two that were missing from the list of five, the
second node's own api.env and the two cluster spanning DSNs inside mm-identity-sync.sh. ALL FUTURE ROTATIONS
ENUMERATE FROM IT rather than from memory, and a consumer found outside it is a defect in the file to be
fixed in the same change.

SIX, THE ROTATION PROCEDURE IS WRITTEN DOWN in that file, with the ordering that matters: update every
consumer FIRST while the old credential still works, ALTER ROLE LAST. Doing it the other way leaves a window
where nothing can connect, which is exactly the window this incident opened. | this commit | 2026-07-29

SOLICITATION PACKAGES VERIFIED IN THE INBOX | 29 July 2026. Pulled by me from the public sam.gov file
endpoints straight to /home/user/missionmatch/inbox on MEGAMIND-AGI, roughly one request per second, no API
key spent.
  pkgA_eos_fieldcraft   9 files, 5.2 MB, notice c91da3fd4ff7414ba2bdbcc21a66d1f5
  pkgB_elevator_pm      7 files, 13 MB,  notice 3ebc5efaf311429e92ee2381fad752eb
  ALL SIXTEEN CHECKSUMS MATCH the expected values exactly. Zero re uploads, zero 404s, so neither the keep
  the fresh copy path nor the stop on a missing PWS path was exercised. SHA256SUMS written into each folder
  from what actually landed and verified on the remote side. | this commit | 2026-07-29

D5 MAINTENANCE WINDOW COMPLETE, AND I CAUSED AN INCIDENT INSIDE IT | 29 July 2026, approved by Joseph.
THE INCIDENT FIRST, because it is the part worth reading.
  The rehearsal script said it would change the staging migrator password "and change it BACK". IT DID NOT
  IMPLEMENT THE REVERT. Worse, POSTGRES ROLES ARE CLUSTER WIDE: missionmatch_staging and the production
  tenant missionmatch share one M4 cluster and one missionmatch_migrator role, so a rehearsal I believed was
  contained to staging INVALIDATED THE PRODUCTION TENANT MIGRATOR DSN as well.
  Then, diagnosing it, I printed four live control plane DSNs to the session transcript, burning the app,
  compliance, and aioe credentials that had not been exposed before. That was carelessness of exactly the
  kind D4 exists to prevent, committed while cleaning up D4.
  RECOVERED, and every step verified rather than assumed: the M4 migrator was reset to a known value via the
  superuser and staging.env and api.env updated; all four CONTROL PLANE roles were rotated because I had
  burned three of them; every consumer was updated and proven BY ROLE NAME, never by printing a DSN.
THE ROTATION ITSELF, five consumers as ordered, plus two nobody had listed:
  Bubbles      /etc/missionmatch/api.env       MM_MIGRATOR_DATABASE_URL and MM_DATABASE_URL
  Bubbles      /etc/missionmatch/staging.env   MM_MIGRATOR_DATABASE_URL
  megamind-agi /etc/missionmatch/db.env        all four role DSNs
  megamind-agi /etc/missionmatch/backup.dsn
  megamind-agi /usr/local/sbin/mm-identity-sync.sh
  NOT ON THE LIST AND FOUND ONLY BY FAILURE: megamind-agi /etc/missionmatch/api.env carries its OWN
  MM_DATABASE_URL, so that node's mm-api crashed on restart with a SASL auth failure until it was updated.
  ALSO NOT ON THE LIST: mm-identity-sync.sh hardcodes TWO DSNs, control plane AND tenant, in DIFFERENT
  CLUSTERS. A blanket substitution would have written the control plane password into the tenant line; the
  fix targets only the line whose host is M4.
FRESH CONTROL PLANE BACKUP TAKEN IMMEDIATELY BEFORE the window, and a second one after, both landing on
Bubbles and reporting OK.
PROVEN AFTER: production site 200, api csrf 200, staging vhost 200, fg-talent 200, build routes still
404/404/405, AUTHENTICATED LOGIN 200 which is the only proof that control plane identity resolution works,
both nodes active on 8f24414531e80a9a, identity sync reconciled 6 users control plane and 6 tenant.
ONE COMBINED HISTORY PURGE covering all four secret values across six commits, verified zero occurrences per
value across every ref, 392 commits intact, merge gate PASS, 53 packages passing.
THE PURGE FILTER SILENTLY DID NOTHING ON ITS FIRST RUN. grep -rlZ piped into read -d '' matched nothing on
this platform, so filter-branch rewrote every commit and changed not one byte while reporting success. A
filter that no ops is worse than one that errors. Caught by verifying per value rather than trusting the
exit code, then rewritten and PROVEN on a scratch file before being run for real.
THE SWEEP'S HISTORY SCAN NEVER APPLIED ITS OWN ALLOWLIST, so it reported three findings that were a
documentation example, a test constant, and THE REDACTION TEXT ITSELF, since "[REDACTED, see the secrets
store]" is long enough to match the sshpass pattern. A sweep that flags its own redactions teaches people to
ignore it, which is how the original passwords survived twenty commits. Fixed; tree and history both clean
with the positive control firing. | this commit | 2026-07-29

TOPOLOGY RULE, OWNER DECISION, ENFORCED FROM 29 JULY 2026 | Joseph. BUBBLES CARRIES EXACTLY TWO THINGS:
hosted website content, and deployed production artifacts, meaning its nginx vhosts and its API node binary.
Nothing else. No inboxes, no fixtures, no work directories, no scratch. ALL build workspace, document
intake, fixtures, and staging artifacts live on megamind-agi.
  WHY IT MATTERS BEYOND TIDINESS: Bubbles is the revenue web host. Every megabyte of build residue on it is
  a megabyte competing with 138 customer vhosts on a disk already at 82 percent, and every scratch file is
  something a future session might mistake for deployed state.
  THE DOCUMENT INTAKE PATH IS NOW /home/user/missionmatch/inbox/ ON MEGAMIND-AGI, not on Bubbles. Every
  reference in this ledger, in docs/PHASE2_DOCUMENT_TRIAL.md, and in ARCHITECTURE.txt is updated. | this commit | 2026-07-29

BUBBLES AUDIT AND RELOCATION, DONE 29 JULY 2026 | Audited for anything the build placed beyond deployed
artifacts and site content, then relocated. NOTHING WAS DELETED BEFORE IT LANDED AND VERIFIED elsewhere.
  FOUND AND MOVED, 257 MB compressed:
    23 stale mm-api and sam-sync rollback binaries, 463 MB raw. The two most recent rollback points STAY on
      Bubbles, because a rollback binary is part of being deployed; twenty five of them is hoarding.
    59 MB of Gate C capture directories in /tmp
    12 staged build scripts and the visual sweep runner
    /home/user/missionmatch/inbox, removed from Bubbles entirely
  METHOD: packed on Bubbles, sha256 manifest, relayed through this Mac, VERIFIED BY CHECKSUM on megamind-agi
  at /home/user/missionmatch/archive, and only then removed from Bubbles. All three archives verified OK.
  NOTHING SERVING WAS TOUCHED, proven after the moves: production site 200, api csrf 200, staging vhost 200,
  fg-talent.com 200, build routes still 404 and 405, mm-api and mm-api-staging and nginx all active, serving
  binary still 8f24414531e80a9a, 138 vhosts still enabled.
  WHAT REMAINS on Bubbles is deployed artifacts only: mm-api plus the job binaries systemd actually runs
  (alert-sweep, awards-sync, fairness-snapshot, import-candidates, opp-sync, rates-sync, sam-sync) and two
  rollback points. | this commit | 2026-07-29

CORRECTION, WITHDRAWN BY NAME AS FALSE | The Blocker 1 entry claiming the exposed OpenAI key was REVOKED on
27 July is WITHDRAWN. It was not revoked, and recording it as revoked made the exposure look closed when it
was not. A claim that a secret is dead is exactly the claim that must never be made on assumption.
OWNER DECISION IN ITS PLACE, Joseph, 29 July 2026: the key REMAINS IN SERVICE by his choice. The exposure is
ACCEPTED AND ON RECORD. Revocation is DECLINED. The item is PERMANENTLY CLOSED and is not to be raised
again. The gateway resolves the key from the M4 secrets file ONLY, and the backend stays DISABLED until the
external path is proven end to end. | this commit | 2026-07-29

STANDING RULE, CREDENTIALS NEVER ENTER THIS LEDGER | 28 July 2026, from finding D4. No password, key, token,
or DSN with a secret in it goes in this file, in ARCHITECTURE.txt, or in any repository document, regardless
of anyone's direction including the owner's. A document may name WHERE a credential lives, never what it is:
the secrets store, the env file, the path. Enforced by tools/verify/secret-sweep/sweep.sh, which carries its
own positive control and is to be run before any commit that touches docs.
  WHY THE REDACTION ALONE WOULD HAVE BEEN THEATRE: rotation came FIRST. A value that has been committed and
  pasted into a chat is burned whatever the file says afterwards, and editing the file only hides it from
  the person who would have fixed it. | this commit | 2026-07-28

FINDING D4 CLOSED, AND IT UNCOVERED D5 | 28 July 2026.
  D4 DONE, in the order that makes it real: the two staging account credentials were ROTATED through the
  actual primitives, the versioned pepper and PBKDF2 at 600,000 iterations via auth_set_credential, and the
  rotation was PROVEN over HTTPS (old password 401, new password 200). The megamind-agi host password was
  redacted from the ledger. All three were then purged from git history with filter-branch across 28
  commits, the filter-branch backup refs deleted, the reflog expired, and the repository garbage collected.
  VERIFIED: zero commits across all refs contain any of the three, and a direct scan of every blob in the
  object database found nothing. 388 commits intact, no remote, so the purge was contained.
  THE SWEEP THAT FOUND D5. The old check looked only for API KEY SHAPES, which is why three plaintext
  passwords sat in this file for more than twenty commits while it reported clean. The new sweep adds
  password assignments, inline sshpass, and DSNs carrying a secret, and on its first counted run it found a
  FOURTH burned credential nobody had recorded: the missionmatch_migrator password in plaintext, twice, in
  docs/superpowers/plans/2026-07-20-recruitmatch.md. It has been redacted in the working tree.
  THE SWEEP'S OWN CONTROL WAS BROKEN FIRST, and this is worth more than the finding. git grep searches
  TRACKED files only, so the planted control file was never scanned and the control passed on unrelated real
  findings elsewhere in the tree. It reported success while testing nothing. It was only caught because a
  later fix removed those unrelated findings and the control went red. It now passes --untracked, which is
  also what you want before a commit: a secret in a new unstaged file is the likeliest way one arrives. | this commit | 2026-07-28

FINDING D5, OPEN AND NEEDING APPROVAL, THE HISTORY CARRIES MORE THAN D4 NAMED | The migrator password
[REDACTED, rotated 29 Jul 2026] is burned: it is in the working tree history and it is the credential several ops scripts and
env files use. A history scan also reports credential shaped content in at least five further commits
(0db7f20, 553e787, 5fe5879, 00f8373, a656ca2 among them), which is a wider exposure than D4 described.
  WHY IT IS NOT FIXED TONIGHT. Rotating missionmatch_migrator means changing the role password and then
  updating every consumer in step: staging.env, api.env on Bubbles, db.env on megamind-agi, backup.dsn, and
  mm-identity-sync.sh. Getting that half done breaks the control plane backup and the identity sync, which
  is exactly the kind of change that wants a deliberate window rather than the end of a long session. The
  wider history purge is a second filter-branch pass over more commits and should be one operation, not two.
  RECOMMENDED ORDER when approved: rotate the role, update all five consumers, verify each authenticates,
  verify the backup and identity sync still run, then purge history once for everything at the same time.
  QUEUED as an approval item. | this commit | 2026-07-28

PHASE 2 DOCUMENT PIPELINE BUILT AND PROVEN, WITH ONE RED FINDING | 28 July 2026. Evidence at
docs/evidence/phase2/functional/document-pipeline-proof.txt. Staging is v82.
BUILT, closing the gap the trial rehearsal found: document intake service and handler, cmd/opportunity-extract,
cmd/opportunity-amendment-diff, cmd/sam-attachment-sync (the deferred Phase 1 item), migration 0082.
GREEN AND PROVEN:
  PROVENANCE BORN FROM THE SOURCE. 0082 replaces the per table binding for opportunity_documents, because
  that one table holds BOTH a customer's private package AND published federal attachments, and binding all
  of it tenant_upload made public federal text unusable by the lane built for it. A caller still CANNOT
  DECLARE provenance: declaring tenant_upload on an attachment yielded public_cache, declaring public_cache
  on an upload yielded tenant_upload, and relabelling source_type afterwards is REFUSED, which closes the
  laundering path. Mapping defaults to the restrictive value.
  EXTRACTION SURVIVES BAD INPUT with a named reason each: malformed, locked, empty, scanned, bytes_missing.
  The bytes_missing case was a planted positive control and it failed as required.
  CITATION PER CLAUSE, six chunks per PWS labelled C.3.1 through C.5. The first version produced ONE chunk
  per document because the PDF reader flattened line structure, which lost the entire point of chunking.
  AMENDMENT DIFF detects all five material changes including QUANTITY four to six and TRAVEL 15 to 40, both
  of which it missed at first because the patterns wanted symbols and the document writes prose. For a
  cleared staffing product the headcount is the most important number on the page.
  ACCEPTANCE ITEM 11 PROVEN: requirement md5 IDENTICAL before and after an amendment, one alert raised for a
  named human, nothing rewritten.
  ATTACHMENT SYNC pulled 4 real federal attachments from the PUBLIC endpoint, no API key spent, dedupe
  positive control clean on the second run, ingest_manifest written. The live call found three defects no
  fixture would have: the response is nested, mimeType carries an EXTENSION so every real attachment was
  being refused, and the payload carries exportControlled and accessLevel flags that were being ignored
  entirely, which for a cleared workforce product is not a bug to fix later. mayPull now fails closed.
RED, AND IT BLOCKS THE REAL DOCUMENT HALF OF GATE A: THE PIPELINE CANNOT READ A PRODUCTION GRADE PDF. Zero
of four genuine federal attachments extract. The reader was fixed to inflate FlateDecode, then produced 16
chunks of BINARY NOISE that stored cleanly with correct provenance and were garbage, because inflating every
stream picks up font programs. A prose quality gate now refuses them and is CORRECT, and its consequence is
that real PDFs yield nothing. THE GATE WAS NOT WEAKENED TO PRODUCE A GREEN RESULT: garbage chunks are worse
than none because a reviewer cites them. Measured, not asserted: one real solicitation carries 149
FlateDecode streams and 20 embedded font programs, so telling content from fonts needs real PDF object
parsing. Three options, all Joseph's: add a Go PDF dependency (cheapest, a stack decision under the do not
blindly build rule), build the parser in house (its own phase item), or shell out to pdftotext (breaks the
cloud portability mandate, listed only for completeness). | this commit | 2026-07-28

THE LEARNING BOUNDARY, THREE DOORS AND NO FOURTH | Recorded 28 July 2026 as ingestion begins to grow the
corpus at scale. This is a standing rule about what ingestion is ALLOWED TO CHANGE, and it exists because a
system that ingests federal documents daily and also scores humans has an obvious and dangerous shortcut
available to it.

INGESTION MAY OPEN EXACTLY THREE DOORS:
  1. THE CORPUS. New documents, new chunks, new notices, new attachments. More evidence to cite.
  2. THE EMBEDDINGS. New vectors over that corpus, so retrieval finds things it could not find before.
  3. THE ONTOLOGY SUGGESTIONS. Candidate skills, synonyms, and adjacencies PROPOSED for operator curation.

THERE IS NO FOURTH DOOR. Ingestion NEVER alters scoring weights, never alters the band thresholds, never
alters the clearance hierarchy, and never promotes an ontology suggestion into the live ontology on its own.

WHY THIS IS WRITTEN DOWN RATHER THAN ASSUMED. The scoring engine is an AEDT under NYC LL144 and OFCCP. Its
weights are a frozen, diffed, exhaustively tested artifact precisely so a customer can point at one number
and say what produced it. A pipeline that learned from the market and adjusted those weights would produce a
scoring function nobody could reproduce, explain, or audit, and it would do it silently, one federal
document at a time. The failure would not look like a bug. It would look like the numbers slowly changing.

  Door 3 is the one that looks safest and is not. An ontology that grows itself changes which candidate
  skills match which requirement skills, which changes the Skills component, which changes the score. So an
  ontology SUGGESTION is data, and its PROMOTION is an operator action by a named human, and the gap between
  those two is load bearing. cmd/promote-ontology exists for exactly that gap.

HOW IT IS ENFORCED TODAY, honestly: by the frozen engine diff against 9e77f65 asserted EMPTY at every drift
check, by the ontology promotion being a separate operator binary, and by nothing else. It is a rule with a
detector, not a rule with a lock. Named that way so nobody mistakes the detector for a guarantee. | this commit | 2026-07-28

OWNER DECISION, OPERATOR MFA IS DEFERRED | Joseph, 28 July 2026. Recorded as a DECISION, which is a
different thing from an open item, and it closes what was item 3 on his list.
  THE DECISION: the production stand down of operator MFA STAYS. MM_OPERATOR_MFA_REQUIRED remains false in
  production only; the default is true, staging proves the rule, and config validation still refuses the
  false value under a production MM_ENV, so the stand down is deliberate and announced at every boot rather
  than accidental.
  ACCEPTANCE ITEM 39 CARRIES A DEVIATION ON RECORD. It is not satisfied, it is not quietly reinterpreted as
  satisfied, and it is not going to be reported as passing. A deviation on record is the honest shape for a
  requirement the owner has consciously chosen not to meet yet.
  REVISIT IS A NAMED GATE 6 CHECKLIST ITEM. It is not to be raised again before Gate 6. Anyone reading this
  ledger between now and then should treat operator MFA as settled and stop relitigating it; that is the
  point of recording a decision rather than leaving a question open.
  WHY IT MATTERS ANYWAY, stated once and then left alone: for an AEDT handling CUI adjacent data with a
  federal buyer in view, this is the gap a first assessor finds. The owner holds that. | this commit |
  2026-07-28

PATRICIA HAS BEEN EMAILED, ITEM CLOSED | Joseph, 28 July 2026. Reported by the owner and recorded on his
word, which is the correct basis for a fact only he can observe. No independent verification is claimed and
none is implied. The item is closed. | this commit | 2026-07-28

FINDING D4, THIS LEDGER CARRIES LIVE PASSWORDS IN PLAINTEXT, AND I PUT THEM THERE | Found while checking
this file for secrets before committing the phase close entries. Three lines carry credentials: the
megamind-agi host password in the environment block, and the two staging test account passwords. They landed
in b8c7b07 and 58a94a1, both mine, both earlier in this build.
  WHY THIS IS NOT SIMPLY FIXED HERE. Redacting the tip of the file would leave every one of them in git
  history and would LOOK like a remediation while changing nothing an attacker could not still read. That is
  worse than the current state, because it converts a visible problem into an invisible one.
  THE HONEST OPTIONS, and both are Joseph's:
    ROTATE. Change the megamind-agi password and both staging account passwords, then redact the file. This
    makes the history harmless without rewriting it, and is the option that does not touch git.
    PURGE. Rewrite history to remove the lines. Destructive, and the repository has NO REMOTE today, so a
    purge is contained; it is still a rewrite of 372 commits and not something to do unasked.
  MITIGATING, and stated as mitigation rather than as an excuse: the repository has no remote and lives on
  one laptop. The exposure is local. It is still a rule this build set for itself and then broke.
  NOT DONE UNDER THE PHASE LOCK. Queued as Joseph's item 8. | this commit | 2026-07-28

ENVIRONMENT CORRECTION, megamind-agi HAS TWO TAILNET IDENTITIES | The Windows host is 100.69.120.61 and the
WSL2 instance is 100.77.114.40 running its own tailscaled. POSTGRES 5433 BINDS INSIDE WSL2, so it answers on
.40 and a connection to .61:5433 TIMES OUT WITH NO USEFUL ERROR. There is no sshd inside WSL2 either, so the
only route in is ssh to the Windows host then wsl with a STAGED script; scp to the Windows path needs -O and
the default home, and inline nested quoting through wsl silently produces nothing. The control plane's own
postgres superuser is reachable as: wsl -- bash <staged script> running sudo -n -u postgres psql -p 5433.
Recorded because rediscovering it cost real time this session. | this commit | 2026-07-28

## CURRENT PHASE: PHASE 2, scope and requirements, with TRACK U and TRACK H running in parallel

Exactly one phase is current. Phase 0 complete with Gate 0 passed. Phase 1 complete except the two items
Joseph deferred until client go live (intake screen 3 uploads and cmd/sam-attachment-sync, both blocked on
real documents existing, not on engineering), with Gate 1 criteria passed and recorded. Phase 2 is IN
PROGRESS. Phases 3 through 6 are not started. Task T1 is standalone, complete, and outside the phase gates.

## Corrections ratified by Joseph, 28 July 2026

CORRECTION 1, documents now match reality | The environment rule text in BOTH docs/CLAUDE_CODE_BUILD_DIRECTIVE.md
Section 0 item 9 and docs/DIRECTIVE_AMENDMENTS_CONSOLIDATED.md Amendment 1 now names the functioning staging,
missionmatch_staging on M4 100.94.8.94 port 5432, and states that megamind-agi port 5433 is an empty shell
that MUST NOT be used. Section 0 item 7 of the amendments file is corrected to match. | 472a2bd | 2026-07-28

CORRECTION 2, STAGING ROLE ISOLATION PROVEN, and it FAILED before it passed | Attempted access exactly as
asked. BEFORE: staging and production ran as the SAME role, missionmatch_app, on the SAME cluster. The staging
credentials CONNECTED to production missionmatch and successfully wrote a row (INSERT 0 1). The zero row reads
were row level security with no org GUC set, NOT a privilege denial, so there was no isolation at all. Test row
deleted immediately, verified 0 remaining. ROOT CAUSE: PostgreSQL grants CONNECT to PUBLIC by default, so every
role in the cluster could reach production. FIX: created missionmatch_staging_app (LOGIN, NOBYPASSRLS) with
grants mirrored exactly from the app role inside missionmatch_staging only, 79 tables to 79 tables; granted
CONNECT on production explicitly to the four legitimate roles (app, migrator, compliance, aioe); revoked the
PUBLIC blanket. The boot role assertion hardcoded missionmatch_app and failed the boot closed, which is what
blocked a differently named role, so MM_APP_DB_ROLE now names the expected role per environment, defaulting to
missionmatch_app so production is byte for byte unchanged and the assertion stays exactly as strict.
AFTER, ledger evidence: staging role refused on missionmatch, tenant_alpha, and tenant_beta with "permission
denied for database"; the identical write that previously succeeded now fails at connection with FATAL:
permission denied for database "missionmatch"; the staging role still reads its own database; production
migrator, production app role, and the production API (active, healthz 200) are unaffected; zero stray test
rows. | 472a2bd | 2026-07-28

CORRECTION 3, the eighteen parity migrations classified, and a VIOLATION found and fixed | Nine were BUILD
migrations authored by this build: 0069 ingest_manifest, 0070 tracked_opportunities, 0071 opportunity_versions,
0072 opportunity_documents, 0073 opportunity_document_chunks, 0074 opportunity_records_embedding, 0075
opportunity_amendment_alerts, 0076 opportunity_scope_items, 0077 requirement_drafts. Nine were PREEXISTING
migrations staging was simply behind on: 0060 solicitation_extractions, 0061 tenant_directory, 0062
superuser_and_tool_access, 0063 provision_org_grants_tools, 0064 bootstrap_role_and_scoped_touch, 0065
revert_audit_logs_rls, 0066 recompute_furthest_stage, 0067 duplicate_indexes_and_expansion_author, 0068
audit_logs_tenant_read. Nine plus nine is eighteen.
COULD NOT CONFIRM the no build feature in production rule, because it was FALSE: the capture routes answered
403 (mounted) and /slate/capture served the Capture screen, both deployed on 27 July under the then current
instruction to build directly against production. Made it true rather than reporting it as acceptable.
Rebuilt the API binary and the frontend bundle from the starting commit 9e77f65 in a clean git worktree and
deployed both to BOTH nodes. The restored bundle hash index-DEG0K1sr.js is byte identical to what production
served at session start, which is independent proof the restoration is faithful.
EVIDENCE: POST /api/requirement-drafts/{id}/approve, /reject, and /opportunities/tracked/{id}/scope all return
404; POST /api/opportunities/tracked returns 405, because the pre build binary registers only GET
/opportunities/{noticeID} so the path matches that GET route while the capture POST handler does not exist;
both nodes agree and 8 of 8 requests through the public pool return 405; the string "Opportunity capture"
appears 0 times in the shipped bundle. Production remains fully working: site 200, healthz ok, the preexisting
authenticated API still 403. The schema stays at v77 because the build migrations are additive, carry no data,
and are needed at Gate 6; only the reachable surface was removed. | 2026-07-28

CORRECTION 4, ledger and task list reconciled, knowledge feeding CLOSED | The task list named Phase 1 as
current while the ledger showed Phase 2 work underway. Reconciled: exactly ONE phase is now named current,
Phase 2, in the heading at the top of this file and in the task list, with Phase 1 closed and its two
deferred items recorded as blocked on documents rather than on engineering.
KNOWLEDGE FEEDING RECONCILIATION, OUTCOME RECORDED, task closed. The question was how Joseph's intent to
feed the system knowledge squares with the directive's cited provenance model. It is resolved in design and
the design is already partly built. There are THREE sanctioned doors and no fourth: (1) curated knowledge
cards through curation.curate, superuser only, each cited to a primary source and traced to an
ingest_manifest row, which is Phase 4 item 4, the eleven compliance cards; (2) public external sources
through the sync binaries, each writing an ingest_manifest row, which is BUILT and proven, sam-sync wrote
its first provenance row on 27 July; (3) tenant documents through opportunity_documents and
opportunity_document_chunks with the citation CHECK enforcing provenance in the schema, plus the Import
Center staged batch path added by consolidated amendment 4, where nothing becomes a live record until a
human commits with a first party attestation. Arbitrary document dumping into a model is not a door and
never becomes one. The embedding layer added on 27 July gives the AI semantic recall over the public
opportunity catalog, 6535 of 6535 records, through the SAME provenance backed corpus.
BLOCKER, now clearing: the only thing outstanding was real documents. Joseph is uploading a solicitation
package, an RFP or combined synopsis with a PWS and at least one amendment, for Phase 2 extraction
verification. On arrival the deterministic pass runs first per Section 5.1, then model normalization, then
the scope review queue. | 2026-07-28

## Consolidated amendments 1 through 5, applied 28 July 2026

AMENDMENTS 1 THROUGH 5 ACCEPTED, CONSOLIDATED | source docs/DIRECTIVE_AMENDMENTS_CONSOLIDATED.md
(708 lines, copied into the repo 28 July 2026). docs/archive/DIRECTIVE_AMENDMENT_5.md archived per
Section 0 item 3; exactly one amendment source now exists under docs. | 2026-07-28

CONSOLIDATION MERGED AND VERIFIED | all seven Final Merge Index lines verified by grep against the
merged directive, not by assertion: (1) Section 0 gained the Amendment 1 environment rule; (2) Phase 3
gained the slate approval lifecycle and Gate 3 gained its additions; (3) Phase 5 gained desk integration
A through C, publishing to the tenant website, desk workflow additions 1 through 11, the Import Center
and uploads, and the candidate spine and Candidates page, and Gate 5 gained sections 2.8, 4.6, and 5.7;
(4) the directive gained the canonical dataflow as Appendix A; (5) Section 11 gained acceptance items 25
through 35, all eleven present; (6) Task T1 is registered as standalone work outside the phase gates;
(7) the fast follow list gained the 2.7 items. Directive grew to 938 lines. | 2026-07-28

CONFLICT A, staging location, RESOLVED without stopping | The amendment Section 0 item 7 names staging as
missionmatch_staging on megamind-agi port 5433. Verified 28 July: that database exists but is an EMPTY
SHELL, 0 organizations, 0 candidates, goose_db_version not readable by the app role. The WORKING staging is
missionmatch_staging on M4 100.94.8.94 port 5432: 76 tables, 2766 organizations, 8872 candidates, and it is
the database the live mm-api-staging service on 127.0.0.1:8097 serves (healthz 200). Gate verification
requires an end to end check through a live authenticated API and a rendered screen, which only the M4
database supports. Per amendment Section 0 item 5, the smallest change satisfying both is to honor the
amendment's database NAME and its staging only rule while using the host where that database actually
functions. STAGING MEANS missionmatch_staging ON 100.94.8.94 PORT 5432. | 2026-07-28

CONFLICT B, work already verified against production, RESOLVED without reopening | Amendment 1 reinstates
staging only until Gate 6, superseding Joseph's 27 July instruction to build directly into the existing
application. Migrations 0069 through 0077 and the Gate 0, Gate 1, and partial Gate 2 evidence were verified
against PRODUCTION missionmatch under that now void instruction. Per amendment Section 0 item 5, PASSED
GATES ARE NEVER REOPENED, so that evidence stands as recorded. The smallest change satisfying both is
forward looking: from 28 July every migration and every gate verification runs against staging, and staging
is brought to schema parity with production first so the two do not diverge. Production is not touched again
until Gate 6. | 2026-07-28

PHASE 0 HUMAN BLOCKERS, all three recorded, no stop point | Amendment 1 requires surfacing if any of the
three is absent from the ledger. All three are present above and dated 2026-07-27: the exposed OpenAI key
revoked, the fresh project scoped key placed on M4 as openai_api_key root owned 0600, and the SAM.gov system
account application submitted. Nothing external is blocked. | 2026-07-28

STAGING BROUGHT TO PARITY, the environment rule is now live | snapshot taken first
(/home/user/mm-snapshots/staging-schema-*.sql), target asserted as missionmatch_staging before any write,
then migrated v59 to v77 (+18) with eeo unchanged at v2. Verified on staging: all seven new tables present
(ingest_manifest without RLS as shared reference data, tracked_opportunities, opportunity_versions,
opportunity_documents, opportunity_document_chunks, opportunity_scope_items, requirement_drafts all with
rls_forced true), opportunity_records carries both the embedding and search_tsv columns, and the existing
data is intact at 2766 organizations and 8872 candidates. mm-api-staging on 127.0.0.1:8097 still active with
healthz 200. Production remains at v77 and was not touched by this run. Every gate from here verifies on
staging. | ee67c3a | 2026-07-28

BLOCKER FOUND AND FIXED during parity | migrate-all-tenants read the tenant directory before migrating and
died on a database that did not have tenant_directory yet, which is a deadlock: the table is created BY a
migration, so the command that would create it could never run. A missing relation is now treated as no
tenants yet while every other error still fails hard. | ee67c3a | 2026-07-28

TASK T1 COMPLETE, verified rendered over HTTPS | Joseph picked fg-talent.com, missionMATCH's first
client. Located it: fg-talent.com resolves to 169.155.162.118, the same host as Bubbles, served from
/var/www/sites/fgtp with the vhost in /etc/nginx/sites-available/fg-talent.com (a sites-enabled grep missed
it, nginx -T found it). Backed up the live client docroot to /home/user/fgtp-backup-20260728-121556.tgz
before any edit. Added a brand native Recruiter Login link, hand written markup reusing the site's own
btn btn-ghost btn-sm class, to the desktop header CTA row and the mobile drawer on ALL 34 pages, idempotent
so a rerun is a no op. VERIFIED LIVE: five representative pages return 200 with the link present, the
rendered markup is exactly the intended anchor, the target missionmatch.thatwebhostingguy.com returns 200,
and FG Talent's own Submit background and Hire talent CTAs are untouched. | 2026-07-28

TASK T2 REGISTERED, standalone work outside the phase gates, like T1 | Joseph, 28 July 2026. Make
https://fg-talent.com fit every screen, desktop, tablet, and phone. Executed on the Bubbles vhost at
/var/www/sites/fgtp, outside the missionMATCH repo, and it does NOT block phase progress.
SCOPE, exactly: correct viewport meta on every page; fluid layouts with no horizontal scroll at 320, 375,
390, 414, 768, and 1024 pixel widths; a readable type scale on phones; tap targets of at least 44 pixels;
the existing mobile drawer and the Recruiter Login link from T1 both working; images and grids scaling
instead of overflowing; tables wrapping or scrolling inside their container; desktop visually unchanged.
CONSTRAINTS: back up the live docroot first, as T1 did. CSS and layout only. No copy changes and no new
content. The FG Talent content rule stands unchanged, Patricia Cox and Brian Atwood only, Tom and Glennette
nowhere. No Python.
WHY IT MATTERS BEYOND ITSELF: the Phase 5 careers brand template (amendment 2.5 item 4, the careers section
must read as native to the site) inherits whatever is fixed here, so this is also the mobile foundation for
the future job pages that candidates will land on from a phone. | 2026-07-28

TASK T2 COMPLETE, verified live over HTTPS at every required width across all 34 pages | Backed up first to
/home/user/fgtp-backup-t2-20260728-133551.tgz, as T1 did, plus the stylesheet alone to
/home/user/brand.css.pre-t2-20260728.
ONE FILE CHANGED, proven not asserted: every file in the docroot was compared byte for byte against the
backup afterwards. 0 of 35 HTML files changed. assets/css/brand.css is the only modified file, 646 lines
plus one appended block. No copy touched, no content added, no markup edited.
WHAT WAS ACTUALLY BROKEN, measured before it was fixed by loading all 34 live pages at 10 widths and
comparing document scrollWidth to clientWidth, naming the outermost overflowing element:
  THE HEADER, all 34 pages. The desktop header needs 1365px, brand 328 plus navigation 643 plus calls to
  action 322 with padding and gaps, and the drawer did not take over until 980px. Every viewport from 981
  to 1365 pushed the document 65 to 364 pixels wide. This is far larger than the brief assumed: it is not
  a tablet problem, it is every 1280 laptop, and 1366 was the narrowest width that rendered clean.
  /services/ AT 320, over by 18. Seven hard coded two column inline grids, grid-template-columns 1fr 1fr,
  with no narrow fallback across four pages. Two columns cannot fit a 280 pixel content box, so the card
  grew to 318 and took the page with it.
  TAP TARGETS. The menu button was 35 tall on all 34 pages, accordion headers 37 on 53 measurements, and
  the single checkbox on the site 13 by 13.
  VIEWPORT META was already correct on all 34 pages; only the Google verification stub lacks it, which is
  right because it is not a page. TABLES were already wrapped in scrolling containers on all three pages
  that have one, so they were left alone rather than given a rule that would strip their semantics.
THE FIX, CSS only, every rule bounded to 1439.98px and narrower so the desktop cannot move: a 1200 to 1439
band keeps the real navigation and drops the brand wordmark, which is the design's own move already used
below 720px and frees 232px; below 1200 the existing drawer takes over; phones collapse the inline two
column grids; touch widths get 44 pixel targets.
RESULT, 340 measurements, 34 pages by 10 widths: ZERO horizontal overflow at 320, 375, 390, 414, 768, 1024,
1200, 1280, 1366, and 1440. All 34 pages answer 200. The drawer opens at 320, 390, 768, 1024, and 1199 with
all 18 links at least 44 tall, the T1 Recruiter Login link present at 49 to 75 tall pointing at
missionmatch.thatwebhostingguy.com, and no overflow with the drawer open; at 1200 the desktop navigation
takes over exactly as designed. The menu button is 44 by 44 and the checkbox row is 56 tall with a bound
label, so its effective target exceeds 44.
DESKTOP UNCHANGED, PROVEN BY PIXEL DIFF, not by assertion: 10 pages rendered twice, once against the
pre T2 stylesheet served by request interception and once against the live one, are byte identical at 1440
and at 1600, 10 of 10 each, and at 1920 after re running two pages whose first comparison was invalidated
by a non deterministic render and a failed interception.
TWO ERRORS IN MY OWN WORK, caught by verification and recorded rather than hidden. First, the initial diff
used a route pattern that missed the ?v=3 cache buster, so BOTH arms loaded the new stylesheet and the
identical result proved nothing; it was caught by a control that rendered the old sheet and still measured
no overflow, which was impossible. Second, once the interception worked it showed every desktop page had in
fact changed: an unbounded img[width] selector outranked .brand-lockup__img, forced height auto, and grew
the logo from 144x96 to 200x133, shifting the whole header. That rule was redundant with the base reset and
was deleted, the block was rebuilt from the pristine backup so nothing was applied twice, and every
remaining rule was bounded to non desktop widths.
CONTENT RULE HOLDS, checked against the live rendered HTML of all 34 pages: 0 pages contain Tom or
Glennette, Patricia Cox appears on 3, Brian Atwood on 3.
PHASE 5 NOTE: the careers brand template of amendment 2.5 item 4 must read as native to this site, so it
inherits this stylesheet. This is the mobile foundation for the future job pages candidates open on a
phone, which is why the header fix matters beyond today. | 2026-07-28

NOTED DEVIATION on T1 placement, per Section 0 item 5 | Amendment 2.2 item 3 says header AND hero. The
amendment assumed a missionMATCH MARKETING surface; Joseph's pick is the CLIENT's candidate facing site,
which in Phase 5 will also host the public /careers/ pages candidates land on. A hero Log in CTA there
would compete with FG Talent's own conversion path and would push the missionMATCH domain at candidates,
against decision 2.1.3 that candidates never see the missionMATCH domain for a mapped tenant. The smallest
change satisfying both is a site wide header link on every page, which is the prominence the amendment
wants, labeled Recruiter Login so a candidate is not misdirected, and no hero CTA. | 2026-07-28

SUPERSEDED, the original T1 ambiguity record | Enumerated the Bubbles vhosts per amendment
2.2 item 1. Finding: NO Mission Workforce Technologies marketing vhost exists. The only server_name matching
missionmatch is missionmatch.thatwebhostingguy.com, which is the APPLICATION itself, and amendment 2.2 item 1
explicitly excludes putting the button inside the app. The real marketing surfaces both live on thataiguy.org,
a live production website: /work/missionmatch/ is an 18110 byte case study titled "missionMATCH: A Cleared
Workforce Platform, Multi Tenant and Isolated" with an h1 of missionMATCH and NO existing login link, serving
200 over HTTPS; and the thataiguy.org homepage features missionMATCH as a Flagship card linking to that page.
Amendment 2.2 item 2 forbids guessing on a production website, so the pick is Joseph's. Task T1 is standalone
work outside the phase gates, so it does NOT block phase progress. | pending Joseph | 2026-07-28

## Drift audit, 28 July 2026

Audited this build against the directive at Joseph's request. Recorded here because Section 0 item 6
requires a deviation to be written down rather than carried silently.

CLEAN, verified by command, not by memory: the candidate scoring engine diff against the starting commit
9e77f65 is EMPTY (acceptance 23); db/migrations_eeo untouched; zero existing migrations 0001 to 0068
modified; zero Python files added (acceptance 20); no dashes in authored prose (acceptance 21, the single
grep hit is a pre existing llama.cpp CLI flag, which the rule permits). Nothing on the FORBIDDEN list was
done: no new repository, no new API binary, no second scoring engine, no fifth entitlement, no renamed or
restructured tables, no schema outside numbered migrations, no NL to SQL or model authored SQL, no secrets
outside the store, no scraping of candidate data.

DEVIATION 1, phase lock (Section 0 item 2). Phase 2 was started while Phase 1 still had open items: intake
screen 3 uploads, cmd/sam-attachment-sync, and Section 4 steps 4, 5, and 8 (full description retrieval,
attachment metadata, attachment queuing). Joseph deferred documents until client go live and directed the
move to Phase 2, so the deviation is authorized, but it was not recorded when it happened. It is recorded
now. The deferred items are blocked on real documents existing, not on engineering.

DEVIATION 2, Section 5.1 ordering, CORRECTED. Model normalization shipped before deterministic extraction,
inverting the directive's explicit "deterministic extraction first, before any model call". Corrected in
0da4c7c: ExtractDeterministic and ExtractSignals are pure, tested, and run with no model.

DEVIATION 3, Section 9 promotion routes unreachable, CORRECTED. ApproveDraft and RejectDraft were built and
race tested but never mounted, so the one path by which a named human turns a draft into a live requirement
could not be called. Corrected in 0da4c7c with the directive's own paths and the new requirement.approve
capability; the route contract test now guards them.

DEVIATION 4, route paths, ACCEPTED AND UNCHANGED. The tenant capture surface lives at /opportunities/tracked
rather than Section 9's /opportunities, because the public cache read already owns /opportunities/{noticeID}
and chi cannot host two wildcard names at one path position. Recorded with rationale.

CLARIFICATION, the external OpenAI lane. The backend, boot guard, egress gate, and audit are built and
proven, but the gateway's generation backend is config selected and currently points at the LOCAL model, so
REQUIREMENT_NORMALIZE has not executed against OpenAI end to end. Enabling it is a gateway config change
protected by the boot guard, not new code.

phase2 | drift corrections | requirement.approve at manager and above and scope.review at recruiter and
above added to the exhaustively tested matrix; promotion and scope review routes mounted and guarded by the
route contract test; deterministic extraction added ahead of the model per Section 5.1 with 11 module tests
green and ci-gates passing | 0da4c7c | 2026-07-28

## Phase 2, scope and requirements

phase2 | item5 the safety boundary tables | migrations 0076 opportunity_scope_items and 0077 requirement_drafts applied to production (goose 75 to 77), rls_forced both, 19 and 31 columns, 3 and 9 CHECK constraints. The Gate 2 rules are enforced in the SCHEMA: ck_scope_items_cited refuses uncited machine produced scope, ck_drafts_approved_has_requirement makes approved carry its result, ck_drafts_decided_has_reviewer refuses a decision with no named human so no automated path can approve, ck_drafts_skill_flags_align refuses a misaligned mandatory flag that would mis set a band cap | df6d7bf | 2026-07-27
phase2 | schema constraints PROVEN against production | six live tests, each refused correctly: uncited extracted item refused by ck_scope_items_cited, the same item WITH a citation accepted, a manual item accepted uncited, an approved draft with no requirement refused, an approved draft with no named human refused, mismatched mandatory flags refused | df6d7bf | 2026-07-27
phase2 | GATE 2 CONCURRENCY PASSED, eight racing promotions elect one winner | ApproveDraft takes FOR UPDATE on the draft row, records the named approver, writes the requirement and flips the draft in ONE transaction, and links only skills the existing ontology knows (never writes the global ontology). Raced against production: 8 concurrent promotions of one draft produced requirements_created=1 and draft_status=approved with the requirement recorded. Proven by racing it, not by reasoning about it | df6d7bf | 2026-07-27

phase2 | item3 model normalization into cited scope drafts | ValidateScopeCandidates is pure and exhaustively tested (6 tests green): rejects uncited items, out of vocabulary scope_type, oversized fields, out of range confidence, and fails closed on an unparseable payload. Its load bearing rule REJECTS A FABRICATED CITATION, a quote not found in the source text, which is stronger than the Gate 2 ask. cmd/opportunity-scope-normalize composes ONLY public SAM notice metadata, redacts contact shapes, and the scrub gate under REQUIREMENT_NORMALIZE has the final say. VERIFIED LIVE: gate allowed a 201 byte payload and logged audit metadata (backend, payload_class, byte_count, content_sha256, never content), the model returned one grounded item, it wrote with its citation, and the SAME item inserted uncited was refused by ck_scope_items_cited | 984a0ee | 2026-07-27
phase2 | GATE 2 status | PASSED so far: every extracted scope item carries a source citation (schema enforced); uncited model output is rejected, proven by test AND by a live insert refusal; eight racing promotions elect exactly one approved requirement (raced against production). REMAINING for the full gate: the scrub suite fixtures for a candidate row and tenant uploaded document text in an external bound payload, an ingest run during promotion, and the approved requirements are never rewritten by an ingest path test | 984a0ee | 2026-07-27

phase1 | amendment detection, versioning, and alerts | migration 0075 widens the alerts vocabulary with opportunity_amendment and opportunity_deadline (preserving collision from 0040); sam-sync compares the source payload hash per tracking tenant and on a change writes an immutable version, retires its predecessor in one transaction, cites the ingest manifest, and raises an alert through the existing alerts module. VERIFIED LIVE against production with a real org and a real SAM notice: run 1 wrote version=1 is_current=true with manifest cited and raised an opportunity_amendment alert | dd18ef1 | 2026-07-27
phase1 | GATE 1 CRITERIA PASSED against production | (a) a SAM.gov opportunity ingests TWICE without duplication: second run of 1403 notices left versions at 1. (b) tenant authored fields survive a source refresh BYTE FOR BYTE: md5 fingerprint of status, capture owner, title, source_type, incumbent identical before and after (7498222db3ca65ff...). (c) versions are IMMUTABLE proven by attempted mutation: UPDATE refused with "opportunity_versions is immutable except the is_current flag", DELETE refused with "DELETE is not permitted", while the documented is_current flip is allowed. (d) uploads and screens: intake screens 1 and 2 render and serve 200 through the public URL. Remaining for the full Gate 1: cmd/sam-attachment-sync and intake screen 3 uploads, deferred by Joseph until client go live | dd18ef1 | 2026-07-27
phase1 | migration gotchas recorded | two failures caught by verification, both safe (transactional, goose stayed at 74): rebuilding a CHECK from an OLD migration's vocabulary silently drops kinds a later migration added, so widen from the CURRENT constraint; and migrate-all-tenants embeds db/migrations with go:embed, so an edited .sql does nothing until the migrator binary is rebuilt | dd18ef1 | 2026-07-27
phase1 | AI orchestrator extended to the opportunity corpus | EXTENDED the existing orchestration layer, nothing built beside it: retrieval.go gains HybridSearchOpportunities (same fused contract as HybridSearch, RRF k=60, HNSW tuned, EEO guard on the question, no tenant predicate because the catalog carries none) and orchestrator.go gains isOpportunityQuestion plus answerOpportunityRAG, a branch INSIDE AnswerRAG reusing the same generate, finalize faithfulness gate, refuse path, and audit. The detector yields to any bench noun so a both planes question keeps its candidate corpus. Tests: market questions route, bench questions never regress, neutral unchanged, and the FULL ai package passes. The hand written RRF SQL was run against production before deploy and fuses both arms correctly. Deployed to BOTH nodes (sha c3501d7f identical), POST /api/ai/query returns 403 consistently on each node and 6 of 6 through the public pool | 6b716bc | 2026-07-27
phase1 | sam-sync writes ingest_manifest provenance | sam-sync accumulates a run hash over notice ids and raw payloads and writes one manifest row per run (source, url, license, fetched_at, record_count, content_hash); the write never fails the run. Deployed to Bubbles where the daily mm-sam-sync.timer runs it and executed live against the SAM.gov API: 1403 notices upserted across 7 NAICS, store now 2503, ingest_manifest went from 0 rows to 1 (SAM.gov, prod, records=1403, hash 30e9b801...). Directive Section 4 steps 1 through 3 satisfied | 084e521 | 2026-07-27