LLM Orchestration Interface

The LLM orchestration interface is a provider-agnostic way to ask a model for S010-compatible AML content while preserving the analyst-gated runner boundary.

It is intentionally narrow. It does not try to solve every local deployment question. It provides a standard handoff point between model output and TCAML validation.

Provider-agnostic model#

The public interface supports two basic provider concepts:

This keeps the public framework independent from a specific model vendor, local desktop tool or deployment stack.

Orchestration pipeline#

The orchestrator should perform only the content drafting and validation loop:

prompt + AML knowledge
→ provider draft response
→ LLM-to-S010 bridge parser
→ schema / safety validation
→ correction retry or safety stop
→ validated S010 content file
→ analyst-interactive runner

It should not run the case to completion. It should not confirm gates. It should not call auto-confirm for LLM-generated drafts.

Why mock mode matters#

Mock mode allows the full chain to be tested before a real model is connected:

prepared model-like response
→ parser
→ schema validation
→ correction loop
→ validated content

This is useful for repository tests and for proving that the safety boundary works without relying on a stochastic model response.

Real model behaviour#

A real model may behave differently from a mock response. It may:

• wrap JSON in explanatory text;
• use a wrong enum value;
• invent an extra field;
• truncate output because of token limits;
• omit required fields;
• produce a final-looking decision that must be blocked.

When connecting a real local model, run the same prompt several times and inspect correction prompts, failed attempts and validated outputs. This gives a practical measure of how often the model produces valid S010 content on the first attempt.

Local deployment considerations#

A production local AML node may later add:

• model role profiles;
• local vision or document extraction models;
• approved source connectors;
• browser evidence capture;
• PDF or spreadsheet reporting;
• policy-specific thresholds;
• private implementation profiles;
• local monitoring and access controls.

Those items belong to deployment-specific configuration. The public framework defines the neutral interface and safety boundary.

Boundary summary#

Model = drafts content
Bridge = validates and blocks safety violations
Runner = controls workflow gates
AML analyst = confirms gates and decides next action

The model can support AML operations. It must not replace controlled review.