AskFidelity has no status for an ask that was dropped, and no field for who agreed to drop it

[Steffen025]

7.40.4 already carries both halves of the frame-fidelity idea, and this is a proposal to sharpen the
second, not to add the first:

• ISAFormat.md:165-177 — frame_drift: none | detected | skipped_no_goal_literal | null, written
  at VERIFY entry against principal_stated_goal, immutable thereafter, with
  frame_drift_summary for the detail. A per-run verdict.
• LIFEOS/TOOLS/AskFidelity.ts — a per-ask ledger: --ask "<text>:<status>", statuses
  met, skipped, surfaced, plus the blocking status, with --deferred "<item>:<reason>" and a
  --check corpus-health mode. The tool already refuses a status that needs a reason and arrives
  without one (:91), which is the discipline this builds on.

The gap is between them. An ask that was dropped — not met, not skipped-with-a-reason, not
deferred to a named later, but silently removed from the run's scope — has no status, so it does not
appear in the ledger at all. And no status carries who agreed: skipped — principal deferred it
is free text, so the ledger records that someone said a principal agreed, not that a principal did.

Measured on the tag:

grep -rn 'ratified_by' .           # 0 hits, whole tree
grep -n 'const STATUSES' LifeOS/install/LIFEOS/TOOLS/AskFidelity.ts
# 54:const STATUSES = ["met", "skipped", "surfaced", BLOCKING] as const;
grep -n 'frame_drift' LifeOS/install/LIFEOS/DOCUMENTATION/ISA/ISAFormat.md   # 165,166,169,176,177,187

The last count is there so the first reads as an absence and not as a grep that missed.

frame_drift does not close this, and I think deliberately: it is one verdict per run, computed at
VERIFY entry against the goal literal. An ask dropped mid-run leaves the goal literal intact, so the
drift check is honestly none while the delivered scope is smaller than the asked scope. The
row-level ledger is where that shows up, and today it has no vocabulary for it.

The proposal

Two additions, both small, both in the shape the tool already uses:

1. A dropped status, subject to the same reason requirement :91 already enforces on the
   statuses that need one. Its value is that it forces an ask out of silence and into a row.
2. A ratified_by field on any status that claims someone agreed — the principal, a reviewer, a
   named person. Free text saying "principal deferred it" and a field saying who ratified it are
   different claims, and only the second can be checked later.

Both hatch directions want testing: a dropped that is too easy to write becomes the status
everything gets, and a ratified_by that is required where nobody ratified anything blocks honest
rows. The version running here tests both directions rather than only the too-loose one, which is
the part I would carry over regardless of whether the field names match.

What I am not claiming

That this belongs in AskFidelity rather than beside it. The tool's header calls the corpus a
health surface, and adding two fields to a shipped schema has a migration cost for existing rows
that I have not measured against a public install.

[danielmiessler]

Thanks @Steffen025. Your reading still matches local source: AskFidelity.ts has the same four statuses and no field for who agreed. A dropped ask only shows today as frame drift at verification. A ratified_by field is only worth having if the principal's agreement is captured by the system rather than typed in by the model, and that capture is the hard part. Noted, not scheduled.