Evidence kinds/RuntimeAISpec (the spec)

RuntimeAISpec (the spec)

structural evidence

The closed-enum contract one LLM-in-the-loop feature operates under.

What it is

A RuntimeAISpec declares: specId, displayName, category (classifier/extractor/drafter/router/summariser), inputSchema (closed-enum fields), outputSchema (closed-enum fields), promptTemplate (system + user), modelIdentity (provider/model/version), reviewerGate (closed enum), lowConfidenceThreshold, maxLatencyMs, fallbackBehavior, deterministicDefault.

The spec is the unit of compliance accountability. Each LLM feature gets one (sometimes a few) specs. Changing the spec changes its hash; the chain shows the transition.

Specs are operator-authored TypeScript objects (or equivalent YAML in the SaaS). They're version-controlled in the operator's repo, deployed alongside the feature. The substrate validates the spec format on load.

What it guarantees

  • Closed-enum schema enforcement at runtime.
  • Spec hash commitment on every L12 entry.
  • Cross-implementation byte-stability of spec hashing.
  • Reviewer-gate + fallback-behavior primitives configured per spec.

What it does NOT guarantee

Honest limits. Every primitive has them.

  • That the spec is appropriate for the use case — operator's design.
  • That the operator hasn't introduced semantic ambiguity within an enum value — operator's careful authoring.

Regulations that engage this kind

EU AI Act Art. 11 + Annex IV

Technical documentation

MDR Annex II

Technical documentation

Sectors that rely on this kind

Related evidence kinds

FAQ

Can we share a spec across multiple LLM features?

Each spec covers one feature. If you have multiple variants (different rubrics, different sectors, different reviewer policies), each is a separate spec with its own hash. Sharing a spec across features would defeat the per-feature accountability the substrate is designed for.