The gap
The v1 prompt fragments under prompts/v1/ tell the model what to extract. None of them tell it what not to extract.
Measured across the whole fragment set, with a control confirming the search was live (7 files match fact):
| instruction class |
files containing it |
| against inventing content not present in the source |
0 |
| against transient or one-off content |
0 |
| toward durable or lasting content |
0 |
Nothing forbids the model from producing a "fact" it inferred rather than read, and nothing distinguishes a durable claim from a momentary one.
What that permits
Two failure classes, both observed in practice with small local models:
1. Invention from thin input. Given a short or low-content unit, a model asked only "extract facts" will produce facts. It has no instruction permitting an empty result, so it manufactures one. The output is well-formed, schema-valid, and unfalsifiable against the source.
2. Transient content promoted to durable. Bookkeeping and one-off events are extracted with the same confidence as lasting claims — a command that was run once, a status that was true for a minute, an identifier tuple. These validate cleanly and pollute whatever consumes the extraction, because nothing downstream can distinguish "this was true once" from "this is true."
A related third: given input phrased as a question, a model with no contrary instruction will answer the question and emit the answer as an extracted fact, rather than extracting what the question itself asserts.
Downstream filtering can suppress some of this by shape, but only after the fact and only for shapes someone anticipated. A model that rephrases a transient event into novel declarative prose defeats any fixed pattern set. The prompt is the only place the distinction can be made before the content exists.
Proposed change
Add negative instructions to the shared preamble (or a dedicated fragment included with the fact-bearing capabilities):
- Extract only what the source states or directly supports; do not infer, complete, or invent.
- An empty result is correct and preferred when the source contains nothing durable.
- Do not extract transient or one-off content: single executions, momentary status, bookkeeping identifiers.
- If the source is phrased as a question, extract what the question asserts. Do not answer it.
Proposed assertions
Pin the instructions as content assertions on the assembled prompt, so a fragment edit that drops them fails rather than silently regressing:
- the assembled Stage-1 prompt for a fact-bearing capability set contains an instruction against inventing content
- ... contains an instruction permitting an empty result
- ... contains an instruction against transient and one-off content
- ... contains an instruction against answering questions found in the source
Assertions on the assembled output rather than on individual files, so fragment reorganization does not break them.
Note on verification
A rejection or suppression count is not evidence of improvement here. If the instructions work, the model produces less junk, and any downstream filter's own counter drops for the same reason — measuring the filter measures the filter. Verify by reading extracted output against its source, not by counting.
The gap
The v1 prompt fragments under
prompts/v1/tell the model what to extract. None of them tell it what not to extract.Measured across the whole fragment set, with a control confirming the search was live (7 files match
fact):Nothing forbids the model from producing a "fact" it inferred rather than read, and nothing distinguishes a durable claim from a momentary one.
What that permits
Two failure classes, both observed in practice with small local models:
1. Invention from thin input. Given a short or low-content unit, a model asked only "extract facts" will produce facts. It has no instruction permitting an empty result, so it manufactures one. The output is well-formed, schema-valid, and unfalsifiable against the source.
2. Transient content promoted to durable. Bookkeeping and one-off events are extracted with the same confidence as lasting claims — a command that was run once, a status that was true for a minute, an identifier tuple. These validate cleanly and pollute whatever consumes the extraction, because nothing downstream can distinguish "this was true once" from "this is true."
A related third: given input phrased as a question, a model with no contrary instruction will answer the question and emit the answer as an extracted fact, rather than extracting what the question itself asserts.
Downstream filtering can suppress some of this by shape, but only after the fact and only for shapes someone anticipated. A model that rephrases a transient event into novel declarative prose defeats any fixed pattern set. The prompt is the only place the distinction can be made before the content exists.
Proposed change
Add negative instructions to the shared preamble (or a dedicated fragment included with the fact-bearing capabilities):
Proposed assertions
Pin the instructions as content assertions on the assembled prompt, so a fragment edit that drops them fails rather than silently regressing:
Assertions on the assembled output rather than on individual files, so fragment reorganization does not break them.
Note on verification
A rejection or suppression count is not evidence of improvement here. If the instructions work, the model produces less junk, and any downstream filter's own counter drops for the same reason — measuring the filter measures the filter. Verify by reading extracted output against its source, not by counting.