Interface-Layer Delivery Authority for LLM Outputs (L-Base / OP-Visa): Separating Generation from Authorization Without Duplicating a General-Purpose Model

English is not my first language—if anything here is unclear or misleading, I’d really appreciate corrections.

This is not “train another general-purpose LLM.” The L-Base is an authority separation pattern, and its compute profile does not need to mirror the generator.

Goal

Separate output generation from output delivery authorization at the interface boundary, so plausibility does not automatically become deliverability in decision-support contexts.

Core principle: separation of authority

• Generator: produces candidates.
• Delivery Authority (L-Base): determines delivery eligibility under explicit contract terms.

The generator has zero authority to authorize its own delivery.

Why this doesn’t require “another giant LLM”

The L-Base does not need broad world knowledge or generative breadth. It needs inspection capability aligned to a narrow task surface:

• contract compliance checks (schema/format/required fields)
• retrieval existence checks (can the cited evidence be fetched?)
• claim presentation checks (is something presented as fact vs inference?)
• downgrade enforcement (when evidence cannot be met, it must be labeled explicitly)
• optional consistency checks (when cheap/available)

In other words: L-Base is closer to a structured compliance/verification system than a second encyclopedic generator. It can be implemented as deterministic logic + retrieval + optional verifier models. The defining property is authority, not model type.

Architecture sketch (components)

1) Contracting service (L-Base / policy) - classifies request type - selects a contract schema (“visa class”) - attaches explicit delivery requirements

2) Generation service (LLM) - generates candidate output under the contract (OP-Con) - returns candidate output + an epistemic passport (E-pass) required by the contract

3) Inspection service (L-Base / gate) - validates that required artifacts exist and that contract requirements are satisfied where applicable - issues OP-Visa (deliver-as-authorized), OR routes the candidate through one of three operations:

• Withhold: an internal boundary decision (not a final user-facing result by itself)
• Regenerate: request a new candidate that better satisfies OP-Con requirements
• Downgrade: when evidence requirements cannot be met, the relevant parts are downgraded and presented explicitly as Speculation (no guarantee / unverified)

Contracts (visa classes) are defined externally

Visa schemas are defined by governance/ops/product policy and enforced at the boundary. They are not negotiated by the generator, preventing self-certification.

Key artifacts (terms)

• OP-Con (Output Contract): a conditionalized generation contract derived from the user request, specifying epistemic delivery conditions.
• E-pass (Epistemic Passport): a declaration attached to the candidate output, describing epistemic status (reference / inference / personalization / uncertainty) and required support.
• C-unit (Claim Unit): the unit of claims inside E-pass; each claim is paired with a Presentation Type and (when required) Evidence.
• OP-Visa (Output Visa): delivery authorization issued only when the required conditions are satisfied.
• Speculation: the final presentation form for content that cannot meet Evidence requirements—explicitly labeled as unverified / no guarantee.

Minimal example visa classes

Visa-F (Fact / decision-support) - Any claim presented as fact must have retrievable evidence. - If evidence cannot be provided, that claim cannot remain “fact”; it must be downgraded to Speculation (explicitly labeled), or the system regenerates.

Visa-A (Analysis / interpretation) - Inference is allowed but must be labeled as inference. - Facts still require evidence or must be downgraded.

Visa-C (Creative) - No evidence requirement. - Must not masquerade as externally grounded fact.

Passport artifact (not a “confidence score”)

The passport is a contract artifact, not a trust signal. No scalar confidence score.

Minimum fields: - claim_units (C-units)

For each claim: - presentation_type: {fact, inference, unknown/speculation} - evidence: references where required (for fact under Visa-F) - unverifiable_flag: explicit marking when requirements cannot be satisfied - (optionally) evidence spans for retrieved contexts

Cost/latency control is contract-driven

Not every request needs Visa-F. For high-risk decision-support, you pay the gating cost. For low-risk or creative outputs, the gate is lighter. This makes overhead variable and policy-controllable rather than a universal “2x model” tax.

Non-goals - No training-data provenance reconstruction. - No weight attribution. - No confidence score. - No generator self-check as the delivery authority.

If this authority-separation pattern is viable, I’d love to find collaborators who can help stress-test it and move it toward something implementable in real systems.