RFC-0010: Authorization Envelope

Purpose

Separate proposal generation from authority granting.

Workflow-Level Authoritative Intent

Every workflow MUST declare whether it may emit authoritative envelopes:

interface WorkflowDeclaration {
  workflow_id: string;
  authoritative_intent: "authoritative" | "non_authoritative";
  enforcement_mode: "INLINE" | "ASYNC" | "NON_AUTHORITATIVE_ONLY";
  // ... other workflow config
}

Binding Rules:

If authoritative_intent: "non_authoritative", the runtime MAY permit outputs in narrative mode without oracle checks
If authoritative_intent: "authoritative", the workflow MUST comply with all oracle verification and envelope requirements
enforcement_mode determines how authority is enforced (see RFC-0002 Authority Latency Policy)
Workflows with non_authoritative intent MUST still enforce forbidden markers (soft authority) as defined in Normative Definitions

This creates an explicit "this workflow will never emit authority" declaration, preventing accidental authority escalation.

Envelope (Discriminated Union)

type AuthorizationEnvelope = | { kind: "measurement"; value: number; provenance: Provenance } | { kind: "classification"; label: string; provenance: Provenance } | { kind: "action"; action: string; params?: Record<string, unknown>; provenance: Provenance } | { kind: "narrative"; text: string; policy: NarrativePolicy } | { kind: "refusal"; reason: RefusalReason } | { kind: "dispute_summary"; sources: OracleConflict[] };

Supporting Types

The envelope relies on four supporting types. Implementations MUST define these; the following are normative minimum schemas.

/**
 * Provenance establishes the authoritative basis for a claim.
 * Every authoritative envelope variant MUST include at least one OracleVerificationRecord.
 */
interface Provenance {
  oracle_records: OracleVerificationRecord[]; // At least one required
  derived_from?: string[]; // IDs of upstream envelopes if composed
  generated_at: string; // RFC 3339 timestamp
  envelope_id: string; // Unique identifier for audit
}

/**
 * NarrativePolicy constrains how narrative text may be generated.
 */
interface NarrativePolicy {
  grammar_mode: "attributive" | "hedged" | "educational";
  forbidden_markers: string[]; // Soft-authority markers to reject (see Normative Definitions)
  max_specificity: "general" | "contextualized"; // Prevents smuggling precise claims
  scrub_measurements: boolean; // If true, numeric values with units are stripped
}

/**
 * RefusalReason explains why authorization was denied.
 * It MUST NOT leak control-plane details that enable probing.
 */
interface RefusalReason {
  code:
    | "BLOCKED"
    | "UNRESOLVABLE"
    | "POLICY_VIOLATION"
    | "EMERGENCY_ESCALATION";
  user_message: string; // Safe for display; no oracle/threshold details
  recovery_hint?: string; // Guidance toward a valid request
  audit_id: string; // For internal lookup; opaque to user
}

/**
 * OracleConflict captures disagreement between oracles on the same axis.
 */
interface OracleConflict {
  axis: string;
  oracles: Array<{
    oracle_id: string;
    tier: "primary" | "secondary" | "cross_domain" | "unverified";
    value: unknown;
    verified_at: string;
  }>;
  resolution_attempted: boolean;
  escalation_required: boolean;
}

Client Requirement

Clients must handle each variant explicitly. No .toString() allowed.

Normative client-side handling: • Clients MUST treat unknown kind values as BLOCKED (fail closed). • Clients MUST NOT render or serialize proposal content as if it were an envelope. • Clients MUST ensure authoritative kinds (measurement, classification, action) are only displayed when they are present as explicit envelope variants.

⸻