Source identity
| Field | Recorded value |
|---|---|
| Source type | GitHub source |
| Original record | Janady13/missionmatch / docs/evidence/phase2/findings/finding-3-external-normalize-path.txt |
| Date | Not specified in source |
| Repository | Janady13/missionmatch |
| Revision | 720d47fae476b0d38477ae4401697d372b1ea2bc |
| Branch | feature/opportunity-to-outcome |
| Path or archive member | docs/evidence/phase2/findings/finding-3-external-normalize-path.txt |
| Original SHA-256 | c4b17b5dc1a5af80741a586361c52e64b308a9823ffcba27277b556c6fa5f101 |
| Git blob SHA | d98e03d07a0642613ea1f0391396d1eaf37ab09a |
| Reading-copy SHA-256 | c4b17b5dc1a5af80741a586361c52e64b308a9823ffcba27277b556c6fa5f101 |
Recovered source transcript
Download complete source text ↓205 lines · 11.4 KB
FINDING THREE, EXECUTED AND BLOCKED AT THE FAR END
The external normalize path had never executed.
Run 29 July 2026 at commit 52fcbb9, staging cluster missionmatch_staging on M4.
STATUS: NOT CLOSED. Everything on this side of the boundary is proven. The
external service refused all three calls with insufficient_quota, so the one
thing this finding is ultimately about, prose returned by an external model
passing through the verifier, has no evidence and cannot be manufactured. It
needs one action from Joseph. It is stated at the bottom.
WHAT WAS ORDERED AND WHAT HAPPENED, ITEM BY ITEM
1. RE PROVE THE SCRUB GATE POSITIVE CONTROLS. DONE, 22 of 22 green.
Including TestSuitePositiveControl and TestBindingSiteDetectorPositiveControl,
which are the two that prove the suite is measuring at all. Full list in the
run log below.
2. ENABLE THE OPENAI BACKEND FOR ONE BOUNDED RUN. DONE.
The key resolved from /Users/joseph/.megamind-secrets.env and nowhere else,
per the recorded owner decision of 28 July. No copy was made, no second file
was created, and the value was never printed.
The backend was enabled on a SEPARATE, TEMPORARY gateway process rather than
by flipping a flag on either running gateway. Reason: the staging gateway
reads .megamind-staging-secrets.env, which per the recorded decision does not
hold the key and must not, and flipping production would have widened the
enabled window to every consumer for the length of the run. A temporary
process on port 8097 bound the change to this run and to nothing else.
BOOT GUARD CONTROLLED BOTH WAYS BEFORE THE RUN, because a guard nobody has
seen fire is a guard nobody has tested:
enabled with an EMPTY MODEL refused to boot, by name
enabled with the KEY ABSENT refused to boot, by name
enabled with both present booted, logging openai_enabled=true and
generation backend=openai
3. EXACTLY THREE PUBLIC SAM NOTICE TEXTS THROUGH REQUIREMENT_NORMALIZE. DONE.
Three, not four, not five. The eligible pool held six and holds three now.
All three notices carry provenance public_cache, SELECTED from the database
rather than asserted by the program, and the gate permitted all three on that
basis.
4. CAPTURE THE AUDIT ROWS WITH BACKEND, PAYLOAD CLASS, BYTE COUNT, AND CONTENT
HASH. DONE, and it required building the thing that writes them. See
FINDING D19 below, which is the real discovery of this work.
entity_type content_hash backend payload_class bytes served_model
external_inference a179923bf11d megamind-gateway REQUIREMENT_NORMALIZE 237
external_inference_result a179923bf11d ollama:llama3.1:8b
external_inference c51e24dfc65a megamind-gateway REQUIREMENT_NORMALIZE 117
external_inference_result c51e24dfc65a ollama:llama3.1:8b
external_inference f3c46e811ea5 megamind-gateway REQUIREMENT_NORMALIZE 114
external_inference_result f3c46e811ea5 ollama:llama3.1:8b
3 egress rows, 3 outcome rows, all org scoped, 0 egress rows without a
matching outcome row, and 0 rows carrying payload content, checked by
joining every audit row against every notice title in the cache.
5. PROVE THE VERIFIER GATES THE RETURNED PROSE AND THE TYPED JSON CARRIES
CITATIONS. HALF DONE, and the half that is missing is the point of the
finding.
PROVEN, and backend independent:
TestMalformedPayloadFailsClosed prose that is not JSON is refused
TestUncitedModelOutputIsRejected an item with no quote is refused
TestFabricatedCitationIsRejected a quote NOT PRESENT in the source is
refused, which is the one that
matters, because a fabricated
citation reads exactly like a real one
TestInvalidScopeTypeIsRejected an out of vocabulary type is refused
TestEmptySourceRejectsEverything no source means nothing survives
TestGroundedItemIsAcceptedAndHashed a grounded item is accepted and hashed
PROVEN AGAINST LIVE OUTPUT: all three written items are extraction_method
model_normalize, review_status extracted, and every one carries a citation
hash. 0 uncited extracted items exist in the database, which the schema CHECK
independently forbids.
NOT PROVEN: that the verifier gates prose written by an EXTERNAL model. The
prose it gated came from the local runtime. The mechanism is identical and the
validator cannot tell where bytes came from, so the risk this leaves is small,
and it is not zero and should not be written up as though it were.
6. SET THE FLAG BACK TO FALSE. DONE, and verified rather than assumed.
the temporary process stopped, and its binary deleted
port 8097 closed, 0 listeners
gateway-backend.sh 0 mentions of MEGAMIND_OPENAI, unchanged
the secrets file 0 mentions of MEGAMIND_OPENAI_ENABLED
both persistent gateways openai NOT enabled, verified per process
8092 and the 8090 proxy healthz 200, still serving
7. RECORD THE SPEND. ZERO. Not "small", zero.
All three requests were refused with HTTP 429 insufficient_quota, which is a
refusal before service, so nothing was billable. The 129 completion tokens in
the outcome rows were produced by the LOCAL runtime and cost nothing.
WHY IT IS BLOCKED
The gateway logged, three times:
generate backend "openai" failed (backend status 429 Too Many Requests ...
"You exceeded your current quota, please check your plan and billing details"
"type": "insufficient_quota"), falling back to ollama
Probed directly at the boundary, key never printed:
key present yes, length 164, prefix sk-proj
HTTP 429, code insufficient_quota
THE KEY IS VALID. An invalid or revoked key answers 401. This answered 429 with
insufficient_quota, which is an authenticated request against an account with no
available credit. So the credential works and the account cannot serve.
WHAT THIS MEANS FOR THE BOUNDARY, stated carefully. The request left this
machine, carrying the composed public payload, and was refused at the far end.
The gate permitted it, the audit row was written BEFORE it left, and the outcome
row recorded what actually served it. Every mechanism on our side executed for
real against a live external endpoint for the first time. What did not happen is
a completion coming back.
I did not retry, switch models, or try a second account. A quota refusal is an
account state, not a transient error, and the recorded decision on this key is
that its state is Joseph's to confirm.
THE SILENT FALLBACK, AND WHY IT WAS NOT SILENT
The gateway falls back to the local runtime when the selected backend fails.
That is correct for availability and it is invisible in an audit trail that only
records intent. Had this run recorded only the egress row it would read, forever,
as three successful external calls. The pipeline would have reported accepted=3
rejected=0, three cited scope items would have been written, and every number
would have looked exactly like a successful external run.
RecordExternalOutcome is why it did not. It was written hours earlier in this
same session for exactly this reason, and the first run it ever saw was the run
it caught. The served_model column says ollama:llama3.1:8b three times.
This is the same shape as D18, where 55 chunks became 3 while the status still
read ok, and it was caught only because 55 had been written down. An instrument
that reports success while measuring something else is the recurring failure of
this build, and it is now caught twice by the same discipline: write down what
actually served, not what you asked for.
FINDING D19, FOUND WHILE DOING THIS: THE AUDIT ACTION WAS DECLARED, NEVER WRITTEN
ai.ActionExternalInference has existed since 27 July. 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 wrote it 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 they assert the SHAPE OF A MAP. Not one of them asked whether a
row existed.
Fixed at commit 52fcbb9. AllowExternalAudited gates and writes as one call and
FAILS CLOSED: an external call whose audit row cannot be written does not happen,
the same posture the auth module takes for security events. The row is written
BEFORE the payload leaves, which is the only ordering an auditor can trust, since
a row written afterwards is missing exactly when the process dies mid call.
Four new tests, MUTATION CONTROLLED: removing the write fails exactly the two
that assert it, and restoring it turns them green. Also asserted, because a
promise is worth checking: no insert argument carries the payload content, and a
refused payload writes no row at all.
ONE OBSERVATION, RECORDED NOT ACTIONED
Two of the three MM_MEGAMIND_URL settings point at port 8090, which is
/Users/joseph/pantheon-mlx/gateway-auth.mjs, a fifteen line node reverse proxy
belonging to PANTHEON. It injects the gateway bearer and forwards to 127.0.0.1:8092,
which IS megamind-gateway, so the boundary is intact and no payload reaches a
foreign service. Worth knowing anyway: a component outside this repository sits
in missionMATCH's inference path and makes a loopback only gateway reachable
across the tailnet with an injected credential. missionMATCH's own guarantees,
the scrub gate and the provenance check, run before the call and are unaffected.
WHAT CLOSING THIS NEEDS, and it is one thing
Credit on the OpenAI account behind the key in /Users/joseph/.megamind-secrets.env.
Nothing else. When it has credit, this rerun is three calls, a few cents, and
about ninety seconds:
on M4:
nohup env MEGAMIND_SECRETS_FILE=/Users/joseph/.megamind-secrets.env \
MEGAMIND_OPENAI_ENABLED=true MEGAMIND_OPENAI_MODEL=gpt-4o-mini \
MEGAMIND_GENERATE_BACKEND=openai MEGAMIND_ADDR=100.94.8.94:8097 \
./megamind-gateway-oaiprobe > /tmp/oaiprobe.log 2>&1 &
on Bubbles:
set -a; . /etc/missionmatch/staging.env; set +a
MM_SECRETS_FILE=/etc/missionmatch/api.env MM_MEGAMIND_URL=http://100.94.8.94:8097 \
/tmp/opportunity-scope-normalize -limit 3
Three notices are still eligible, so the rerun needs no seeding.
ACCEPTANCE, decided in advance so it cannot be softened afterwards: three
outcome rows reading openai:gpt-4o-mini. If served_model says ollama again, the
external lane did not execute and this finding stays open no matter what else
the run reports.
ALSO NOTED, from the recorded decision of 28 July: this key was pasted into chat
and sat in a plaintext Desktop file, so it should be treated as compromised
regardless of dashboard state. Adding credit to it is a decision about a key
already recorded as suspect. Rotating first would be the safer order.