Explicit Absence

RFC-0009: Explicit Absence

Status: Canonical when compliance tests pass Canonical claim is invalid if RFC-0008 tests fail. A release may not publish "Canonical" status unless CI attests the test suite hash and pass state.

Test file: supabase/functions/tests/first-article-invariant.test.ts Reference implementation: Semantic annotations envelope (src/types/evaluation-envelope.ts)

"Up-to-date" Terminal State Representation

"Up-to-date" is represented as skipped_not_needed with reason_codes: ["up_to_date"] when the evaluator determines no action is required for the current fingerprint. This is not a separate terminal state—it is a reason within an existing state.

Purpose

Ensure that evaluation itself is a recorded epistemic event, not an implicit assumption.

Principle

"Absence must be explicit, never inferred."

Any subsystem that evaluates a question about the world MUST persist an explicit outcome state. Absence of data MAY NOT be used to imply absence of evaluation, applicability, or relevance.

Required Terminal States

Idempotence Requirement

• input_fingerprint + evaluator_version define identity
• Re-evaluation with identical inputs MUST NOT mutate state
• "Up-to-date" is a recognized terminal condition, not a rewrite

Standard Reason Codes

up_to_date | not_applicable | not_needed | dependency_unavailable | circuit_open | timeout | parse_fail | schema_fail | auth_fail | unknown_error

Forbidden Patterns

1. Inferring non-applicability from missing data
2. Treating null/undefined as "did not evaluate"
3. Silent skipping without recorded reason
4. Logging skip/fail without persisting envelope
5. Returning result for non-ready status
6. Omitting error object for failed status

Compliance

Implementation validity is defined by passing all tests in: supabase/functions/tests/first-article-invariant.test.ts

Claims in llms.json are only valid if tests pass.

⸻

Appendix A: How Nutrition Forced Explicit Absence

This appendix is explanatory and non-normative. Compliance is defined solely by tests.

This appendix documents the empirical origin of RFC-0008. The First-Article Invariant was not designed top-down—it emerged bottom-up from production failures in the nutrition domain.

The Original Problem: Silent Nulls

In the nutrition computation pipeline, NULL values appeared frequently:

• Missing nutrients in FDC database records
• Unmeasured values for exotic ingredients
• Parser failures that emitted nothing
• AI omissions during semantic annotation

The system initially treated NULL as "unknown." This was wrong.

NULL actually meant one of:

• "Not present in the database"
• "Not measured by the lab"
• "Not applicable to this ingredient"
• "Parser didn't emit it"
• "AI hallucinated or omitted it"

Each meaning required different handling. Collapsing them into silence created epistemic debt.

The Cascade of Failures

Production pressure exposed the lie:

1. Alcohol drift: Wine calories were underestimated because alcohol evaporation during cooking was not tracked. The system had no record of whether evaporation was evaluated.

2. Hydration ambiguity: Cooked vs. raw states changed mass by 2-3x. Without explicit state tracking, the system couldn't distinguish "user didn't specify" from "we didn't ask."

3. Fiber disappearing: Some database entries lacked fiber data. The pipeline silently summed zeros instead of flagging incomplete nutritional profiles.

4. Semantic annotation gaps: When AI annotation was skipped (rate limit, timeout, not needed), there was no record. Auditors couldn't distinguish "safe to skip" from "accidentally skipped."

The common failure mode: We don't know because nothing was written.

The Emergence of Explicit Terminal States

Post-mortems forced the question:

"Did we check hydration?" "Did we check alcohol?" "Did we check cooked vs raw?"

The answer kept being: "We can't tell."

This produced the invariant:

Evaluation itself creates an obligation to persist a terminal state.

The terminal states emerged from real failure modes:

Each was a real production scenario before it was a type.

The Birth of EvaluationEnvelope

The semantic annotations system became the reference implementation:

• It never blocks authoritative computation
• It is idempotent (fingerprint + version)
• It records terminal status with provenance
• It separates telemetry from authority

The envelope pattern crystallized:

interface EvaluationEnvelope<T> {
  status: EvaluationStatus;
  subject: { domain; aspect; subject_id };
  input_fingerprint: string;
  evaluator_version: string;
  evaluated_at: string;
  result?: T;
  reason_codes?: string[];
  error?: { code; message; retryable };
  provenance: { evaluator_id; triggered_by; model? };
}

Every field exists because its absence caused a production failure.

Why Theory Alone Would Not Have Produced This

Academic governance frameworks often start with:

• Formal ontologies
• Abstract epistemic categories
• Top-down rule imposition

This invariant came from:

• Production logs
• User confusion
• Drift detection failures
• Post-mortem analysis

The insight "Absence must be explicit, never inferred" is philosophically sound—but it was earned empirically, not derived theoretically.

Conclusion: Reality Wrote the Tests

Most governance systems build theory and fight reality.

RFC-0008 emerged because reality wrote the tests:

• Alcohol evaporation wrote test case FA-003
• Fiber nulls wrote test case FA-005
• Annotation timeouts wrote test case FA-006

The First-Article Invariant is not an abstraction imposed on nutrition.

It is nutrition's demand, formalized.

⸻