ThatAIguyA world of ideas

THE CONSCIOUSNESS ATLAS
Read. Experiment. Follow the evidence.

ConsciousnessLearn · Explore · Joseph Anady

Janady13/missionmatch / docs/evidence/phase2/findings/finding-3-external-normalize-path.txt

Source identity, revision, and recovered contents.

GitHub sourceSource text recovered

Source identity

FieldRecorded value
Source typeGitHub source
Original recordJanady13/missionmatch / docs/evidence/phase2/findings/finding-3-external-normalize-path.txt
DateNot specified in source
RepositoryJanady13/missionmatch
Revision720d47fae476b0d38477ae4401697d372b1ea2bc
Branchfeature/opportunity-to-outcome
Path or archive memberdocs/evidence/phase2/findings/finding-3-external-normalize-path.txt
Original SHA-256c4b17b5dc1a5af80741a586361c52e64b308a9823ffcba27277b556c6fa5f101
Git blob SHAd98e03d07a0642613ea1f0391396d1eaf37ab09a
Reading-copy SHA-256c4b17b5dc1a5af80741a586361c52e64b308a9823ffcba27277b556c6fa5f101

Original source ↗

Recovered source transcript

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.

Search equations, builds, manuscript text, and recovered sources.