Opaque Boundary

RFC-0008: Opaque Boundary

Purpose

Ensure control-plane isolation between proposal generation and authority evaluation.

Principle

Authority logic is not visible to — and therefore not gameable by — the LLM.

This is the structural invariant that separates CAA from prompt-based safety systems. When authority rules are exposed to the simulator, the system becomes a negotiation. When they are opaque, it becomes a gate.

What the Simulator Cannot See

The LLM operates without knowledge of: • Which state dimensions are required for authorization • Which oracles are consulted for verification • Which conflicts trigger escalation or dispute resolution • Which outputs are classified as authoritative vs. narrative • Which thresholds or conditions govern authorization decisions

The model cannot "try again differently" to win. It either meets reality — or it doesn't.

Control-Plane Isolation

This is not security by obscurity. It is architectural separation of concerns — the same principle used in: • OS kernel/user-space separation • Hardware privilege rings • Financial transaction authorization systems • Safety PLCs in industrial control systems

In each case, the untrusted layer (user-space, application code, transaction request, control signal) cannot observe or influence the logic that governs whether its request is permitted.

Structural Consequences • The model cannot learn boundary conditions from refusals • The model cannot optimize phrasing to pass filters • The model cannot smuggle assumptions through inferred state • Jailbreaks fail by default — there is nothing to learn, adapt to, or exploit

Side-Channel & Boundary Leakage (Mandatory)

The opacity boundary can be undermined by side-channels (error detail, timing, structured traces, or differential behavior). Mitigations are mandatory, not advisory.

•	Refusal and dispute responses MUST NOT reveal which specific check failed (e.g., which oracle was consulted, which threshold triggered) beyond what is required for user recovery.
•	Systems MUST normalize error response structure across all failure paths. A `BLOCKED` response for missing state MUST be indistinguishable in shape from a `BLOCKED` response for policy violation.
•	Systems MUST prevent response-time correlation with authorization paths. If oracle latency varies, responses MUST be padded to a consistent floor and measured against a published threshold.
•	The simulator MUST NOT receive privileged control-plane artifacts (e.g., internal policy graphs, oracle registries, conflict configs) in a form it can condition on.
•	Logging and telemetry channels MUST be isolated from model context. Traces written for observability MUST NOT be readable by the simulator in subsequent turns.

Measurable Side-Channel Requirements

interface SideChannelMitigation {
  timing: {
    // Response time MUST NOT correlate with authorization path.
    min_response_ms: number; // Floor for all responses (e.g., 200)
    max_variance_ms: number; // Jitter budget across paths (e.g., 50)
    measurement_requirement: string; // e.g., "p99 variance < 50ms across authorization paths"
  };
  error_structure: {
    // Error responses MUST be structurally indistinguishable across failure paths.
    schema_hash: string; // Hash of the error-response schema
    field_count_invariant: boolean; // Same fields regardless of failure type
    content_length_normalized: boolean; // Pad to consistent length class
  };
  validation: {
    timing_audit_frequency: "monthly" | "quarterly";
    differential_response_test: "on_release" | "monthly";
    penetration_test_scope: Array<"timing" | "error_content" | "response_size">;
  };
}

Risk-Tiered Opacity Profiles

Full timing normalization may harm UX and cost in low-stakes domains. Implementations MAY use risk-tiered profiles:

Workflow-level configuration:

interface OpacityProfile {
  tier: "high" | "medium" | "low";
  timing_floor_ms?: number; // Required for high tier
  error_padding_enabled: boolean;
  rationale: string; // Audit log: why this tier was chosen
}

Warning: The tier MUST be determined by domain risk, not performance convenience. A financial workflow claiming "low" tier to avoid latency is non-compliant.

RFC-0007 Amendment: Constraint by Elimination

Status: Normative Applies to: All high-sensitivity domains

Models are not coerced by explanation. They are constrained by elimination.

Foundational Observation

Language models do not converge toward correctness through explanation. They converge through search-space reduction. Increasing prompt length, context, or retrieval expands the model's available completion space. Correctness degrades as optionality increases.

Rule (Normative)

In state-sensitive or high-risk domains, systems MUST NOT attempt to improve correctness by:

• adding explanatory prompt text,
• expanding contextual retrieval (RAG),
• reiterating instructions,
• or negotiating with the model.

Instead, systems MUST enforce correctness by eliminating degrees of freedom available to the simulator.

Required Enforcement Mechanisms

1. Single-Step Authority Gates The simulator MUST receive at most one opportunity to propose content for any authoritative operation. Re-prompting is prohibited.

2. Binary State Resolution Every required state axis MUST resolve to exactly one of:

   • verified (explicit or oracle-confirmed), or
   • absent (explicit terminal envelope).

   Partial satisfaction is forbidden.

3. No Iterative Clarification via Prompting Clarification MUST occur through:

   • REQUIRES_SPECIFICATION envelopes, or
   • explicit user input,

   never by reformulating prompts to the simulator.

4. Elimination Over Instruction If a value is unsafe, ambiguous, inferred, or unverifiable, the system MUST remove it from the simulator's available action space rather than instructing the simulator not to use it.

5. RAG Restriction (High-Risk Domains) Retrieval-augmented generation MUST NOT be used to satisfy required state or to justify authoritative outputs. Retrieved content MAY inform narrative explanations only after authorization is denied or deferred.

Implementation Heuristic

Increase certainty by adding telemetry; increase safety by removing model degrees of freedom.

Alignment with Related RFCs

Rationale (Non-Normative)

Language models optimize for plausibility across large token spaces. Increasing prompt length or context increases the probability of selective compliance ("token cherry-picking"). Deterministic safety requires reducing the simulator's choice set, not negotiating within it.

⸻