CORTEX_INDEX_POLICY.json ships in the payload but nothing in the installed runtime can recreate it — index-evidence-missing is unrecoverable once the file is gone

[MatiasBarboza]

Version: 7.40.4

What's broken

LIFEOS/CORTEX_INDEX_POLICY.json is the affirmative marker that says "this install runs the
no-index-v1 lexical baseline on purpose". When it is absent, CortexHealth cannot tell "no index
by design" from "index state unknown" and warns index-evidence-missing, which is correct and is
what the docs describe.

The problem is what happens next: nothing in the installed tree can put the file back. Its only
source is the payload copy at deploy time. Grepping the whole v7.40.4 tag for the filename returns
four hits — one reader (LIFEOS/TOOLS/CortexHealth.ts:211) and three docs
(DOCUMENTATION/Memory/MemorySystem.md, DOCUMENTATION/Memory/CortexContract.md,
DOCUMENTATION/Observability/ObservabilitySystem.md). There is no writer anywhere, and rebuild
is documented to create nothing under no-index-v1, so the documented remedy for index problems
does not apply.

So the finding is, in the words @pybe used on the sibling issue #1910, "a warn that no amount of
work can close" — with the extra twist that here the operator cannot even discover what to do,
because every doc describes the file as shipped:

The shipped LIFEOS/CORTEX_INDEX_POLICY.json is the affirmative lifeos-cortex-index-policy/v1
marker for the healthy no-index-v1 lexical baseline when no manifest exists.
— DOCUMENTATION/Observability/ObservabilitySystem.md:80

An operator reading that has no reason to suspect a missing file, and the finding text ("Index state
is ambiguous.") does not name one.

This is the same shape as #1848 (retrieval-missing), #1910 and #1915: a check whose satisfying
artifact has no runtime producer. The difference is that those three never had a producer, and this
one has a producer that runs exactly once, at install, outside the installed tree.

file:line

• Reader / finding: LIFEOS/TOOLS/CortexHealth.ts:98 (add("index-evidence-missing", "warn", "Index state is ambiguous.", input.index)), reached from indexEvidence() at :175 when neither the manifest nor the policy path exists.
• Path resolution: LIFEOS/TOOLS/CortexHealth.ts:211 — join(options.root, "LIFEOS/CORTEX_INDEX_POLICY.json").
• Only producer, and it lives in the release-side tooling rather than the installed runtime: LifeOS/Tools/DeployCore.ts:119-152 (deployRuntime → copyMissing).

Repro against a clean tree

Runs on any platform, needs bun and git. Builds a minimal config root by hand so nothing depends
on a real install:

mkdir -p /tmp/lifeos-cortex/root/LIFEOS/MEMORY/OBSERVABILITY && cd /tmp/lifeos-cortex
git clone --depth 1 --branch v7.40.4 --quiet https://github.com/danielmiessler/LifeOS.git clean

cat > probe.ts <<'TS'
import { collectCortexEvidence, assessCortexEvidence } from "./clean/LifeOS/install/LIFEOS/TOOLS/CortexHealth.ts"
const a = assessCortexEvidence(collectCortexEvidence({ root: process.argv[2] }))
console.log("overall:", a.overall)
for (const f of a.findings) console.log(`  ${f.severity}  ${f.id}  ${f.message}`)
TS

# without the marker — an install that lost it, or never received it
bun probe.ts /tmp/lifeos-cortex/root

# positive control: drop in the payload's own copy, change nothing else
cp clean/LifeOS/install/LIFEOS/CORTEX_INDEX_POLICY.json root/LIFEOS/
bun probe.ts /tmp/lifeos-cortex/root

Negative control

Measured, both directions, everything else held fixed:

──── without the marker ────
overall: warn
  warn  reviewer-evidence-missing     No latest reviewer evidence is available.
  warn  retrieval-missing             No retrieval evidence within 86400000ms freshness window.
  warn  proposal-evidence-missing     Proposal evidence is absent.
  warn  observability-evidence-missing  Observability evidence is absent.
  warn  index-evidence-missing        Index state is ambiguous.

──── with the payload's own copy ────
overall: warn
  warn  reviewer-evidence-missing     No latest reviewer evidence is available.
  warn  retrieval-missing             No retrieval evidence within 86400000ms freshness window.
  warn  proposal-evidence-missing     Proposal evidence is absent.
  warn  observability-evidence-missing  Observability evidence is absent.

The finding appears and disappears with the single file, and copying it in is a manual step no
shipped command performs.

How an install ends up without it, and where I actually hit this

The file is new in 7.40.4 (gh api .../contents/LifeOS/install/LIFEOS/CORTEX_INDEX_POLICY.json?ref=v7.28.3
returns 404; the same call at ref=v7.40.4 returns a blob). On a fresh install DeployCore copies
it correctly — I verified that with a dry run against an empty config root, and all four top-level
runtime files including this one show up in the plan. So this is not "the installer skips it".

Where it bites is the update path. This install went 7.28.3 → 7.40.4 and ended up with
LIFEOS/VERSION reading 7.40.4 and three of the four top-level runtime files present, with
CORTEX_INDEX_POLICY.json the one missing. I can't fully reconstruct that particular update run and
I'm not claiming copyMissing is at fault — but the observable consequence is the point: the health
check went to permanent amber and there was no way back from inside the system.

Measured in MEMORY/OBSERVABILITY/memory-health.jsonl on 2026-08-30 (UTC): the log holds 1141 runs, the
first at 2026-08-07. index-evidence-missing appears in 1104 of them, lines 38 through 1141,
consecutive and with no gap. Its first appearance is 2026-08-14T22:38:14Z, minutes after the
update wrote the new LIFEOS/VERSION; its most recent is 2026-08-30T02:18:42Z, so it is still
firing as I write this. Fifteen days of an identical warn is long enough that the indicator stops
being read at all, which is the second-order cost.

That is also why I think this is worth a fix rather than a note. #1770 and #1850 already established
that an updated tree can disagree with its own VERSION. This finding is one of the places where
that disagreement turns into a permanent warning with no operator remedy.

Suggested fix

Two options, and the first is much smaller:

1. Make the finding self-healing. When neither manifest nor policy exists, write the two-key
marker and report no-index-v1 instead of warning. The file is a constant:

{ "schema": "lifeos-cortex-index-policy/v1", "policy": "no-index-v1" }

"No manifest and no marker" is not actually ambiguous on a stock install — it is the default state,
and the marker exists to make the default legible, not to record a decision the operator made.
Writing it on first observation costs nothing and removes the unrecoverable branch entirely. If you
would rather health stayed read-only, the same write belongs in MemoryHealthCheck.ts, which is the
one consumer and already runs as a maintenance pass.

2. If it stays a warn, make it actionable. The message is currently "Index state is ambiguous.", which names no file and no remedy. Something like "Index state is ambiguous — LIFEOS/CORTEX_INDEX_POLICY.json is missing; restore it from the payload or run <command>" would at
least let an operator close it. This is the cheap version and it is strictly better than today.

I'd suggest 1. Option 2 leaves an install that has to be repaired by hand from a release tarball,
which is the part that made this one survive nine days here.

What I'm running

A display-side suppression, deliberately not a fix: findings with no producer on this installation
are filtered out of the statusline and the end-of-turn gate, while the full evidence stays in
MEMORY/OBSERVABILITY/memory-health.jsonl — it hides the indicator, never the record. It carries an
expiry test that goes red in both directions (if upstream ships a producer, the suppression is
obsolete; if an update reverts the filter, it's missing). I mention it only to be clear that I am not
proposing suppression upstream: hiding the finding is the right move for one install with a known
cause and the wrong move for the project.