Evidence gap register
Record the gap before the claim grows.
An evidence gap row preserves what TraceMap or a reviewer can show, what cannot be concluded, and who owns the next public-safe proof or validation step.
Public claim level: concept. No public conclusion without evidence. A gap row is a bounded follow-up item, not proof that impact is absent, runtime behavior is known, release is ready, or coverage is complete.
When to use it
A gap is useful when it keeps uncertainty actionable.
Evidence exists, but it is not enoughKeep the rule family, tier, coverage label, public-safe context, and limitation visible instead of smoothing the gap into stronger wording.
The next proof route is knownPoint the row to validation, limitations, owner follow-up, claim review, or another public-safe route that can collect or explain the missing evidence.
The sentence needs a stop signUse the row to hold, downgrade, keep internal, or hand off a claim before it implies proof that the available evidence cannot support.
The audience needs a durable noteA register row gives future readers the same boundary the original reviewer saw: the useful evidence, the missing proof route, the role that can supply the next answer, and the exact wording that must wait. That makes the gap portable across a review packet, a manager summary, or an owner handoff without changing it into a stronger claim, and easy to audit during later review.
Fields
Every row carries the same boundary.
gap labelNeutral name for the missing, reduced, stale, unsupported, unknown, validation, private-only, or owner-question state.what evidence existsThe public-safe evidence category, not a source excerpt, local artifact, command transcript, or private detail.what cannot be concludedThe stronger claim that must remain unavailable from this row.public claim levelUse concept for these register rows unless a separate evidence-backed decision upgrades a future surface.next ownerA public role category that can collect proof, validation, or a decision record.proof/validation routeAn existing public-safe route that explains the next check, limitation, handoff, or claim-review step.safe wordingA bounded sentence that keeps the label attached.stop conditionThe point where public wording must hold, downgrade, stay internal, or move to owner follow-up.Example gap rows
Use the row that matches the missing proof state.
| Gap label | What evidence exists | What cannot be concluded | Public claim level | Next owner | Proof/validation route | Safe wording | Stop condition |
|---|---|---|---|---|---|---|---|
| missing proof path | A public-safe summary says a claim needs proof, but the supporting route or artifact is absent or not ready for public use. | Public proof, repeatable proof-link support, demo-backed wording, or absence of impact; an unavailable proof path cannot support a public proof-link claim. | concept | site owner or reviewer | Validation and review claim checklist | Record this as a missing proof path and collect a public-safe proof route before repeating the claim. | Stop before publishing proof-link wording or treating the claim as supported. |
| reduced coverage | Scan or review context carries a reduced, partial, fallback, unsupported, or unavailable coverage label. | Clean repo, complete coverage, release readiness, operational certainty, runtime behavior, or no impact; reduced coverage cannot support clean, complete, release-ready, or absence-of-impact wording. | concept | scanner owner or reviewer | Reduced coverage playbook | Coverage is reduced, so keep the label attached and use the row as review input only. | Stop before removing the limitation or upgrading the conclusion. |
| Tier4Unknown | Evidence exists only as an unknown tier, unresolved gap, unavailable source, or unclassified support note. | Tier1Semantic, Tier2Structural, or Tier3SyntaxOrTextual certainty; semantic proof; complete proof; unknown evidence cannot be upgraded by confidence, repetition, reviewer seniority, or pressure. |
concept | reviewer or scanner owner | Limitations and validation | The evidence tier is Tier4Unknown, so keep the statement downgraded until evidence is classified. | Stop before upgrading the tier or repeating a stronger claim. |
| private-only support | Internal evidence may exist, but a public-safe summary, public route, or reusable proof wording is not available. | Public proof, public demo support, customer-specific conclusion, or publishable detail; private-only evidence cannot be cited as public proof until summarized through a public-safe route. | concept | site owner or evidence owner | Review claim checklist | Treat private-only support as internal follow-up until a public-safe summary exists. | Stop before publishing private material or citing it as public proof. |
| stale commit | Evidence belongs to an older source context, previous commit, older branch state, or outdated public summary. | Current-head proof, current-release wording, current source behavior, or current validation status; stale source context cannot support current-head, current-release, or current-proof wording. | concept | reviewer or source owner | Validation | The source context is stale, so current wording needs current-context confirmation. | Stop before current-head, current-release, or current-proof wording. |
| unsupported framework surface | A framework, route style, file type, adapter surface, or project pattern is outside public support or only structurally recognized. | Complete framework coverage, complete route coverage, runtime behavior, or semantic certainty; unsupported framework evidence cannot support complete framework or route coverage. | concept | framework owner or scanner owner | Limitations and reduced coverage | Record the framework surface as unsupported and route it to owner or scanner follow-up. | Stop before complete-framework, complete-route, or runtime wording. |
| missing validation evidence | A claim, row, or route lacks public-safe validation evidence, focused test evidence, build evidence, or browser sanity evidence. | Validation passed, demo backed, implementation ready, release ready, or proof complete; absent validation cannot support validation-passed, demo-backed, or implementation-ready wording. | concept | implementation owner or reviewer | Validation | Hold the claim until required validation evidence is present or explicitly deferred; internal validation plans are next steps, not public proof routes. | Stop before marking the implementation or claim ready. |
| unresolved owner question | The evidence points to a question that requires a service, framework, source, artifact, reviewer, or site owner response. | Owner agreement, absence of impact, operational certainty, release approval, or resolved risk; an unanswered owner question cannot be converted into an assumption of safety or no impact. | concept | public role category, such as source owner or evidence owner | Owner follow-up and evidence decision record | Carry the owner question forward with the evidence and stop condition attached. | Stop before converting an unanswered question into an assumption. |
Stop conditions
Stop before the row becomes a conclusion.
- Stop when the proof path is missing, unavailable, private-only, or stale.
- Stop when coverage is reduced, partial, syntax-only, unsupported, unknown, or marked
Tier4Unknown. - Stop when validation evidence is absent, hidden, or not public-safe.
- Stop when the next owner has not answered a question needed for the public claim.
- Stop before wording implies runtime proof, production traffic proof, endpoint performance proof, outage-cause proof, release approval, operational certainty, complete coverage, clean-repo status, AI impact analysis, or absence of impact.
Next-owner handoff
Transfer the evidence question with its boundary.
Use role categoriesSite owner, reviewer, scanner owner, framework owner, source owner, artifact publisher, implementation owner, and evidence owner are public-safe owner labels.
Ask for the next evidenceName the missing proof, validation, public-safe summary, or owner answer that would let a future reviewer repeat or downgrade the claim.
Keep private context outUse public-safe summaries and route links instead of private names, sample identities, source details, or local output locations.
Safe wording
Keep the label and next route in the sentence.
missing proof pathRecord this as a missing proof path until a public-safe proof route exists.reduced coverageCoverage is reduced, so this is review input, not a final conclusion.Tier4UnknownThe evidence tier is Tier4Unknown and cannot support a stronger public claim yet.private-onlyPrivate-only support needs a public-safe summary before public citation.staleThe source context is stale and needs current-context confirmation.unsupported framework surfaceThe framework surface is unsupported, so complete framework coverage is not available from this evidence.missing validation evidenceValidation evidence is missing, so hold readiness wording.unresolved owner questionThe owner question remains open and should travel with the stop condition.Unsafe wording
Rejected patterns stay inside this boundary.
- Rejected pattern: the missing proof path proves there is no impact.
- Rejected pattern: reduced coverage means the repository is clean.
- Rejected pattern: Tier4Unknown is enough because reviewers are confident.
- Rejected pattern: private evidence proves the public claim.
- Rejected pattern: stale evidence supports the current release.
- Rejected pattern: unsupported framework coverage is complete.
- Rejected pattern: missing validation evidence is acceptable for readiness.
- Rejected pattern: the unresolved owner question can be treated as approval.
- Rejected pattern: the register proves production traffic, runtime behavior, endpoint performance, outage cause, operational certainty, or release readiness.
- Rejected pattern: the register is AI or LLM impact analysis, embedding search, vector database analysis, prompt classification, or a replacement for human review.
Non-claims
The register records follow-up; it does not create proof.
- It does not run TraceMap, create facts, emit reducer findings, validate a build, approve a release, settle owner questions, assign fault, or replace tests, source review, runtime observability, release controls, or human judgment.
- It does not prove absence of impact, runtime behavior, production traffic, endpoint performance, outage cause, operational certainty, release readiness, clean-repo status, complete coverage, AI analysis, LLM analysis, embeddings, vector databases, or prompt classification.
- It does not publish raw facts, raw SQLite content, analyzer logs, raw source snippets, raw SQL, config values, secrets, local paths, raw remotes, generated scan directories, private sample names, raw command output, hidden validation details, or credential-like values.
Adjacent surfaces