# Telynt Agentic and LLM Technology Baseline

This reference describes shared runtime and protocol support. Capability activation is controlled by installed packages and their environment lock; a supported speech, retrieval or multimodal runtime does not automatically install its business workflow. Package-specific taxonomies, datasets and outcome measures are documented by their owning packages. Authoring procedures are documented under [Developers](/documentation/developers).

## Purpose

This document defines the implemented technology baseline used by Telynt’s agentic and language-model platform. It records which standards and technologies form the common product core, which implementation is the default for a deployment profile, which alternatives are production-qualified adapters, and which advanced capabilities are enabled only after workload-specific qualification.

Telynt incorporates mature emerging technology without coupling the product to a collection of competing frameworks. Protocols define stable boundaries; Telynt owns the evidence, policy, package, workflow, audit, and evaluation contracts; runtimes and authoring frameworks remain replaceable adapters.

The exact container image, source revision, artifact digest, model revision, tokenizer, prompt, schema, policy, adapter, and compatibility result used by a run are immutable parts of its deployment record. “Latest” never means an unreviewed rolling dependency.

## Technology Qualification Classes

| Class | Meaning in Telynt |
|---|---|
| `CORE` | Required common contract or service in every applicable installation |
| `DEFAULT` | Standard implementation selected for a deployment profile |
| `VALIDATED_ADAPTER` | Shipped adapter activated only on its tested software, model, and hardware matrix |
| `ADVANCED_PROFILE` | Proven capability activated when scale, confidentiality, or workload justifies its added complexity |
| `GATED_CAPABILITY` | Implemented capability kept behind explicit evaluation, policy, and compatibility gates |
| `MIGRATION_COMPATIBILITY` | Import or transition support; not accepted as a second architectural source of truth |

A technology does not enter `CORE` solely because it is new or popular. It enters the core only when its responsibility is distinct, its operating behavior is understood, and it strengthens the common architecture.

## Coherent Ecosystem Architecture

```text
Telynt web application
        │
        │ AG-UI stable event subset
        ▼
UI and streaming gateway
        │
        ▼
Canonical Telynt agent contracts
        │
        ├──────── A2A 1.0 ─────── Independently deployed customer/partner agents
        │
        ├──────── MCP ──────────── Registered tools, resources, prompts and long operations
        │
        ├──────── Temporal ─────── Durable workflows, timers, retries and approvals
        │
        ├──────── Model router ─── Vendor-neutral inference task contract
        │             │
        │             ├── vLLM / SGLang / TensorRT-LLM
        │             ├── llama.cpp / OpenVINO / ONNX Runtime
        │             └── llm-d / KServe cluster profiles
        │
        ├──────── Evidence layer ─ Hybrid, late-interaction, graph,
        │                          hierarchical and visual retrieval
        │
        ├──────── Tool gateway ─── SPIFFE + OpenFGA + OPA enforcement
        │
        └──────── Event backbone ─ CloudEvents + AsyncAPI

Cross-cutting:
OCI artifacts, Sigstore, in-toto/SLSA, SPDX,
OpenTelemetry, immutable audit, evaluation and red teaming
```

The architecture enforces the following ownership rules:

- **Temporal owns durable execution state.** Framework checkpoints, A2A tasks, MCP tasks, UI sessions, and event deliveries never replace the canonical workflow state.
- **MCP owns tool and context interoperability.** It does not implement internal peer-agent delegation.
- **A2A owns interoperability with independently deployed agents.** Internal native-agent handoffs remain typed Telynt artifacts within a Temporal workflow.
- **AG-UI owns application-to-agent streaming.** It does not act as an event bus, audit store, or workflow engine.
- **CloudEvents owns the transport-neutral event envelope.** AsyncAPI documents channels and payload contracts; the broker supplies delivery behavior.
- **OpenAPI owns synchronous control and administration APIs.** It is not used as an agent protocol.
- **The inference gateway owns the stable model contract.** Engine-specific APIs never leak into agent packages.
- **OPA and OpenFGA own deterministic authorization.** No language model grants authority.
- **The Telynt evidence layer owns factual provenance.** Framework memory and model context never become the system of record.
- **OpenTelemetry owns operational telemetry.** The append-only audit ledger remains the authoritative compliance record.

## Implemented Core Standards and Services

| Technology | Qualified baseline | Telynt responsibility | Class |
|---|---:|---|---|
| [Model Context Protocol](https://modelcontextprotocol.io/specification/2026-07-28) | 2026-07-28 | Tool, resource, prompt, skill, application, and long-operation interoperability | `CORE` |
| [A2A Protocol](https://a2a-protocol.org/latest/specification/) | Wire specification 1.0.0 | Independently deployed agent discovery, messaging, tasks, artifacts, streaming, and authorization | `CORE` |
| [AG-UI](https://docs.ag-ui.com/) | Upstream release 2026-05-26; `telynt-agui-core.v1` | Version-pinned application-to-agent event streaming | `VALIDATED_ADAPTER` |
| [Temporal](https://docs.temporal.io/) | Server 1.31 qualified line | Durable workflows, retries, timers, cancellation, compensation, and human approval waits | `CORE` |
| [CloudEvents](https://github.com/cloudevents/spec/releases/tag/ce%40v1.0.2) | 1.0.2 | Transport-neutral event envelope | `CORE` |
| [AsyncAPI](https://www.asyncapi.com/docs/reference/specification/v3.1.0) | 3.1.0 | Event-channel and payload catalogue | `CORE` |
| [OpenAPI](https://spec.openapis.org/oas/latest.html) | 3.2.0 | Synchronous product and control-plane APIs | `CORE` |
| [JSON Schema](https://json-schema.org/draft/2020-12) | 2020-12 | Input, output, tool, event, and package schema validation | `CORE` |
| [Protocol Buffers](https://protobuf.dev/programming-guides/proto3/) and gRPC | Proto3 | Efficient internal synchronous service contracts | `CORE` |
| [OpenTelemetry](https://opentelemetry.io/docs/specs/semconv/) | Semantic Conventions 1.44 qualified profile | Cross-service traces, metrics, and logs | `CORE` |
| [W3C Trace Context](https://www.w3.org/TR/trace-context/) | Recommendation | Cross-boundary trace propagation | `CORE` |
| [SPIFFE/SPIRE](https://spiffe.io/docs/latest/spiffe-about/overview/) | Qualified release line | Workload identity, attestation, and short-lived X.509-SVIDs | `CORE` |
| [OpenFGA](https://openfga.dev/docs/concepts) | Qualified release line | Object-relationship and task-bound authorization | `CORE` |
| [Open Policy Agent](https://www.openpolicyagent.org/docs) | Qualified release line | Contextual policy decisions and admission/action control | `CORE` |
| [OCI Distribution](https://github.com/opencontainers/distribution-spec) | Distribution and artifact 1.1 contracts | Portable model, agent, tool, prompt, and evaluation artifacts | `CORE` |
| [Sigstore/cosign](https://docs.sigstore.dev/cosign/verifying/verify/) | Qualified release line | Artifact signature and identity verification | `CORE` |
| [in-toto](https://github.com/in-toto/attestation/tree/main/spec) and [SLSA](https://slsa.dev/spec/v1.2/) | Attestations; SLSA 1.2 | Verifiable build provenance and promotion evidence | `CORE` |
| [SPDX](https://spdx.dev/use/specifications/) | SPDX 3 profiles | Canonical software, AI, data, and build bill of materials | `CORE` |

The qualified versions are pinned by immutable image or artifact digest. Upgrade qualification runs compatibility, safety, leakage, quality, performance, rollback, and disaster-recovery tests before promotion.

## Agent and Application Protocols

### Model Context Protocol

Telynt exposes and consumes MCP through a policy-wrapped MCP gateway. The implementation supports the 2026-07-28 protocol capabilities used by the product:

- resources for policy-scoped context;
- tools for declared read, derive, draft, approved-write, and restricted operations;
- prompts as signed and versioned templates, never as a source of authority;
- elicitation for typed user input;
- tasks for protocol-level handles to long-running tool work;
- Skills over MCP for capability discovery;
- MCP Apps for sandboxed, tool-owned interface elements.

MCP Tasks provide an external operation handle; the underlying work remains a Temporal workflow. Skills over MCP supplement discovery but do not replace a signed `AgentPackage`. MCP Apps are isolated widgets; the principal application experience remains AG-UI.

Every MCP server is registered, version-pinned, signed or explicitly allowlisted, tenant-scoped, and reached through the tool gateway. Tool descriptions, arguments, resource content, prompts, and results are all treated as untrusted inputs. Schema validation, taint propagation, authorization, output inspection, rate limits, and audit apply at every call.

### A2A Protocol

Telynt uses A2A 1.0 when an agent is independently deployed, separately administered, or externally owned. Native agents in the same Telynt trust and deployment boundary use canonical internal contracts instead.

The A2A gateway implements:

- signed and allowlisted Agent Cards;
- declared skills and capabilities;
- messages, tasks, artifacts, streaming, and asynchronous completion;
- JSON-RPC, HTTP/JSON, or gRPC bindings selected by the integration profile;
- OAuth 2.0/OIDC or mutual TLS;
- in-task authorization where the remote operation requires additional consent;
- tenant-scoped task identifiers;
- protected push-notification endpoints;
- recipient, destination, size, type, and retention controls.

A2A artifacts enter the same evidence, schema, malware, policy, provenance, and human-review gates as local results. Remote agent statements do not inherit trust from the remote agent’s identity alone.

### AG-UI

Telynt pins the AG-UI upstream release dated 2026-05-26 by source and package digest and exposes the named compatibility profile `telynt-agui-core.v1` between the product interface and UI gateway.

The profile includes:

- lifecycle: `RUN_STARTED`, `RUN_FINISHED`, `RUN_ERROR`, `STEP_STARTED`, and `STEP_FINISHED`;
- assistant text: `TEXT_MESSAGE_START`, `TEXT_MESSAGE_CONTENT`, and `TEXT_MESSAGE_END`;
- permission-filtered tool activity: `TOOL_CALL_START`, `TOOL_CALL_ARGS`, `TOOL_CALL_END`, and `TOOL_CALL_RESULT`;
- state: `STATE_SNAPSHOT`, `STATE_DELTA`, and `MESSAGES_SNAPSHOT`;
- structured progress: `ACTIVITY_SNAPSHOT` and `ACTIVITY_DELTA`;
- allowlisted `CUSTOM` events in the `telynt.*` namespace for interrupt, cancellation, approval request, and approval resolution.

`RAW`, reasoning-message, encrypted-reasoning, and every upstream draft event are excluded. Reasoning is represented only as curated `ACTIVITY_*` summaries without private chain-of-thought.

Server-Sent Events are the default transport. WebSocket is enabled only for interactive steering or live voice flows that require bidirectional low latency. The gateway never exposes hidden prompts, credentials, unauthorized tool arguments/results, or unrestricted evidence.

An upstream AG-UI change reaches the profile only after event-schema, ordering, reconnection, redaction, accessibility, cancellation, approval, and security conformance tests pass. Changing the upstream revision or the Telynt profile creates a new immutable compatibility record.

### Events and Synchronous APIs

Every internal domain or platform event published to the Kafka-compatible event backbone uses a CloudEvents 1.0.2 envelope and an AsyncAPI 3.1.0 channel definition. Payloads use versioned JSON Schema 2020-12 contracts. Headers contain routing and correlation metadata, not literal meeting or document content. AG-UI events, A2A messages/tasks, MCP traffic, Temporal history, and synchronous RPC retain their native protocol envelopes and are correlated rather than wrapped as CloudEvents.

OpenAPI 3.2.0 describes synchronous application, registry, evaluation, deployment, review, and administrative operations. Internal high-volume RPC uses gRPC and Protocol Buffers. Contract generation and consumer-driven compatibility tests prevent schema drift across all three forms.

## Durable Agent Runtime

Temporal is the orchestrator of record. Each agent invocation maps to a durable workflow; model calls, tool calls, verification, external-agent calls, and artifact operations execute as idempotent Activities.

Temporal owns:

- workflow identity and durable state;
- activity retries and timeouts;
- timers, schedules, and delayed follow-up;
- cancellation and policy-revocation propagation;
- signals and updates;
- human-approval waits;
- compensation for partially completed workflows;
- replay after worker or infrastructure failure;
- workflow versioning.

At-least-once Activity execution is safe because every side effect carries an idempotency key and uses prepare–authorize–commit semantics. Non-deterministic values are obtained through Activities and recorded in workflow history. Large evidence objects remain in encrypted object storage and are referenced by immutable IDs rather than embedded in workflow histories.

MCP Tasks, A2A tasks, UI sessions, queue messages, and framework-native checkpoint IDs are recorded as correlated external handles. None becomes the authoritative state.

## Agent Authoring Adapters

Telynt ships a framework-neutral native SDK and qualified adapters for widely adopted agent frameworks. Every adapter compiles or translates native concepts into:

- `AgentInvocation`;
- `AgentEvent`;
- `AgentResult`;
- `EvidenceReference`;
- `ToolCall`;
- `ApprovalRequest`;
- `AgentError`;
- `AgentPackage` manifest declarations.

| Adapter | Qualified line at baseline | Implemented use | Class |
|---|---:|---|---|
| Telynt native SDK | Agent contract v1 | First-party agents and maximum control | `DEFAULT` |
| Telynt language-neutral contract adapter | Agent contract v1 | Customer runtimes packaged behind canonical gRPC, HTTP, MCP, or A2A boundaries | `CORE` |
| [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/) | Python 0.19 qualified line | Python authoring with tools, handoffs, guardrails, sessions, human approval, MCP, and tracing | `VALIDATED_ADAPTER` |
| [Google Agent Development Kit](https://adk.dev/) | Python 2.6 qualified line | Portable customer agents and multi-language integration | `VALIDATED_ADAPTER` |
| [Microsoft Agent Framework](https://learn.microsoft.com/en-us/agent-framework/) | Python 1.13 and .NET 1.17 qualified lines | Enterprise Python/.NET agents and A2A integration | `VALIDATED_ADAPTER` |
| [LangGraph](https://docs.langchain.com/oss/python/langgraph/overview) | 1.2 qualified line | Graph-shaped customer-agent implementations and local checkpoints | `VALIDATED_ADAPTER` |
| Semantic Kernel / AutoGen | Import and migration profiles | Migration into Microsoft Agent Framework or the native contract | `MIGRATION_COMPATIBILITY` |

Framework sessions, memory, checkpoints, handoffs, tools, and guardrails remain subordinate implementation details. An adapter cannot bypass Temporal, the tool gateway, policy enforcement, the evidence model, evaluation gates, or immutable audit.

Adapters execute in isolated workers with pinned dependencies. Framework-native telemetry is normalized into the Telynt OpenTelemetry profile. Direct backend credentials and unrestricted native tools are disabled.

Agents authored with PydanticAI, CrewAI, LlamaIndex Workflows, or another customer-selected framework enter through the language-neutral contract adapter or A2A boundary. They are admitted as customer packages only after the same conformance, isolation, and evaluation gates; their framework does not become a platform dependency merely because an extension uses it.

## Package and Software Supply Chain

### OCI Artifact Model

`ExtensionPackage` has exactly two concrete variants: `ModelPackage` and `AgentPackage`. Both are stored as OCI 1.1 artifacts in a private registry. Tools, prompts, policies, skills, taxonomies, schemas, and evaluation suites are supporting OCI artifacts referenced or bundled by those packages; they are not additional `ExtensionPackage` variants. The manifest links:

- executable image or WASM component;
- weights, tokenizer, templates, and quantization metadata;
- input and output schemas;
- tool and permission declarations;
- SPDX bill of materials;
- vulnerability and license results;
- evaluation attestations;
- SLSA provenance;
- publisher signature;
- compatibility matrix;
- immutable digests for every referenced layer.

ORAS is the supported client and transport adapter; OCI Distribution is the actual platform contract. Runtime Internet downloads, floating tags, arbitrary remote code, and unregistered dependencies are disabled.

### Signing, Provenance, and Promotion

Cosign verifies artifact signatures before registration, promotion, loading, and execution. Private and air-gapped installations use tenant or Effority KMS-backed keys and, where required, a private transparency service. Confidential package metadata is never submitted to a public transparency log.

Effority production packages carry in-toto attestations and SLSA 1.2 Build Level 3 provenance: isolated and ephemeral builds, non-falsifiable provenance, and auditable source-to-artifact relationships. Customer packages enter quarantine until signature, provenance, bill of materials, vulnerability, policy, and evaluation requirements pass.

SPDX 3 is the canonical bill of materials. CycloneDX ML-BOM is accepted through an import/export adapter and normalized to the canonical package record.

## Identity and Deterministic Authorization

### Workload Identity

SPIRE attests every service, agent runner, tool runner, connector, and inference worker and issues short-lived SPIFFE X.509-SVIDs. Mutual TLS authenticates service-to-service traffic. JWT-SVID is limited to integrations that cannot use X.509 because bearer tokens carry greater replay risk.

Workload identity proves which component is calling. It does not grant data access by itself.

### Relationship and Context Policy

OpenFGA models durable relationships among tenant, principal, role, package, agent and run, plus object types registered by installed data-model packages. Domain types such as project, meeting, report and case belong to those packages. A run receives a task-bound grant scoped to its declared purpose and objects.

OPA/Rego evaluates contextual policy, including:

- participant acceptance and processing eligibility;
- tenant, purpose, source, object, and recipient;
- agent and tool manifest;
- workload identity and task grant;
- data sensitivity, provenance, and trust label;
- jurisdiction and deployment profile;
- action risk and required approval;
- time, policy epoch, retention, and extraordinary access.

The reference monitor requires both the OpenFGA relationship result and the OPA policy decision. Cedar is available as a validated adapter for customer environments standardized on Cedar; it maps into the same policy-decision contract and does not operate as a simultaneous second source of truth.

### Authority Invariant

> All model outputs, agent plans, framework handoffs, and tool arguments are untrusted proposals. Only the deterministic policy enforcement point grants an action after correlating the user, workload, agent, task, tenant, object relationship, policy, data provenance, risk, and approval. Authority is never inferred from natural language.

## Isolation Profiles

| Profile | Technology | Implemented placement | Trade-off |
|---|---|---|---|
| Container service | Kubernetes/container runtime with seccomp, AppArmor/SELinux, read-only root, capabilities dropped, and NetworkPolicy | Trusted first-party stateless services | Lowest overhead; smaller isolation boundary |
| Untrusted OCI extension | [gVisor](https://gvisor.dev/docs/architecture_guide/intro/) | Default customer and third-party agent/tool workers | Strong application-kernel boundary; syscall and I/O overhead |
| Portable deterministic tool | [Wasmtime](https://docs.wasmtime.dev/security.html) with WASI Component Model | Small tools, transforms, validators, and policy-safe plugins | Capability-oriented and fast; not a full Python/CUDA environment |
| High-assurance extension | [Kata Containers](https://katacontainers.io/) with [Firecracker](https://firecracker-microvm.github.io/) runner profile | High-risk code and strict customer isolation | MicroVM boundary; higher cold start, memory, and operations cost |
| Confidential workload | [Confidential Containers](https://confidentialcontainers.org/) | TEE-backed customer models or data on third-party infrastructure | Hardware and attestation constraints |

Wasmtime workers receive no ambient filesystem, network, clock, randomness, or secret capability. Required imports are explicitly declared. The qualified production ABI supports the stable WASI 0.3 lane and retains a pinned WASI 0.2 compatibility lane for packages whose toolchains have not completed migration.

Confidential Containers is installed only in the confidential-computing profile. Key release requires verified hardware and workload attestation. It is not represented as a universal guarantee on unsupported infrastructure.

## Vendor-Neutral Model Runtime Contract

The inference gateway exposes stable, versioned task contracts and advertises a capability record rather than an engine identity:

```yaml
RuntimeCapabilities:
  interfaces:
    - chat
    - responses
    - embeddings
    - reranking
    - multimodal
  generation:
    - structured_json
    - grammar
    - tool_calls
    - logprobs
  cache:
    - prefix_cache
    - cache_salt
    - kv_offload
  optimization:
    - speculative_decoding
    - disaggregated_prefill_decode
    - continuous_batching
  adaptation:
    - lora
    - multi_lora
    - quantization_formats
  parallelism:
    - tensor_parallel
    - data_parallel
    - expert_parallel
```

Every `ModelDeployment` pins:

- engine image and digest;
- model and tokenizer revision;
- chat or multimodal template;
- quantization and KV-cache format;
- attention and grammar backend;
- LoRA adapter and version;
- tensor, data, pipeline, and expert parallelism;
- cache configuration and isolation domain;
- supported modalities and limits;
- evaluated hardware and driver matrix.

Agents request a task capability and SLA; they never select an engine-specific endpoint.

## LLM and Model Runtime Matrix

| Technology | Exact Telynt role | Class |
|---|---|---|
| [vLLM](https://docs.vllm.ai/) | Default high-throughput local LLM/VLM server with continuous batching, paged KV memory, structured outputs, prefix caching, quantization, LoRA, and speculative decoding | `DEFAULT` GPU server |
| [SGLang](https://docs.sglang.io/) | Alternative for extensive shared prefixes, branching programs, multi-LoRA, and model/hardware combinations where RadixAttention wins the qualified workload benchmark | `VALIDATED_ADAPTER` |
| [TensorRT-LLM](https://nvidia.github.io/TensorRT-LLM/latest/index.html) | NVIDIA Hopper/Blackwell profile with FP8/FP4, KV reuse/offload, EAGLE/MTP speculation, tensor/expert parallelism, multimodal batching, and prefill/decode disaggregation | `VALIDATED_ADAPTER` |
| [llama.cpp](https://github.com/ggml-org/llama.cpp) and [GGUF](https://github.com/ggml-org/ggml/blob/master/docs/gguf.md) | CPU, Apple Silicon, workstation, appliance, and constrained air-gapped serving with continuous batching, GBNF/JSON constraints, embeddings, reranking, and speculation | `VALIDATED_ADAPTER` |
| [OpenVINO GenAI](https://github.com/openvinotoolkit/openvino.genai) | LLM, VLM, Whisper, embedding, and reranking on Intel CPU, GPU, and NPU | `VALIDATED_ADAPTER` |
| [ONNX Runtime GenAI](https://github.com/microsoft/onnxruntime-genai) | Windows, DirectML, QNN, ARM, C#/Java/C++ and on-device generation; conventional classifiers and encoders use ONNX Runtime | `VALIDATED_ADAPTER` |
| [FlashAttention](https://github.com/Dao-AILab/flash-attention) and [FlashInfer](https://github.com/flashinfer-ai/flashinfer) | Runtime-selected kernels for prefill, decode, paged KV, long context, MoE, FP8, and FP4 | `VALIDATED_ADAPTER` |
| [llm-d](https://github.com/llm-d/llm-d) | Large distributed LLM profile with cache-aware routing, tiered KV, disaggregated prefill/decode, flow control, and wide expert parallelism | `ADVANCED_PROFILE` |

vLLM remains the architectural default. Alternative engines are selected only when the same Telynt workload, model, quality, and isolation tests demonstrate a profile advantage. No runtime becomes a second inference gateway.

ONNX Runtime GenAI speculative decoding and llama.cpp audio multimodality are not baseline capabilities because their upstream status is not production-stable. Telynt does not advertise them in the corresponding capability records.

## Constrained and Structured Generation

[XGrammar](https://github.com/mlc-ai/xgrammar) is the preferred constrained-decoding backend where the qualified runtime supports it. vLLM, SGLang, TensorRT-LLM, and OpenVINO use the compatible integration. llama.cpp uses its native GBNF and JSON-Schema compiler; ONNX Runtime GenAI uses its native grammar layer.

Implemented controls:

1. Every agent output targets a versioned Telynt JSON-Schema subset.
2. Grammars compile and warm before deployment receives traffic.
3. Unsupported schema constructs fail package admission.
4. Constrained decoding guarantees syntax, not correctness.
5. Schema validation, evidence existence, entailment, authorization, taxonomy, date, recipient, and business-rule validation still run after decoding.
6. The repair attempt is used only for semantic validation failures.
7. XGrammar dynamic structured generation remains a gated capability; stable fixed schemas are the normal production path.

## Inference Optimization Profiles

### Prefix and KV Caching

Automatic prefix caching is enabled for repeated policies, schemas, evidence packages, and authorized multi-turn sessions. Each cache identity includes:

- tenant encryption and trust domain;
- purpose, policy decision epoch, and sensitivity;
- model, tokenizer, template, and engine versions;
- prompt, taxonomy, and schema versions;
- LoRA adapter ID and version;
- modality content hashes;
- retrieved evidence-set hash;
- opaque per-domain cache salt.

Cross-tenant KV reuse and unsalted shared caching are prohibited. Cached states inherit source encryption, retention, deletion, and residency policy. GPU-to-CPU or NVMe KV offload, hierarchical cache, and cache-aware routing are enabled in the advanced cluster profile.

Semantic answer caching is restricted to non-sensitive, deterministic, policy-equivalent requests and never bypasses retrieval authorization or citation regeneration.

### Speculative Decoding

Runtime-native draft-model, EAGLE/MTP, and training-free n-gram or suffix speculation are implemented as gated capabilities. A model/profile pair enables speculation only when representative traces improve p95 latency or throughput without degrading structured output, evidence quality, or cancellation behavior.

The router records proposed tokens, acceptance rate, effective speedup, memory cost, and fallback reason. Ordinary decoding is the deterministic operational fallback.

### Quantization

The registry stores separately evaluated variants rather than treating quantization as format conversion:

| Deployment | Qualified variant family |
|---|---|
| Accuracy reference | BF16 or FP16 |
| NVIDIA Hopper/Ada | FP8 W8A8 and separately qualified FP8 KV cache |
| NVIDIA Blackwell | FP8 or NVFP4/FP4 after task-level approval |
| Memory-constrained GPU | AWQ/GPTQ W4A16 or compressed-tensors INT4 |
| Intel profile | OpenVINO INT8/INT4 |
| CPU and Apple edge | Signed GGUF Q4_K_M or Q5_K_M selected by the quality budget |

Each weight and KV-cache variant passes language, taxonomy, citation, calibration, fairness, latency, memory, and adversarial gates independently.

### LoRA, Post-Training, and Distillation

Telynt supports:

- supervised fine-tuning with PEFT LoRA;
- QLoRA/NF4 for resource-constrained offline adaptation;
- reviewed DPO after supervised fine-tuning;
- task-model distillation for high-volume extractors;
- multiple tenant-scoped LoRA adapters on compatible runtime profiles.

A LoRA adapter is an immutable, signed, tenant-scoped `ModelPackage`. Cache identity includes its exact version. Runtime resolution from public hubs and unrestricted dynamic LoRA loading are disabled. Production content never enters automatic continual training.

## Kubernetes and Distributed Inference

### Common Cluster Boundary

Large Kubernetes installations use the [Gateway API Inference Extension](https://gateway-api-inference-extension.sigs.k8s.io/) `InferencePool` and endpoint-picker contract for model-, queue-, load-, and prefix-cache-aware routing. The Telynt inference gateway remains in front as the authorization, task-contract, quota, and output-validation boundary.

### Deployment Profiles

| Profile | Implemented technology | Class |
|---|---|---|
| Single site or appliance | k3s, internal service, node-local signed models | `DEFAULT` |
| Standard Kubernetes | Gateway API Inference Extension, GPU scheduling, node-local model cache, inference-aware autoscaling | `DEFAULT` |
| Enterprise model lifecycle | [KServe](https://kserve.github.io/website/docs/intro) | `VALIDATED_ADAPTER` |
| Large distributed models | KServe `LLMInferenceService`, LeaderWorkerSet, and llm-d | `ADVANCED_PROFILE` |
| Non-Kubernetes HPC/bare metal | llm-d-compatible routing and Telynt deployment adapter | `ADVANCED_PROFILE` |

KServe `LLMInferenceService` remains isolated behind the Telynt deployment adapter because its published API is still `v1alpha1`. llm-d is activated for scale that benefits from cache-aware scheduling, tiered KV, disaggregated prefill/decode, or wide expert parallelism; it is not imposed on smaller installations.

Online replicas scale from queue depth, waiting and running requests, input/output token rate, KV utilization, p95 time to first token, and p95 time per output token. Batch analysis uses separate lower-priority queues. Prefill and decode pools scale independently only when production traces justify disaggregation.

Models are pre-seeded from the signed internal registry to node-local NVMe or persistent volumes. Runtime Internet downloads are disabled. Model-load time, cold starts, cache warmup, placement, GPU fragmentation, and rollback are measured as deployment health.

## Retrieval and Knowledge Architecture

### Default Evidence Retrieval

The production default remains:

```text
ABAC, purpose, validity and sensitivity filter
  → BM25 and exact retrieval + multilingual dense retrieval
  → Reciprocal Rank Fusion
  → local cross-encoder reranker
  → diversity, recency and source-authority selection
  → citation and entailment verification
```

This path retrieves exact names, codes, figures, dates, and clauses while recognizing semantic equivalents. Authorization occurs before candidate calculation and again before evidence delivery.

### Qualified Retrieval Profiles

| Technology or method | Implemented use | Class |
|---|---|---|
| PostgreSQL + [pgvector](https://github.com/pgvector/pgvector) | Transactional metadata and local exact/approximate vector search | `DEFAULT` |
| [OpenSearch hybrid search](https://docs.opensearch.org/latest/vector-search/ai-search/hybrid-search/index/) | BM25, filtering, aggregation, sparse/dense retrieval, and RRF | `DEFAULT` |
| [ColBERTv2](https://github.com/stanford-futuredata/ColBERT) / late interaction | High-recall clauses, commitments, transcript turns, and fine-grained evidence | `VALIDATED_ADAPTER` |
| BGE-M3 or equivalent registered package | Multilingual dense, sparse, and multi-vector representation | `VALIDATED_ADAPTER` |
| [GraphRAG](https://github.com/microsoft/graphrag) method | Local, global, and DRIFT-style queries over Telynt’s temporal business graph | `ADVANCED_PROFILE` |
| [RAPTOR](https://proceedings.iclr.cc/paper_files/paper/2024/hash/8a2acd174940dbca361a6398a4f9df91-Abstract-Conference.html) method | Hierarchical retrieval across long SOWs, contracts, reports, and meeting histories | `ADVANCED_PROFILE` |
| [ColPali](https://github.com/illuin-tech/colpali)-style visual retrieval | Rendered proposals, slides, diagrams, tables, whiteboards, and screenshots | `VALIDATED_ADAPTER` |

The retrieval router selects lexical/dense, late-interaction, graph, hierarchy, or visual retrieval from the query and agent purpose. Results may be fused, but permission filtering occurs at every graph hop and before every candidate score.

GraphRAG operates over Telynt’s own versioned evidence graph. Model-extracted nodes and edges remain suggested findings until validation or review. RAPTOR summaries retain links to leaf evidence and never satisfy a literal citation without the underlying source. Visual retrieval complements OCR and textual retrieval rather than replacing them.

### Context Construction

The context assembler applies:

- parent–child and clause-aware chunking;
- topic- and turn-aware transcript windows;
- contextual headers without rewriting source text;
- source authority, validity, sensitivity, and trust metadata;
- token-budget allocation by evidence value;
- duplicate suppression and diversity;
- lost-in-the-middle mitigation through evidence ordering;
- precise timestamp, page, cell, region, and checksum references.

Context compression outputs are model-generated artifacts with their own provenance and trust label. Material conclusions always resolve to original evidence.

## Agent State and Memory Technology

Telynt implements explicit, typed memory rather than hidden framework memory:

| Memory class | Canonical implementation | Authority and retention |
|---|---|---|
| Workflow state | Temporal workflow history plus encrypted referenced artifacts | Authoritative for the current durable run; bounded by workflow retention |
| Working context | Ephemeral encrypted worker storage and immutable context-package references | Invocation-scoped; deleted at the configured TTL |
| Source memory | Versioned object storage, transcripts, documents, checksums, and source metadata | Original evidence; never overwritten by a model |
| Business semantic memory | PostgreSQL temporal graph, OpenSearch, and pgvector indexes | Structured entities, relationships, decisions, commitments, actions, risks, and acceptances with evidence links |
| Review and episodic memory | Versioned findings, human decisions, corrections, and run outcomes | Authoritative only for the recorded reviewed state |
| Procedural memory | Signed `AgentPackage` versions and referenced OCI prompt, policy, skill, tool, taxonomy, and schema artifacts | Activated only by deployment and policy; never self-modified by an agent |
| Personal development memory | Segregated private recommendation and practice records | Visible only to the person and explicitly authorized support roles |

Framework sessions and checkpoints are cached implementation state. They are correlated to, but never replace, Temporal history or the Telynt evidence and business stores. Vector similarity does not establish truth, identity, permission, or current validity.

Every memory read applies current authorization and purpose. Every memory write is a separate tool operation with schema validation, provenance, trust-label propagation, retention, recipient rules, and immutable audit. Agents do not create undeclared memories, rewrite source evidence, or carry context between tenants.

## Multimodal Model Use

Telynt uses modality-specific extraction and retrieval before VLM verification:

- scene-change and time-based frame sampling;
- OCR and layout extraction before general VLM use;
- visual-token, pixel, frame, and duration budgets;
- page and frame multi-vector retrieval;
- VLM analysis of selected slides, whiteboards, screens, diagrams, and demonstrations;
- page/frame, timestamp, region, and content-hash citations;
- independent OCR or textual corroboration when a material finding depends on visible text.

Media is passed as policy-scoped local bytes or short-lived internal references. Arbitrary external media URLs, redirects, and private-address fetches are disabled to prevent SSRF. Runtime multimodal caches use content hashes scoped to the tenant trust domain.

## Prompt-Injection and Information-Flow Security

### Trust Labels and Taint Propagation

Every `ContextItem`, `Artifact`, `ToolResult`, memory record, and handoff carries provenance, sensitivity, and one of these trust labels:

- `SYSTEM`;
- `TENANT_POLICY`;
- `USER_AUTHORIZED`;
- `INTERNAL_EVIDENCE`;
- `EXTERNAL_UNTRUSTED`;
- `MODEL_GENERATED`.

Labels propagate through retrieval, summarization, tool results, agent handoffs, and memory writes. Derived content receives the least-trusted applicable label. A model cannot promote the trust of data.

System instructions, tenant policy, user intent, evidence, and tool results remain separate typed fields. Email, transcript, webpage, calendar, document, and model-generated text are data; they never change permissions, tools, recipients, budgets, retention, identity, or memory policy.

### Deterministic Tool Enforcement

Every tool call passes through a reference monitor that validates:

1. SPIFFE workload identity;
2. authenticated user or service principal;
3. tenant and agent deployment;
4. Temporal workflow and task-bound grant;
5. OpenFGA object relationships;
6. OPA contextual decision;
7. tool manifest, risk class, and parameter schema;
8. input trust and taint constraints;
9. data sensitivity and destination;
10. required human approval;
11. idempotency and resource limits.

The model proposes a tool call; the gateway authorizes, transforms, executes, and audits it.

### Credentials, Network, and File Access

Agents receive no ambient credentials. After authorization, the secret broker issues a short-lived token scoped to one run, one tool, one destination, and one operation.

Workers have deny-by-default network and filesystem policy. Authorized outbound calls traverse an egress proxy with host allowlists, DNS and IP revalidation, redirect policy, private-range blocking, SSRF controls, content-type and size limits, malware inspection, and time limits.

Unrestricted SQL, shell, browser, filesystem, public hub, package manager, and network tools do not exist in production agent manifests.

### Consequential Writes and Handoffs

High-impact operations use:

```text
prepare draft
  → deterministic policy and current-permission recheck
  → recorded human approval when required
  → commit with idempotency key
  → verify result
  → compensate or escalate on partial failure
```

Agent-to-agent handoffs are typed, signed envelopes containing task, purpose, artifact references, policy decision, remaining budget, intended recipient, and permitted next operation. Free-form text never transports authority.

Memory write is a separate policy-controlled tool. Agent memory is explicitly bounded and policy-controlled; agents cannot create hidden memory or change their own memory policies.

Prompt-injection detectors, spotlighting, LlamaFirewall, and NeMo Guardrails are defense-in-depth adapters. They never replace authorization, isolation, taint propagation, or the tool gateway. The CaMeL research architecture informs the information-flow design, but its research codebase is not a production dependency.

## Observability and Immutable Audit

### OpenTelemetry Profile

Telynt uses OpenTelemetry SDKs, Collector, OTLP, and a pinned compatibility profile for the evolving GenAI semantic conventions. The profile covers:

- agent and workflow runs;
- model invocation and streaming;
- embedding, retrieval, and reranking;
- tool calls and approval waits;
- guardrails and policy decisions;
- evaluation runs;
- token, latency, cost, queue, cache, GPU, and error metrics.

W3C Trace Context links UI, API, workflow, agent, model, retrieval, and tool boundaries. OpenInference is an export/enrichment adapter for compatible observability platforms; it is not the internal canonical schema.

Prompts, transcripts, retrieved excerpts, tool arguments, credentials, and model output are excluded from ordinary telemetry. Content capture is tenant opt-in, separately encrypted, access-controlled, time-limited, and redacted at source or in the Collector. Tail sampling retains all denials, extraordinary access, cross-tenant probes, high-risk actions, and failures.

### Audit Ledger

OpenTelemetry is not the audit record. Telynt writes an append-only, WORM-capable, cryptographically chained ledger containing:

- human, agent, workload, and task identities;
- tenant, object, and purpose;
- policy and relationship decision;
- package, model, prompt, tool, schema, and source versions;
- artifact and evidence references;
- approval, action, result, and error;
- timestamps, correlation, and integrity checkpoint.

Literal evidence is resolved only after a new authorization check. Merkle checkpoints and signatures support independent integrity verification and export.

## Evaluation, Red Teaming, and Promotion

### Canonical Evaluation Model

`EvalSuite`, `EvalCase`, and `EvalRun` pin:

- agent, model, runtime, prompt, taxonomy, tool, policy, and schema versions;
- dataset and evidence versions;
- seed and repetition count;
- expected output or abstention;
- expected citation and policy outcome;
- hardware and deployment profile;
- evaluator and judge versions.

Hard production gates include:

- zero cross-tenant leakage;
- zero unauthorized writes;
- zero policy bypasses;
- zero missing mandatory approvals;
- required schema validity;
- required citation existence;
- task-specific minimum quality and calibration;
- acceptable regression, latency, resource, and recovery behavior.

Measured metrics include precision, recall, F1, package-defined false-positive rates, citation coverage, entailment, Brier score, expected calibration error, abstention, task and tool success, attack success, over-defense, latency, throughput, resource consumption, and human confirmation/modification/rejection.

LLM-as-judge is a secondary metric only. Judges are blind, versioned, calibrated against human labels, and repeated across controlled seeds. A judge never constitutes the only promotion gate.

### Evaluation and Security Tooling

| Technology | Implemented use | Class |
|---|---|---|
| [Inspect AI](https://inspect.aisi.org.uk/) | Primary evaluation and sandbox adapter | `VALIDATED_ADAPTER` |
| [PyRIT](https://github.com/microsoft/PyRIT) | Automated generative-AI red-team campaigns | `VALIDATED_ADAPTER` |
| [garak](https://github.com/NVIDIA/garak) | Model and system vulnerability probes | `VALIDATED_ADAPTER` |
| [AgentDojo](https://github.com/ethz-spylab/agentdojo) | Agent utility and indirect prompt-injection evaluation | `VALIDATED_ADAPTER` |
| Telynt replay and metamorphic runner | Business-taxonomy, evidence, permission, multilingual, counterfactual, and regression cases | `CORE` |

Promotion includes difficult negatives, multilingual and domain slices, metamorphic and counterfactual tests, replay, indirect prompt injection, exfiltration, malicious tools, forged handoffs, dependency compromise, denial of service, and adaptive defense-aware attacks.

Static benchmark success does not replace adaptive red teaming.

## Governance and Threat-Model Mappings

Telynt maps controls and evidence to:

- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework);
- [NIST AI 600-1 Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf);
- [NIST SP 800-218A](https://csrc.nist.gov/pubs/sp/800/218/a/final);
- [NIST Adversarial Machine Learning taxonomy](https://csrc.nist.gov/pubs/ai/100/2/e2025/final);
- [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/);
- [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/);
- [MITRE ATLAS](https://atlas.mitre.org/);
- ISO/IEC 42001 when included in the customer’s contractual assurance profile.

These mappings organize controls, threats, tests, and evidence. They do not replace jurisdiction-specific legal review or deterministic runtime enforcement.

## Capability Activation Registry

Every technology whose activation varies by deployment has an explicit class and gate:

| Capability | Class | Activation gate |
|---|---|---|
| MCP resources, tools, prompts, elicitation, Tasks, and Skills | `CORE` | Registered server, protocol conformance, schemas, policy, taint, and audit |
| MCP Apps | `GATED_CAPABILITY` | Widget sandbox, content security policy, origin isolation, accessibility, and UI security review |
| A2A independently deployed agents | `CORE` | Signed Agent Card, identity, authorization, destination allowlist, package admission, and remote-agent evaluation |
| `telynt-agui-core.v1` streaming profile | `VALIDATED_ADAPTER` | Pinned upstream release, event allowlist, payload redaction, reconnection, ordering, and compatibility tests |
| Fixed-schema XGrammar or native grammar decoding | `DEFAULT` | Schema-subset compilation, warmup, runtime conformance, and semantic validation |
| XGrammar dynamic structured generation | `GATED_CAPABILITY` | Exact model/runtime compatibility and structured-output regression suite |
| Tenant-isolated prefix/KV caching | `DEFAULT` | Complete cache identity, cryptographic salt, retention, deletion, and cross-tenant isolation tests |
| Hierarchical KV offload and cache-aware routing | `ADVANCED_PROFILE` | Measured cache reuse, encryption, storage, latency, and deletion behavior |
| Draft-model, EAGLE/MTP, n-gram, or suffix speculative decoding | `GATED_CAPABILITY` | Model/profile benchmark proving quality-preserving p95 latency or throughput gain |
| FP8, FP4, INT4, AWQ, GPTQ, OpenVINO, or GGUF quantization | `GATED_CAPABILITY` | Variant-specific task, language, evidence, calibration, fairness, and resource gates |
| Tenant-scoped LoRA and multi-LoRA | `GATED_CAPABILITY` | Signed adapter, data authorization, base-model compatibility, cache isolation, and task evaluation |
| Disaggregated prefill/decode and wide expert parallelism | `ADVANCED_PROFILE` | Large-scale trace benchmark, failure recovery, network, placement, and cost evidence |
| ColBERT late interaction and ColPali visual retrieval | `VALIDATED_ADAPTER` | Purpose-specific retrieval, permission, storage, latency, and citation benchmarks |
| GraphRAG and RAPTOR methods | `ADVANCED_PROFILE` | Corpus benefit, build cost, source-link preservation, and hallucinated-edge/summary controls |
| Confidential Containers and TEE key release | `ADVANCED_PROFILE` | Compatible hardware, verified attestation, measured image, KMS policy, and recovery test |
| OpenInference export | `VALIDATED_ADAPTER` | Mapping to the pinned Telynt OpenTelemetry profile and content-redaction test |

## Explicit Maturity Boundaries

The following boundaries prevent emerging technology from being overstated:

- AG-UI uses only upstream release 2026-05-26 through the immutable `telynt-agui-core.v1` event profile.
- OpenTelemetry GenAI conventions use a pinned Telynt compatibility schema because the upstream vocabulary continues to evolve.
- MCP Tasks remain external handles; Temporal remains the durable state owner.
- A2A is limited to independently deployed agents, avoiding distributed complexity inside the native runtime.
- KServe `LLMInferenceService` remains behind an adapter while its API is `v1alpha1`.
- llm-d is a large-scale profile, not a requirement for small installations.
- vLLM disaggregated prefill/decode is not used as a generic core capability; qualified llm-d/KServe profiles provide that topology.
- Dynamic remote LoRA loading, untrusted GGUF, arbitrary `trust_remote_code`, unrestricted VLM URLs, and shared unsalted KV caches are disabled.
- CaMeL is an architectural research reference, not executable production code.
- Prompt-injection detectors and guardrails are never sole security controls.
- Confidential Containers and TEE processing are enabled only on attested compatible infrastructure.
- Framework-native durable state, memory, authorization, and audit do not supersede Telynt contracts.

## Implemented Technology Decisions and Trade-Offs

| Decision | Benefit | Cost or limitation | Implemented control |
|---|---|---|---|
| Protocol-centered architecture | Interoperability without framework lock-in | More conformance testing | Canonical contracts and adapter suites |
| Temporal as the single durable orchestrator | Reliable replay, waits, retries, and approvals | Operational stateful service | Multi-zone persistence, backups, workflow versioning |
| MCP through a gateway | Broad tool and context ecosystem | Untrusted third-party metadata and content | Registration, policy, taint, schema, sandbox, audit |
| A2A only at independent-agent boundaries | External interoperability | Distributed trust and callbacks | Signed cards, identity, allowlists, scoped tasks |
| Multiple inference adapters | Hardware and workload efficiency | Larger qualification matrix | vLLM default; capability routing and pinned profiles |
| Structured decoding | High syntactic validity | Grammar compilation and schema subset | Warmed grammars plus semantic assurance |
| Hybrid and specialized retrieval | Better evidence recall | Index and routing complexity | Purpose router, ACL-before-retrieval, benchmark gates |
| Prefix/KV cache isolation | Lower latency without tenant leakage | Reduced cross-request reuse | Tenant, policy, adapter, evidence, and salt in key |
| Signed OCI package chain | Portable and verifiable extensions | Build and registry overhead | SLSA, in-toto, SPDX, cosign admission |
| Layered sandbox profiles | Proportionate isolation | Several execution backends | Risk-based selection behind one runner contract |
| Deterministic authorization | LLM cannot self-authorize | More policy modeling | SPIFFE + OpenFGA + OPA reference monitor |
| Full evaluation and adaptive red team | Safer promotion | Time and compute cost | Risk-based suites, hard gates, replay, canary |
| Telemetry separated from audit | Operability and defensible records | Two data paths | OTel for operations; immutable ledger for authority |

## Technology Acceptance Criteria

The implemented baseline satisfies all of the following:

1. Every external boundary uses a documented, version-pinned protocol.
2. Temporal remains the sole authoritative durable workflow state.
3. Every framework adapter produces canonical Telynt contracts.
4. Every tool and remote agent crosses a deterministic policy gateway.
5. Every executable, model, agent, tool, prompt, policy, and evaluation artifact resolves to an immutable OCI digest.
6. Every production package has verified signature, provenance, bill of materials, and evaluation evidence.
7. Every workload has an attested identity and receives only short-lived scoped credentials.
8. Every untrusted extension runs in the isolation profile required by its risk.
9. Every model route advertises tested capabilities and hides runtime-specific APIs.
10. Every structured result passes syntactic and semantic assurance.
11. Every cache is partitioned by tenant, policy, model, adapter, evidence, and cryptographic salt.
12. Every inference optimization is enabled by representative benchmark evidence.
13. Every retrieval candidate is authorization-filtered before scoring and delivery.
14. Every material result resolves to original, versioned evidence.
15. Every context item and derived artifact propagates provenance, sensitivity, and trust.
16. No natural-language content grants authority or alters policy.
17. Every consequential write uses prepare, reauthorization, approval where required, idempotent commit, and verification.
18. Operational telemetry excludes literal confidential content by default.
19. Immutable audit remains independent of the observability backend.
20. Production promotion passes quality, leakage, authorization, resilience, and adaptive-security gates.
21. Every new version supports canary, immediate suspension, deterministic rollback, and reproducible replay.
22. Customer and Effority packages use the same admission contract without sharing private artifacts across tenants.
23. Every agent memory read and write resolves to a typed canonical store, current authorization, explicit retention, provenance, and audit.

## Canonical References

### Agentic Protocols and Runtime

- [MCP specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28)
- [A2A specification](https://a2a-protocol.org/latest/specification/)
- [Temporal documentation](https://docs.temporal.io/)
- [AG-UI documentation](https://docs.ag-ui.com/)
- [CloudEvents 1.0.2](https://github.com/cloudevents/spec/releases/tag/ce%40v1.0.2)
- [AsyncAPI 3.1.0](https://www.asyncapi.com/docs/reference/specification/v3.1.0)
- [OpenAPI specification](https://spec.openapis.org/oas/latest.html)
- [OpenTelemetry semantic conventions](https://opentelemetry.io/docs/specs/semconv/)

### Agent Authoring

- [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/)
- [Google Agent Development Kit](https://adk.dev/)
- [Microsoft Agent Framework](https://learn.microsoft.com/en-us/agent-framework/)
- [LangGraph](https://docs.langchain.com/oss/python/langgraph/overview)

### Model Serving and Retrieval

- [vLLM](https://docs.vllm.ai/)
- [SGLang](https://docs.sglang.io/)
- [TensorRT-LLM](https://nvidia.github.io/TensorRT-LLM/latest/index.html)
- [llama.cpp](https://github.com/ggml-org/llama.cpp)
- [OpenVINO GenAI](https://github.com/openvinotoolkit/openvino.genai)
- [ONNX Runtime GenAI](https://github.com/microsoft/onnxruntime-genai)
- [llm-d](https://github.com/llm-d/llm-d)
- [Kubernetes Gateway API Inference Extension](https://gateway-api-inference-extension.sigs.k8s.io/)
- [KServe](https://kserve.github.io/website/docs/intro)
- [XGrammar](https://github.com/mlc-ai/xgrammar)
- [ColBERT](https://github.com/stanford-futuredata/ColBERT)
- [Microsoft GraphRAG](https://github.com/microsoft/graphrag)
- [RAPTOR paper](https://proceedings.iclr.cc/paper_files/paper/2024/hash/8a2acd174940dbca361a6398a4f9df91-Abstract-Conference.html)
- [ColPali](https://github.com/illuin-tech/colpali)

### Security, Supply Chain, and Evaluation

- [SPIFFE and SPIRE](https://spiffe.io/docs/latest/spiffe-about/overview/)
- [OpenFGA](https://openfga.dev/docs/concepts)
- [Open Policy Agent](https://www.openpolicyagent.org/docs)
- [OCI Distribution specification](https://github.com/opencontainers/distribution-spec)
- [Sigstore documentation](https://docs.sigstore.dev/)
- [in-toto attestations](https://github.com/in-toto/attestation/tree/main/spec)
- [SLSA 1.2](https://slsa.dev/spec/v1.2/)
- [SPDX specifications](https://spdx.dev/use/specifications/)
- [gVisor architecture](https://gvisor.dev/docs/architecture_guide/intro/)
- [Wasmtime security](https://docs.wasmtime.dev/security.html)
- [Kata Containers](https://katacontainers.io/)
- [Firecracker](https://firecracker-microvm.github.io/)
- [Inspect AI](https://inspect.aisi.org.uk/)
- [PyRIT](https://github.com/microsoft/PyRIT)
- [garak](https://github.com/NVIDIA/garak)
- [AgentDojo](https://github.com/ethz-spylab/agentdojo)

---

This baseline is part of the implemented product specification. A dependency upgrade changes the qualified baseline only after the resulting deployment passes the same evidence, security, performance, compatibility, and rollback gates.