Skip to content

Verified Completions M1: OpenAI-compatible /v1/chat/completions proxy (annotate + enforce) #84

Closed

Description

@jsam

Why

This is the adoption story: point any existing OpenAI SDK client at InputLayer by changing base_url, and completions keep working while consistency findings appear on the response. Every framework supports a custom base_url, so integration cost is near zero.

What to do

  • POST /v1/chat/completions accepting the standard OpenAI request shape
  • Map OpenAI params to the Anthropic Messages API: model, messages, temperature, top_p, max_tokens (required by Anthropic, default from config), stop, system role to the system param. Ignore unknown fields, log them at debug level
  • Model routing: a model starting with claude- is forwarded as-is, anything else falls back to the configured default
  • Run the completion call and the verification pipeline (from the /v1/verify issue) in parallel. Verification checks the incoming conversation, so it does not need to wait for the completion
  • Attach the inputlayer.consistency block to the response. Clients that ignore unknown fields are unaffected
  • annotate mode (default): findings attached, never blocks, any verification failure returns status: "unverified" and the completion still goes out
  • enforce mode: verify first; if conflicts are found, return HTTP 422 with the findings and skip the completion call entirely
  • Per-request overrides via an optional inputlayer object in the body (mode, conversation id, rule packs), per RFC section 9.1

Done when

Take an existing app using the OpenAI SDK, change only base_url, and: nothing breaks, completions come from Claude, and a self-contradictory conversation produces findings on the response.

Depends on

  • /v1/verify (M0)

Activity

  1. added
    enhancementNew feature or request
    backendBackend/server related
    verified-completionsVerified Completions: OpenAI-compatible endpoint with consistency checking
    on Jul 26, 2026
  2. jsam commented on Aug 21, 2026

    @jsam
    ContributorAuthor

    M0 (#83, PR #105) is done, so this is next up. Delta notes against the checklist now that M0's final shape is known:

    • Ontology selection: M0 settled on mandatory per-request selection (x-il-ontology header or il_ontology body field) from the set published in the registry - the 'rule packs' per-request override in the last checklist item should follow the same contract, not introduce a second mechanism.
    • Auth is now REQUIRED scope for this milestone, not hardening: /v1/verify could stay unauthenticated behind Caddy, but a chat proxy spends the operator's model budget on every request. Minimum: a GATEWAY_API_KEY bearer check.
    • Two small enablers worth doing first (both feed the getting-started tutorial's next chapter):
      1. Opt-in trace surface on the verify pipeline (e.g. X-IL-Trace header) returning extracted claims, mapped statements, and timings - makes the translation step observable.
      2. il chat: terminal chat subcommand against the gateway showing per-turn findings and the trace panel.
    • The completion-verification parallelism note holds, with one wrinkle from M0: verification is of the INCOMING conversation only in annotate mode; verifying the model's own output (origin="output" claims, which the pack's origin-gated constraint rules already handle - proven live in M0 testing) requires a second verify after the completion returns, or folding it into M2 sessions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    backendBackend/server relatedenhancementNew feature or requestverified-completionsVerified Completions: OpenAI-compatible endpoint with consistency checking

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions