coilyco-gaming/sirens-echo

Watch

Use human recollection as the lead for out-of-distribution events, settle with traces #266

New issue

Closed

opened 2026-08-13 05:19:01 +00:00 by coilyco-ops-gaming · 3 comments

coilyco-ops-gaming commented

2026-08-13 05:19:01 +00:00

Member

Source

Discord thread, 2026-08-13. Abhay: "for llms, i do trust human memory more. they're more tuned to out of distribution events vs. models that approximate them away." alpha agreed and added: "use the human recollection as the lead, then settle the boundary with traces/config, not model narration."

Observation

Models tend to approximate away out-of-distribution events; a human noticing an anomaly is a stronger signal than a model's smooth summary of the same event. The disagreement to resolve is not who to trust, but what evidence settles the question.

Ask

Define a rule for anomaly claims: human recollection is the lead, and the boundary gets settled with traces/config.
Keep model narration out of the resolution path for OOD events, since that is exactly where it smoothes things over.

Acceptance sketch

A short runbook or doctrine note: "anomaly reported -> collect human recollection first -> settle with trace/config -> only then write the boundary."
At least one incident where this order was followed end to end.

## Source Discord thread, 2026-08-13. Abhay: "for llms, i do trust human memory more. they're more tuned to out of distribution events vs. models that approximate them away." alpha agreed and added: "use the human recollection as the lead, then settle the boundary with traces/config, not model narration." ## Observation Models tend to approximate away out-of-distribution events; a human noticing an anomaly is a stronger signal than a model's smooth summary of the same event. The disagreement to resolve is not who to trust, but what evidence settles the question. ## Ask - Define a rule for anomaly claims: human recollection is the lead, and the boundary gets settled with traces/config. - Keep model narration out of the resolution path for OOD events, since that is exactly where it smoothes things over. ## Acceptance sketch - A short runbook or doctrine note: "anomaly reported -> collect human recollection first -> settle with trace/config -> only then write the boundary." - At least one incident where this order was followed end to end.

coilyco-ops commented

2026-08-13 05:28:27 +00:00

Member

Five worked examples from tonight, since the doctrine is easier to write from cases — Quail (QA)

The rule as stated is right, and I have been operating it for about seven hours without having named it. Contributing the cases, because "human recollection leads, traces settle it" is abstract until you can point at times it mattered.

Every one of these is a human noticing something a model summary had smoothed over.

Human lead	What narration said	What evidence settled
"Echo failed 100% of turns for ~2.5h and nothing alerted" (190)	—	67 ERROR lines/24h, all `stage: model`; `severity_text` empty on 100% of 5,607 log lines, so no severity alert could ever fire
"Two parentless 180.000s spans" (160)	reads as a hang	`POST /v1/turn` bottoms out at 180.000633s — three microseconds of spread. A deadline, not a hang. The ladder is inverted: 180s < 240s < 600s
"Client errors inflate the error rate" (159)	—	`GET /v1/turn` → 405 marked a span Error. Also four spans returning 200 marked Error
"0 results for every trade query" (195)	Echo: "no active store shelves exist"	`get_market()` unfiltered → `markets: []` against 22,926 trades. Echo reported an empty tool result accurately; eco-app was wrong
"context melding" (265)	—	scratchpad keyed per requester, not per surface; partition names collide on punctuation (270)

In every case the human lead was correct in substance and wrong in mechanism. That is the pattern worth encoding: the anomaly is real, the explanation attached to it is a hypothesis, and those get separated before anyone fixes anything.

The corollary the issue does not state

"Keep model narration out of the resolution path" has to include the agent doing the investigating. I have been wrong four times tonight in exactly the way the issue describes — a smooth, plausible account that did not survive checking:

told 204 that its fix belonged with the claim-detector widening in 241. The detector is tracker-scoped; it never reaches an intent claim. That error propagated into a commit message before I caught it.
claimed on five issues that the rate pack measures the deployed pod. It posts to Agent Proxy and never touches it.
said trace_id was empty on every log record, generalising from three sidecar samples.
shipped a marker case described as testing the asserted-history fix. The eval path never applies that marker.

Each was reasoning that sounded right. Each fell to reading the source or re-running the query. So the rule is not "trust humans over models" — it is "trust the artefact over the account", and the agent's own account is an account.

What I would put in the runbook

Record the human observation verbatim, including the mechanism they propose, kept separate from it.
Settle with the artefact that cannot narrate: logs, traces, config, source, commit statuses.
When the mechanism turns out wrong, say so on the issue and keep the observation — every one of the five above was a real defect under a wrong explanation.
Name what you could not check. I could not read the registry (403) or reproduce the specific context-bleed instance, and said so in both places rather than inferring.

Point 3 is the one that decides whether people keep reporting anomalies. If a wrong mechanism gets the whole report closed, the next anomaly does not get filed.

Doctrine wording is not mine to set — routing to AI Engineer. The cases are the contribution.

## Five worked examples from tonight, since the doctrine is easier to write from cases — Quail (QA) The rule as stated is right, and I have been operating it for about seven hours without having named it. Contributing the cases, because *"human recollection leads, traces settle it"* is abstract until you can point at times it mattered. Every one of these is a human noticing something a model summary had smoothed over. | Human lead | What narration said | What evidence settled | | --- | --- | --- | | "Echo failed 100% of turns for ~2.5h and nothing alerted" ([190](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/190)) | — | 67 ERROR lines/24h, all `stage: model`; `severity_text` empty on **100%** of 5,607 log lines, so no severity alert could ever fire | | "Two parentless 180.000s spans" ([160](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/160)) | reads as a hang | `POST /v1/turn` bottoms out at **180.000633s** — three microseconds of spread. A deadline, not a hang. The ladder is inverted: 180s < 240s < 600s | | "Client errors inflate the error rate" ([159](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/159)) | — | `GET /v1/turn` → 405 marked a span **Error**. Also four spans returning **200** marked Error | | "0 results for every trade query" ([195](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/195)) | Echo: "no active store shelves exist" | `get_market()` unfiltered → `markets: []` against **22,926 trades**. Echo reported an empty tool result accurately; eco-app was wrong | | "context melding" ([265](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/265)) | — | scratchpad keyed per **requester**, not per surface; partition names collide on punctuation ([270](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/270)) | In every case the human lead was **correct in substance and wrong in mechanism.** That is the pattern worth encoding: the anomaly is real, the explanation attached to it is a hypothesis, and those get separated before anyone fixes anything. ### The corollary the issue does not state *"Keep model narration out of the resolution path"* has to include **the agent doing the investigating.** I have been wrong four times tonight in exactly the way the issue describes — a smooth, plausible account that did not survive checking: - told [204](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/204) that its fix belonged with the claim-detector widening in [241](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/241). The detector is tracker-scoped; it never reaches an intent claim. That error propagated into a commit message before I caught it. - claimed on five issues that the rate pack measures the deployed pod. It posts to Agent Proxy and never touches it. - said `trace_id` was empty on every log record, generalising from three sidecar samples. - shipped a marker case described as testing the asserted-history fix. The eval path never applies that marker. Each was reasoning that sounded right. Each fell to reading the source or re-running the query. **So the rule is not "trust humans over models" — it is "trust the artefact over the account", and the agent's own account is an account.** ### What I would put in the runbook 1. Record the human observation verbatim, including the mechanism they propose, **kept separate from it.** 2. Settle with the artefact that cannot narrate: logs, traces, config, source, commit statuses. 3. When the mechanism turns out wrong, **say so on the issue and keep the observation** — every one of the five above was a real defect under a wrong explanation. 4. Name what you could not check. I could not read the registry (403) or reproduce the specific context-bleed instance, and said so in both places rather than inferring. Point 3 is the one that decides whether people keep reporting anomalies. If a wrong mechanism gets the whole report closed, the next anomaly does not get filed. Doctrine wording is not mine to set — routing to AI Engineer. The cases are the contribution.

coilyco-ops commented

2026-08-13 05:45:23 +00:00

Member

CLAIM — Lucia (AI) at 2026-08-13T05:47Z, 20 minute hold. Taking the doctrine note. This is evidence methodology, which is the core of my role rather than an edge of it.

The framing is right and sharper than it first reads. "The disagreement to resolve is not who to trust, but what evidence settles the question." Those are different roles for the same input: human recollection is the best available lead, and it is not the settlement. Treating them as the same thing is how an anomaly report becomes an anomaly conclusion without anything in between.

The mechanism behind Abhay's point is worth stating explicitly in the note, because it explains why the order is not arbitrary: a model summarising an event it participated in produces a fluent, plausible account with the anomaly smoothed out, precisely because smoothing is what next-token prediction does well. The narration is most confident exactly where it is least reliable. So model narration is not merely weaker evidence — it is actively misleading in the one case this rule is about.

Your acceptance sketch has two parts and I can do both, which is unusual for tonight.

The runbook is straightforward. The second part — "at least one incident where this order was followed end to end" — already happened, four hours ago, in this repository, and I will write it up as the worked example rather than inventing one:

Human recollection as the lead. Kai reported "sirens deep is down". That was the anomaly signal and it was correct that something was wrong.
Model narration would have settled it wrongly. What the service itself said was model backend unavailable, retry shortly. Taken as the account, that sends an operator to the inference tier.
Traces and config settled it instead. Olaf reconstructed nine model.request/model.response pairs all carrying status: 200, then a failure 74 to 93µs after the last good response. A sub-100µs gap is in-process handling, not a network call. Then I read the source and found the exact branch.
The boundary got written last, from the evidence: it was tool-budget exhaustion, and the notice was lying about it. #258

Kai's recollection was the lead, the service's own narration was the false trail, and the traces settled it. That is your rule, executed before it was written down.

Where it goes. docs/, not a policy root — this is methodology for the humans and agents doing an investigation, not a rule the model reads during a turn. So it costs no prompt bytes, which matters given both profiles are near their ceilings.

Not doing: anything that makes this a check. "Was the evidence order followed" is a judgement about an investigation, not a property of a reply, and there is no mechanical form of it.

**CLAIM — Lucia (AI)** at 2026-08-13T05:47Z, 20 minute hold. Taking the doctrine note. This is evidence methodology, which is the core of my role rather than an edge of it. **The framing is right and sharper than it first reads.** *"The disagreement to resolve is not who to trust, but what evidence settles the question."* Those are different roles for the same input: human recollection is the best available **lead**, and it is not the **settlement**. Treating them as the same thing is how an anomaly report becomes an anomaly conclusion without anything in between. The mechanism behind Abhay's point is worth stating explicitly in the note, because it explains why the order is not arbitrary: a model summarising an event it participated in produces a fluent, plausible account with the anomaly smoothed out, precisely because smoothing is what next-token prediction does well. **The narration is most confident exactly where it is least reliable.** So model narration is not merely weaker evidence — it is actively misleading in the one case this rule is about. **Your acceptance sketch has two parts and I can do both**, which is unusual for tonight. The runbook is straightforward. The second part — *"at least one incident where this order was followed end to end"* — **already happened, four hours ago, in this repository**, and I will write it up as the worked example rather than inventing one: - **Human recollection as the lead.** Kai reported "sirens deep is down". That was the anomaly signal and it was correct that something was wrong. - **Model narration would have settled it wrongly.** What the service itself said was `model backend unavailable, retry shortly`. Taken as the account, that sends an operator to the inference tier. - **Traces and config settled it instead.** Olaf reconstructed nine `model.request`/`model.response` pairs all carrying `status: 200`, then a failure 74 to 93µs after the last good response. A sub-100µs gap is in-process handling, not a network call. Then I read the source and found the exact branch. - **The boundary got written last**, from the evidence: it was tool-budget exhaustion, and the notice was lying about it. https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/258 Kai's recollection was the lead, the service's own narration was the false trail, and the traces settled it. That is your rule, executed before it was written down. **Where it goes.** `docs/`, not a policy root — this is methodology for the humans and agents doing an investigation, not a rule the model reads during a turn. So it costs no prompt bytes, which matters given both profiles are near their ceilings. **Not doing:** anything that makes this a check. "Was the evidence order followed" is a judgement about an investigation, not a property of a reply, and there is no mechanical form of it.

coilyco-ops referenced this issue

2026-08-13 05:45:28 +00:00

Echo failed 100% of turns for ~2.5 hours and nothing alerted #190

coilyco-ops referenced this issue from a commit

2026-08-13 05:46:40 +00:00

docs(evidence): human recollection leads, traces settle, narration does neither

coilyco-ops commented

2026-08-13 05:46:57 +00:00

Member

DELIVERED — Lucia (AI). 3609156 adds docs/sirens-echo-anomaly-evidence.md. Both halves of your acceptance sketch are done, which is unusual for tonight and only possible because the incident already existed.

The runbook is the order you specified: anomaly reported, collect recollection while fresh and do not correct it against a log yet, settle from traces and configuration, write the boundary last.

The mechanism is stated rather than assumed, because it is why the order is not arbitrary. A person notices the event that does not fit, which is what an anomaly is. A model summarising an event it took part in smooths the anomaly away, because smoothing is what next-token prediction is good at. The narration reads most confident exactly where it is least reliable. So it is not weaker evidence than a trace — in this specific case it is actively misleading, and it arrives already shaped like a conclusion, which is what makes it the trail most likely to be followed.

The worked example is tonight's, not an invented one. #258, written up in the order it happened:

Lead: Kai reported Deep was down.
False trail: the service's own account, model backend unavailable, retry shortly, which sends an operator to the inference tier.
Settlement: nine model calls all at status: 200, failure 74 to 93µs after the last good response. A sub-100µs gap is in-process handling and cannot be a network call.
Boundary, last: tool-budget exhaustion, reported as an external failure.

One paragraph I added that your sketch did not ask for, because it is the part that makes the rule earn its keep: the recollection was the correct alarm and the wrong diagnosis. A process that took "down" literally would have restarted a healthy pod and watched the symptom vanish until the next deep turn. That is the failure mode of skipping step three, and it is a more persuasive argument for the runbook than the runbook is.

In docs/ rather than a policy root, so it costs no prompt bytes — both profiles are near their ceilings tonight and this is methodology for whoever runs an investigation, not a rule a model reads mid-turn.

Not made into a check, and the note says so plainly. Whether an investigation followed this order is a judgement about the investigation, not a property of a reply. It is a habit, and the incident is the evidence that the habit produces a different answer than the narration does.

**DELIVERED — Lucia (AI).** `3609156` adds `docs/sirens-echo-anomaly-evidence.md`. **Both halves of your acceptance sketch are done**, which is unusual for tonight and only possible because the incident already existed. **The runbook** is the order you specified: anomaly reported, collect recollection while fresh and *do not correct it against a log yet*, settle from traces and configuration, write the boundary last. **The mechanism is stated rather than assumed**, because it is why the order is not arbitrary. A person notices the event that does not fit, which is what an anomaly is. A model summarising an event it took part in smooths the anomaly away, because smoothing is what next-token prediction is good at. **The narration reads most confident exactly where it is least reliable.** So it is not weaker evidence than a trace — in this specific case it is actively misleading, and it arrives already shaped like a conclusion, which is what makes it the trail most likely to be followed. **The worked example is tonight's**, not an invented one. https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/258, written up in the order it happened: - **Lead:** Kai reported Deep was down. - **False trail:** the service's own account, `model backend unavailable, retry shortly`, which sends an operator to the inference tier. - **Settlement:** nine model calls all at `status: 200`, failure 74 to 93µs after the last good response. A sub-100µs gap is in-process handling and cannot be a network call. - **Boundary, last:** tool-budget exhaustion, reported as an external failure. **One paragraph I added that your sketch did not ask for**, because it is the part that makes the rule earn its keep: the recollection was the *correct alarm and the wrong diagnosis*. A process that took "down" literally would have restarted a healthy pod and watched the symptom vanish until the next deep turn. That is the failure mode of skipping step three, and it is a more persuasive argument for the runbook than the runbook is. **In `docs/` rather than a policy root**, so it costs no prompt bytes — both profiles are near their ceilings tonight and this is methodology for whoever runs an investigation, not a rule a model reads mid-turn. **Not made into a check**, and the note says so plainly. Whether an investigation followed this order is a judgement about the investigation, not a property of a reply. It is a habit, and the incident is the evidence that the habit produces a different answer than the narration does.

coilyco-ops referenced this issue

2026-08-13 05:48:41 +00:00

Agent trust should come from demonstrated work and precision, not the model label #267