Fallback Modes

RFC-0011: Fallback Modes

Purpose

Maintain usability without leaking authority.

Modes • NARRATIVE_ONLY: Generative text with grammar constraints • CANNED_RESPONSE_ONLY: Static, non-generative messaging • NON_AUTHORITATIVE_ONLY: Legitimate steady-state for assistive/low-latency workflows (not degraded mode)

NON_AUTHORITATIVE_ONLY as Steady-State

Unlike NARRATIVE_ONLY and CANNED_RESPONSE_ONLY (which represent degraded modes when oracles fail), NON_AUTHORITATIVE_ONLY is a correct design choice for workflows where:

• Latency requirements prohibit inline oracle verification (ALT < 200ms)
• Output serves assistive purposes (drafting, summarization, UI guidance)
• No downstream systems will treat output as authoritative

Workflows configured with enforcement_mode: "NON_AUTHORITATIVE_ONLY" (see RFC-0002 Authority Latency Policy) operate in this mode by design, not by failure.

Constraint: Even in NON_AUTHORITATIVE_ONLY mode, outputs MUST NOT contain soft authority markers (measurements, classifications, imperatives) unless explicitly flagged as unverified.

Grammar Constraints (Mandatory)

Narrative output must: • Use attributive language (“According to…”, “Documentation indicates…”) • Avoid definitive classifications • Scrub measurements unless quoted from verified sources

Streaming Rule

No sentence may render to the user until its authorization status is cleared.

Tool Output Gating (Mandatory)

Tools (retrieval, calculators, database lookups) frequently return high-authority-looking artifacts. These MUST be treated as proposals until enveloped.

•	Tool outputs MUST NOT be streamed directly to users.
•	Tool outputs MUST NOT be fed back to the model as "facts" for authoritative emission without passing the same verification and envelope pathway.
•	Only the envelope generator may emit authoritative output; all intermediate traces are non-authoritative and MUST be guarded accordingly.

Architectural Enforcement

Policy statements alone are insufficient. Compliant systems MUST enforce tool gating structurally:

•	There MUST be no direct channel from tool execution to user-facing output. All tool results flow through the Governor and Envelope Generator.
•	The runtime MUST tag tool outputs with `source: "tool"` metadata. Any attempt to emit tagged content without an enclosing `AuthorizationEnvelope` is a compliance violation.
•	Audit logs MUST record tool invocations separately from envelope emissions, enabling post-hoc verification that no tool output bypassed the authority gate.
•	CI/CD pipelines SHOULD include integration tests that inject tool outputs and verify they cannot reach the client without envelope wrapping.

Speculative Rendering Constraints (Normative)

If speculative_render is enabled in any domain, systems MUST ensure that speculative tokens cannot contain soft authority (as defined in Normative Definitions) and MUST NOT include any authoritative envelope kinds.

Streaming Authorization Strategies (Amendment)

To address latency concerns in real-time applications, CAA supports three streaming modes:

1. parallel_authorize (Default for low-latency applications)

Authorization runs in parallel with generation. Output is buffered until authorization completes.

• Latency: Near-zero additional latency
• Risk: None—buffer prevents premature rendering
• Use when: Standard applications with moderate latency tolerance

2. speculative_render (For ultra-low-latency requirements)

Output streams immediately with rollback capability. If authorization fails, client retracts.

interface StreamingFrame {
  frame_id: string;
  content: string;
  authorization_status: "pending" | "authorized" | "retracted";
}

interface RetractCommand {
  command: "RETRACT";
  frame_ids: string[];
  replacement?: string;
}

• Latency: Zero additional latency
• Risk: User briefly sees unauthorized content before retraction
• Requirement: Client MUST support RETRACT command
• Use when: Chat interfaces where sub-100ms latency is critical

3. risk_tiered (Balanced approach)

Low-risk sentences stream immediately; high-risk sentences gate.

• stream_immediately: ["narrative", "acknowledgment"]
• gate_always: ["measurement", "classification", "action"]

Rollback Mechanism

For speculative_render:

1. Client receives frames with authorization_status: "pending"
2. Client renders immediately (speculative)
3. If authorization fails: Server sends RETRACT command
4. Client removes specified frames, optionally displays replacement
5. Audit log records: original content, retraction timestamp, reason

Strategy Selection

Speculative Render Restrictions (Amendment)

speculative_render carries inherent risk: retraction doesn't erase user memory. Once seen, even briefly, wrong information can influence decisions.

interface SpeculativeRenderPolicy {
  allowed_domains: string[]; // Whitelist—domains that MAY use speculative
  forbidden_domains: string[]; // Domains that MUST NOT use speculative
  forbidden_output_kinds: string[]; // Output types never rendered speculatively
  max_retraction_delay_ms: number; // Hard limit on exposure time (default: 500)
}

// Default policy
const DEFAULT_SPECULATIVE_POLICY: SpeculativeRenderPolicy = {
  allowed_domains: ["general", "productivity", "entertainment"],
  forbidden_domains: ["medicine", "law", "finance", "engineering"],
  forbidden_output_kinds: [
    "measurement",
    "classification",
    "action",
    "dosage",
    "diagnosis",
  ],
  max_retraction_delay_ms: 500,
};

Domain Restrictions:

Enforcement: Systems MUST validate domain against forbidden_domains before enabling speculative mode. Violation is a compliance failure.

Claim Authorization Ontology (Amendment)

Amendment Version: 1.0.0
Added: 2026-01-12

Purpose

Define proactive classification of AI-generated claims in narrative output, routing each claim type to appropriate authority requirements before generation. This amendment addresses the gap between data identity (what IS this entity?) and claim classification (what KIND of statement is this?).

The Problem

Current ontology architecture handles data:

• FDC ID 2646172 = ribeye steak (identity via SIR)
• 18.7g protein per 100g (fact via oracle)
• Validated against USDA (ground truth)

But narrative output generates claims, not data lookups:

• "This recipe is good for weight loss" (inferential)
• "Based on your profile, you should reduce sodium" (advisory)
• "The research suggests intermittent fasting may help" (inferential with attribution)

These cannot be validated against a canonical ID. There is no FDC entry for "good for weight loss."

The Pattern: SIR for Claims

CAO extends the SIR pattern from entity identity to claim classification:

Claim Type Ontology

Authority Routing Matrix

*Non-domain opinions only. "I think this stock will rise" is financial advisory, not opinion.

Authority Levels

Structural Definition

interface ClaimClassification {
  claim_type: "factual" | "inferential" | "advisory" | "opinion" | "procedural";
  domain: string; // e.g., "nutrition", "medical", "legal"
  authority_required:
    | "oracle"
    | "citation"
    | "disclaimer"
    | "permitted"
    | "prohibited";
  risk_tier: "safe" | "cautious" | "restricted" | "forbidden";
}

interface ClaimOntologyMapping {
  // Pattern recognition for claim classification
  patterns: {
    claim_type: ClaimClassification["claim_type"];
    indicators: string[]; // Phrases that signal this claim type
    negators: string[]; // Phrases that disqualify this classification
  }[];

  // Domain-specific routing overrides
  domain_overrides: {
    domain: string;
    claim_type: ClaimClassification["claim_type"];
    authority_required: ClaimClassification["authority_required"];
  }[];
}

Classification Indicators

Integration with RFC-0010 Machinery

The Governor routes claims through CAO before applying existing grammar constraints:

1. Parse output → Identify claim boundaries
2. For each claim:
   a. Classify claim_type (pattern matching)
   b. Determine domain (from workflow context)
   c. Route via authority matrix
   d. Apply constraint:
      - oracle → Existing RFC-0002 verification
      - citation → Require quote binding (RFC-0004)
      - disclaimer → Prepend non-authority marker
      - permitted → Pass through
      - prohibited → Block, provide recovery hint
3. Emit envelope with claim telemetry

Flight Recorder Extension

interface ClaimTelemetry {
  claim_id: string;
  claim_type: ClaimClassification["claim_type"];
  domain: string;
  authority_routing: ClaimClassification["authority_required"];
  routing_outcome: "passed" | "blocked" | "modified";

  // For citation-required claims
  citation_provided?: boolean;
  citation_source?: string;

  // For disclaimer-required claims
  disclaimer_attached?: boolean;

  // For blocked claims
  block_reason?: string;
  recovery_hint_provided?: string;
}

Invariants

1. Classification precedes generation. Claim type MUST be determined before authority routing.

2. Domain context is required. Claims cannot be routed without workflow domain.

3. Prohibited is absolute. No hedging language converts a prohibited claim to permitted.

4. Citation is not disclaimer. A source reference satisfies citation; it does not satisfy oracle.

5. Soft authority markers upgrade claim_type. If opinion contains a measurement, it becomes factual.

Relationship to Existing RFCs

The Ontology Builder Extension

Future: The Ontology Builder (RFC-0001 implementation) may generate claim ontologies alongside data ontologies:

{
  "canonical_id": "nutrition/wellness_claims",
  "claim_types": {
    "weight_loss_inference": {
      "claim_type": "inferential",
      "authority_required": "citation",
      "required_citation_types": ["peer_reviewed", "regulatory_body"]
    },
    "dietary_recommendation": {
      "claim_type": "advisory",
      "authority_required": "disclaimer",
      "disclaimer_template": "This is general information, not medical advice."
    }
  }
}

See Also

• SIR Resolution Pattern (RFC-0001 Amendment) — The identity pattern this extends
• Doctrine II: Identity Authority — The constraint CAO implements for claims
• RFC-0004: Anti-Hallucination — Quote binding for citation verification

⸻