# Telynt Core Platform Architecture

## 1. Purpose

This document defines the architecture of the Telynt base platform independently of any installed business configuration. It describes the professional open-source infrastructure, system boundaries, runtime, data stores, security controls, extension mechanisms, version chain, and operational topology on which Telynt configurations operate.

The Technology Consulting & Delivery Intelligence Industry Solution, its capability bundles, business agents, detectors, classifiers, dashboards, taxonomies, and organization-specific connectors are installable configuration content and are not part of the base architecture described here.

### 1.1 Enterprise Platform and Development Tools

Telynt separates the platform that operates business solutions from the environment and kit that define their packages. A customer can deploy and use ready-made packages without developing them or operating the authoring tools.

| Product surface | Responsibility | Primary users |
|---|---|---|
| **Enterprise Platform** | Installs compatible, qualified packages; executes agents and workflows; manages business data; renders interfaces; enforces security, governance, deployment and rollback controls | Business users, solution administrators and platform operators |
| **Development Environment** | Provides the Authoring Studio, package workspaces, AI-assisted proposals, previews, source versioning, validation and release preparation | Marketplace publishers, Effority, partners and authorized customer development or configuration teams |
| **SDK** | Provides typed contracts, schemas, libraries and test tools for custom agents, integrations, workflows and package components | Package developers, whether publishing externally or developing privately |
| **Marketplace** | Distributes packages and industry solutions with compatibility, ownership, licensing and support information | Publishers and authorized package consumers |

The Development Environment and SDK produce the same signed, versioned package formats regardless of their author or distribution channel. Customer teams can create packages, extend existing packages through overlays or enrichment, and modify source where the package license permits. An existing publisher release remains immutable.

Natural-language authoring generates proposed screens, workflows, data models and related package definitions. These are editable drafts, not changes to a live solution. Developers and authorized administrators review and validate them before creating a release. Authoring permissions do not grant production deployment rights, production credentials or access to business data.

Private releases use an organization's private registry. Marketplace publication is optional and does not deploy or activate a package in any customer installation. Installation, environment promotion and activation remain authorized Enterprise Platform operations, with dependency checks, evaluation gates and audit records.

The product boundary is functional and permission-scoped; it does not require the tools and platform to run on different physical hosts. The **Development Environment** is the authoring product surface, while **Development** in the four-environment lifecycle is an isolated runtime target used to integrate and exercise package versions. Testing, Staging and Production do not depend on an active authoring session or service to operate installed solutions.

The lifecycle is:

```text
Development Environment + SDK
  -> reviewed package source and versioned build
  -> signed package release in a private registry
     -> optional Marketplace publication and distribution
  -> Enterprise Platform qualification and controlled deployment
     -> Testing -> Staging -> Production
```

Both distribution paths resolve immutable package digests through the same platform contracts. See [AI-Assisted Customization](/documentation/platform/packages-marketplace#10-ai-assisted-customization) for the authoring workflow.

## 2. Architectural Decision Summary

Telynt Core is a self-hostable, cloud-native, event-driven enterprise AI platform with:

- four isolated environments: Development, Testing, Staging, and Production;
- Kubernetes as the portable execution substrate;
- Apache Kafka as the durable event backbone;
- Temporal as the durable workflow and process orchestrator;
- PostgreSQL as the transactional system of record;
- Ceph Object Gateway as the default S3-compatible object store;
- OpenSearch as the reconstructible text, vector, hybrid-search, and analytics index;
- Valkey for ephemeral caching, rate state, and short-lived coordination;
- KServe with qualified inference runtimes for model deployment and serving;
- Keycloak, OpenFGA, OPA, SPIFFE/SPIRE, and OpenBao for identity, authorization, policy, workload identity, and secrets;
- Git-compatible source control, Tekton, Harbor, Sigstore/Cosign, and Argo CD for the integrated version and software-supply-chain flow;
- OpenTelemetry, Prometheus, Grafana, Loki, and Tempo for vendor-neutral observability;
- versioned contracts for agents, models, tools, connectors, interfaces, workflows, evaluations, and configuration bundles.

The critical platform path remains self-hostable. Managed services can replace an implementation only through the same documented contract and without changing package semantics or creating an irreversible dependency on a provider.

## 3. Agents, Processes, Workflows, and Workers

### 3.1 The Precise Distinction

Agents are removable and replaceable capability units, but they are not operating-system processes and they are not, by themselves, complete business processes.

| Concept | Meaning in Telynt | Lifecycle and replaceability |
|---|---|---|
| **AgentPackage** | Versioned definition of a bounded classification, analysis, assurance, recommendation, or action capability | Installable, qualifiable, activatable, suspendable, replaceable, and removable when dependencies permit |
| **AgentDeployment** | An immutable qualified agent version available to a tenant or configuration | Promoted between environments and pinned by digest |
| **WorkflowDefinition** | Versioned process graph that coordinates agents, deterministic services, tools, timers, decisions, and human approvals | Installable as part of a configuration and executed durably by Temporal |
| **WorkflowRun** | One execution of a business or platform process | Durable, replayable, cancellable, auditable, and terminal-state controlled |
| **AgentRun** | One invocation of an agent inside a workflow or authorized interactive request | Bound to exact input, package, model, tool, policy, and evidence versions |
| **Worker** | Go or Python runtime process executing workflow or agent code | Horizontally scalable and replaceable infrastructure |
| **Pod or sandbox** | Kubernetes execution boundary hosting one or more workers according to the isolation profile | Ephemeral; not a business identity and not the agent itself |
| **ModelDeployment** | Qualified model-serving endpoint used by an agent | Independently versioned, routed, canaried, suspended, and rolled back |
| **Tool or Connector** | Typed operation through which an agent reads or drafts an external action | Permission-scoped, policy-wrapped, metered, and audited |
| **Platform service** | Deterministic infrastructure such as identity, storage, policy, registry, deployment, and audit | Part of Telynt Core; not removable as an agent |

The relationship is:

```mermaid
flowchart LR
    W["WorkflowRun\nOne process instance"] --> I1["AgentRun A"]
    W --> D["Deterministic step"]
    W --> H["Human approval"]
    W --> I2["AgentRun B"]
    I1 --> P1["Isolated worker pod"]
    I2 --> P2["Isolated worker pod"]
    P1 --> M["Qualified model deployment"]
    P1 --> T["Policy-wrapped tool"]
    P2 --> M
```

Therefore:

- one process can invoke several agents;
- one agent can participate in many processes;
- a process can contain deterministic steps that do not use AI;
- an agent can classify or analyze without owning the whole process;
- installing an agent does not activate it until a configuration binds it to a feature, trigger, workflow, interface, policy, and evaluation profile;
- removing an agent is blocked while an active required binding depends on it;
- retirement preserves historical packages, runs, evidence, reviews, and audit references.

### 3.2 Agent Lifecycle

```text
DRAFT -> REGISTERED -> QUALIFIED -> INSTALLED -> ACTIVE
                                      |           |
                                      v           v
                                   RETIRED     SUSPENDED
```

Reactivation, upgrade, downgrade, replacement, and rollback always resolve to an immutable qualified package digest. Physical deletion occurs only after retention rules confirm that no retained run, report, review, release, or audit record references the artifact.

### 3.3 Example

A project-meeting analysis process can invoke:

1. a meeting-structure agent;
2. a project-execution agent;
3. a scope-and-contract agent;
4. an evidence-verification agent;
5. a human-review routing agent.

Removing the scope-and-contract agent removes that capability only after the configuration replaces or disables its feature binding. It does not delete the workflow history or invalidate independently produced project-execution results.

## 4. High-Level Architecture

```mermaid
flowchart TB
    UI["Enterprise Platform: business interfaces and operational administration"] --> GW["Envoy API and AI Gateway"]
    DEV["Separate Development Environment and SDK"] --> SRC["Versioned package source and validation"]
    SRC --> BUILD["Qualified, signed package release"]
    BUILD --> REG["Package, Model and Configuration Registry"]
    MARKET["Optional Marketplace distribution"] --> REG

    GW --> CP["Telynt Control Plane"]
    CP --> IAM["Identity and Policy"]
    CP --> REG["Package, Model and Configuration Registry"]
    CP --> REL["ChangeSet and Release Controller"]
    CP --> ORCH["Temporal Orchestrator"]

    ORCH --> BUS["Apache Kafka Event Backbone"]
    ORCH --> AR["Isolated Agent Runtime"]
    AR --> TG["Tool and Connector Gateway"]
    AR --> MG["Model Gateway"]
    MG --> KS["KServe: vLLM, ONNX, Triton and specialized runtimes"]

    CP --> PG["PostgreSQL"]
    AR --> OBJ["Ceph Object Storage"]
    AR --> SEARCH["OpenSearch"]
    AR --> CACHE["Valkey"]

    OBS["OpenTelemetry, Prometheus, Grafana, Loki and Tempo"] --- CP
    OBS --- AR
    SEC["Keycloak, OpenFGA, OPA, SPIRE and OpenBao"] --- CP
    SEC --- AR
```

## 5. Runtime Planes

| Plane | Core responsibilities |
|---|---|
| **Experience** | Business application shell, operational administration, API clients, streaming UI events and declarative rendering of installed interface packages; package authoring belongs to the separate Development Environment |
| **Control** | Tenants, entitlements, registries, configuration, feature bindings, triggers, releases, `ChangeSet` records, environment locks, Marketplace metadata, and deployment control |
| **Workflow** | Durable process state, scheduling, timers, retries, compensation, human approval waits, fan-out/fan-in, cancellation, and terminal-state enforcement |
| **Event** | Durable domain and platform events, replay, asynchronous integration, consumer isolation, and incremental reprocessing |
| **Execution** | Agent workers, tool gateway, connector workers, document/media workers, model gateway, and isolated extension sandboxes |
| **Evidence and Data** | Transactional metadata, immutable source objects, versioned evidence, search indexes, derived artifacts, retention, lineage, and audit |
| **Assurance** | Policy decisions, package qualification, evidence verification hooks, human-review routing hooks, security gates, evaluation, and operational monitoring |

## 6. Core Service Boundaries

Telynt Core uses a limited set of stable services instead of creating one microservice per agent.

1. **API Gateway and Backend for Frontend** — external API routing, session boundary, streaming, rate control, and web-specific aggregation.
2. **Tenant, Organization, and Entitlement Service** — tenants, organizations, plans, licenses, Marketplace entitlements, quotas, and isolation profiles.
3. **Identity and Policy Service** — identity federation, object authorization, contextual policy, purpose limitation, and policy-decision audit.
4. **Package, Model, and Configuration Registry** — immutable package metadata, dependencies, compatibility, ownership, signatures, and installation state.
5. **ChangeSet, Version, and Release Service** — diffs, qualification evidence, approvals, environment locks, promotion, suspension, and rollback.
6. **Trigger and Orchestration Service** — event, schedule, API, user, source-change, and policy triggers mapped to Temporal workflows.
7. **Agent Runtime Manager** — worker placement, execution budgets, isolation, capability tokens, termination, and agent-run state.
8. **Model Gateway** — model routing, capability enforcement, inference budgets, batching, streaming, fallback, and deployment health.
9. **Tool and Connector Gateway** — typed tools, connector credentials, MCP operations, idempotency, dry-run, approval, and external-action compensation.
10. **Evidence and Artifact Service** — source versions, object references, evidence fragments, provenance, derived artifacts, and invalidation.
11. **Search and Indexing Service** — permission-aware indexing and lexical, vector, semantic, and hybrid retrieval.
12. **Audit and Operations Service** — append-only audit, telemetry correlation, operational findings, cost, health, and incident integration.
13. **Marketplace Service** — publisher records, listings, licensing, compatibility, purchase, installation, update, revocation, and settlement metadata.

Business agents remain packages executed by the Agent Runtime Manager. They do not add permanent core services unless a qualified extension explicitly supplies a specialized connector or runtime component.

## 7. Event and Workflow Architecture

### 7.1 Apache Kafka

Apache Kafka is the event backbone because Telynt requires durable history, replay, multiple independent consumers, asynchronous extension, and incremental recomputation.

Kafka carries facts such as:

- `package.registered`;
- `source.version_created`;
- `workflow.started`;
- `agent_run.completed`;
- `artifact.invalidated`;
- `change_set.promoted`;
- `environment.rollback_completed`.

Events contain identifiers, versions, tenant and purpose metadata, trace context, and encrypted object references. Literal documents, audio, transcripts, prompts, and sensitive model inputs do not enter ordinary event headers or operational logs.

Kafka runs in KRaft mode and is managed on Kubernetes through Strimzi. Apicurio Registry holds Avro, JSON Schema, and Protobuf event contracts. Every consumer is idempotent, maintains an inbox or checkpoint, and uses dead-letter handling with an explicit replay procedure.

### 7.2 Temporal

Temporal is the authoritative state for durable business and platform processes. It controls:

- step order and dependencies;
- retries and backoff;
- timers and deadlines;
- waits for human approval;
- agent and tool invocation;
- cancellation and compensation;
- fan-out and fan-in;
- replay and recovery after worker failure.

Kafka records that something happened. Temporal controls what must happen next. Telynt does not use Kafka as a substitute for workflow state and does not use Temporal history as the enterprise event backbone.

### 7.3 Why RabbitMQ Is Not in the Default Stack

RabbitMQ is a valid professional open-source broker for routed messages and work queues. It is not installed by default because Temporal already provides durable work execution and Kafka provides the retained event stream. Operating all three would duplicate responsibilities and increase failure modes, patching, monitoring, and support work.

The Tool and Connector Gateway supports a RabbitMQ adapter when a customer system already requires AMQP integration.

### 7.4 Delivery Semantics

Telynt assumes at-least-once delivery across distributed and external boundaries. It does not claim global exactly-once behavior. Correctness uses:

- idempotency keys;
- transactional outbox and consumer inbox patterns;
- optimistic concurrency and version checks;
- immutable event identifiers;
- deterministic workflow activity contracts;
- registered compensation for reversible external actions;
- human remediation for irreversible destinations.

## 8. Persistence Architecture

| Store | Authoritative content | Explicitly not authoritative for |
|---|---|---|
| **PostgreSQL with CloudNativePG** | Tenant, identity references, configuration, package metadata, workflow metadata, reviews, findings, relationships, releases, and audit indexes | Large binary objects and high-volume search indexes |
| **Ceph Object Gateway** | Audio, documents, model files, package payloads, evidence objects, reports, exports, backups, and immutable audit segments | Transaction coordination |
| **OpenSearch** | Reconstructible full-text, vector, hybrid-search, aggregation, and retrieval indexes | Original evidence, permissions, or transactional truth |
| **Valkey** | Cache, rate-limit counters, short locks, ephemeral session and routing state | Durable business or audit records |
| **Kafka** | Retained domain and platform event streams | Current transactional object state |
| **Temporal persistence** | Durable workflow execution history | General business queries and document storage |

PostgreSQL is deployed with independent high-availability clusters for Telynt business metadata and Temporal persistence. Production uses point-in-time recovery, tested backups, replicas on separate failure domains, and connection pooling.

OpenSearch indexes are rebuilt from authorized PostgreSQL and Ceph sources. A missing or corrupted index never changes the underlying source of truth.

## 9. AI and Agent Execution

### 9.1 Model Serving

KServe provides the Kubernetes control and data planes for qualified model deployments. Runtime profiles include:

- vLLM for compatible large language models;
- NVIDIA Triton and ONNX Runtime for predictive, embedding, reranking, vision, and accelerated models;
- llama.cpp for compatible CPU, edge, or constrained deployments;
- specialized ASR, diarization, OCR, and media workers;
- customer-supplied runtime containers after conformance and security qualification.

Models remain behind the Telynt Model Gateway. Agents request a declared capability rather than connecting directly to a model endpoint. The gateway resolves the authorized model, version, hardware profile, prompt contract, schema, budget, and fallback route.

Runtime Internet model downloads and floating tags are disabled. Model weights and associated artifacts resolve to signed immutable digests.

### 9.2 Extension Isolation

Extension packages run under a declared isolation profile:

| Profile | Default use |
|---|---|
| Standard OCI container | Effority-signed and trusted platform components |
| gVisor sandbox | Customer and Marketplace Python or native agents with bounded tools |
| Kata Containers or Firecracker-compatible microVM | High-risk or stronger tenant-isolation workloads |
| Wasmtime/WASI component | Small portable tools, validators, and deterministic transforms |
| Dedicated worker pool or cluster | Regulated, high-volume, hardware-specific, or contractually isolated workloads |

An installed package receives short-lived capability credentials and can access only the sources, objects, models, tools, network destinations, and outputs declared by its manifest and allowed by policy.

## 10. Identity, Authorization, and Security

- **Keycloak** provides user authentication, SSO, OIDC, SAML, LDAP federation, MFA integration, and organization identity mapping.
- **OpenFGA** answers relationship-based object permissions such as whether a user, group, role, or delegated agent can access a project, document, meeting, package, or case.
- **OPA** evaluates contextual policy such as purpose, environment, data category, residency, risk, time, approval, and tool constraints.
- **SPIFFE/SPIRE** gives services and workers cryptographic workload identities.
- **OpenBao** stores and issues secrets; applications do not embed long-lived credentials.
- **Cilium** enforces Kubernetes network policy and service-level traffic isolation.
- **cert-manager** automates certificate lifecycle.
- **Cosign, in-toto attestations, SBOMs, vulnerability scans, and admission policies** protect the software and model supply chain.
- **gVisor, Kata Containers, or Wasmtime** isolate customer and Marketplace code.

Authorization is checked at request entry, context assembly, evidence retrieval, model invocation, tool invocation, artifact publication, and interface disclosure. An agent never gains more authority than the user, service, or policy that delegated the run.

## 11. Integrated Version and Supply-Chain Architecture

### 11.1 Technology Flow

```mermaid
flowchart LR
    G["Git-compatible source\nForgejo or enterprise Git"] --> T["Tekton build and evaluation"]
    T --> S["SBOM, provenance, signatures and attestations"]
    S --> H["Harbor OCI Registry"]
    H --> C["ChangeSet and environment lock"]
    C --> A["Argo CD deployment"]
    A --> D["Development"]
    D --> E["Testing"]
    E --> F["Staging"]
    F --> P["Production canary and active"]
    P -.-> R["Prior approved environment lock"]
```

The same artifact digest moves between environments. Telynt never rebuilds a qualified artifact for Staging or Production.

### 11.2 Versioned Objects

The version chain covers:

- source code and dependencies;
- service and interface images;
- agent, workflow, model, tool, connector, interface, evaluation, and configuration packages;
- prompts, skills, schemas, taxonomies, rules, and templates;
- OpenAPI, AsyncAPI, Protobuf, MCP, A2A, and AG-UI contracts;
- identity models, policies, review matrices, and feature bindings;
- database and index migrations;
- evaluation data, rubrics, baselines, and results;
- environment locks, approvals, releases, suspensions, and rollbacks.

### 11.3 ChangeSet

Every modification entering a shared environment has a `ChangeSet` that records:

- author, owner, reason, requirement, and affected tenants;
- source revision and artifact digests;
- semantic and field-level diff;
- affected agents, workflows, models, tools, interfaces, schemas, policies, and features;
- dependency and compatibility analysis;
- security, license, supply-chain, regression, quality, performance, and rollback-test evidence;
- node-by-node promotion history and approvals;
- before and after environment locks;
- rollback target and final disposition.

Rollback restores a complete approved environment lock and creates a new immutable audit event. It never deletes the reverted release, its evidence, or its historical runs.

## 12. Four Isolated Environments

The term **environment** or **platform installation** is used in technical documentation instead of **node**, because every environment can contain many Kubernetes control-plane and worker nodes.

| Environment | Responsibility | Data and access boundary |
|---|---|---|
| **Development** | Integrate and execute package versions produced by the Development Environment and SDK; run local or synthetic development tests | Development credentials and synthetic or explicitly authorized development data |
| **Testing** | Contract, regression, evaluation, red-team, compatibility, performance, migration, and rollback qualification | Independent test credentials and synthetic, de-identified, or approved evaluation data |
| **Staging** | Production-equivalent installation, end-to-end validation, connector rehearsal, shadow validation, capacity, upgrade, and rollback rehearsal | Independent staging credentials and masked or explicitly authorized representative data |
| **Production** | Approved business operation, controlled canary, active releases, and governed rollback | Production-only credentials, keys, data stores, queues, policies, and audit scope |

Each environment operates its own Kubernetes cluster, Kafka, Temporal, PostgreSQL, object-storage namespace, OpenSearch indexes, secrets, credentials, policies, queues, audit scope, and environment lock. Shared release infrastructure can distribute signed immutable artifacts but cannot read business evidence from an environment.

## 13. Observability and Operations

OpenTelemetry provides the canonical correlation context for API requests, Kafka events, Temporal workflows, agent runs, tool calls, model invocations, human review, and artifact publication.

The base platform records:

- service and workflow availability;
- event lag and replay state;
- run latency, retries, failures, cancellation, and terminal states;
- model latency, token rate, batching, cache, accelerator utilization, and cost;
- tool latency, denial, dry-run, approval, and compensation;
- package, policy, schema, and environment versions;
- agent quality, abstention, evidence coverage, drift, and review outcomes when supplied by a configuration;
- storage health, capacity, replication, backup, and restoration results.

Literal customer evidence is excluded from ordinary logs, traces, labels, metric dimensions, and event headers. Authorized diagnostic samples use a separate access-controlled evidence path.

## 14. Base Installation Contents

### 14.1 Included

- the web and administration shell;
- tenant, identity, authorization, policy, and entitlement services;
- package, model, workflow, interface, connector, evaluation, and configuration registries;
- event, workflow, agent, model, tool, evidence, search, audit, and deployment runtimes;
- package installation and registry integration for private and Marketplace releases;
- integrated version control, qualification, promotion, suspension, and rollback;
- the minimum trusted package-qualification and AI-operations capabilities required to govern the platform itself;
- documented runtime APIs, schemas and extension contracts consumed by the separate development tools.

### 14.2 Not Included Until a Configuration Is Installed

- business classification or analysis agents;
- meeting, commercial, project, relationship, ethics, engineering, or personal-development functions;
- business taxonomies and thresholds;
- organization-specific data-source connections;
- role-specific dashboards and reports;
- organization-specific workflow and review definitions;
- external-action permissions.

An empty Telynt installation is operational and administrable but intentionally performs no business analysis until an authorized configuration activates the required packages and bindings.

### 14.3 Separate Development and Distribution Services

The Authoring Studio, development workspaces, SDK, package build and authoring tools form the Development Environment and development kit. They are not required inside each business runtime installation. The Marketplace provides a separate distribution channel; private registries provide the internal alternative. Both use the Enterprise Platform's package, qualification and deployment contracts without bypassing its security controls.

## 15. Deployment Profiles

The same contracts support:

- private-cloud Kubernetes;
- public-cloud Kubernetes;
- on-premises Kubernetes;
- sovereign or dedicated-tenant installations;
- air-gapped installations with offline registry synchronization;
- hybrid installations with local evidence and separately authorized remote inference;
- compact non-production installations preserving the same package and API contracts.

Production high availability uses multiple failure domains where infrastructure permits. PostgreSQL, Kafka, Ceph, OpenSearch, and Kubernetes control planes use topology-aware replicas and tested backup or disaster-recovery procedures. Exact RPO, RTO, availability, throughput, and capacity remain activation parameters rather than hidden assumptions.

## 16. Principal Decisions and Trade-Offs

| Decision | Benefit | Cost or limitation | Control |
|---|---|---|---|
| Kafka plus Temporal, without default RabbitMQ | Clear separation between retained events and durable processes | Two distributed systems to operate | Separate ownership, SLOs, schemas, and failure tests |
| Limited stable core services | Lower operational and cognitive overhead | Some services contain several related modules | Strict module boundaries and independent scaling where justified |
| PostgreSQL as transactional truth | Mature consistency and operational knowledge | Not optimized for every retrieval pattern | Reconstructible OpenSearch and object-store projections |
| Ceph behind S3 contracts | Self-hosted, durable, portable object storage | Significant operational expertise | Managed S3-compatible replacement and dedicated storage operations |
| Declarative package and interface contracts | Safer extension and reproducible Marketplace installation | Less unrestricted customization | Qualified isolated runtime for exceptional custom components |
| No global exactly-once claim | Honest behavior across external systems | Requires idempotency and compensation design | Outbox, inbox, version checks, workflow state, and review |
| Four independent environments | Strong isolation and reliable qualification | Higher infrastructure cost | Compact sizing outside Production; same contracts in every environment |
| Open-source critical path | Self-hosting and reduced provider lock-in | Internal operational capability or support contracts required | Replaceable adapters, documented exit, and upstream version qualification |

## 17. Items Revisited as Scale Grows

The following implementation choices are reviewed against measured workloads without changing the stable platform contracts:

- whether a large tenant receives dedicated Kafka, Temporal, PostgreSQL, OpenSearch, model, or execution clusters;
- when a specialized vector database outperforms the OpenSearch hybrid-search profile;
- when a dedicated temporal graph engine is justified beyond the PostgreSQL graph abstraction;
- when control-plane services require independent decomposition or regional replication;
- whether Ceph, an external S3 service, or another qualified S3-compatible implementation is preferred for a deployment;
- placement across CPU, GPU, NPU, confidential-computing, and edge pools;
- multi-region active/passive or active/active disaster-recovery topology;
- additional qualified agent-framework, model-runtime, connector, and policy-engine adapters.

## 18. Official Technology References

- [Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/)
- [Apache Kafka documentation](https://kafka.apache.org/documentation/)
- [Temporal documentation](https://docs.temporal.io/)
- [CloudNativePG high availability](https://cloudnative-pg.io/info/high-availability/)
- [Ceph Object Gateway](https://docs.ceph.com/en/latest/radosgw/)
- [OpenSearch hybrid search](https://docs.opensearch.org/latest/vector-search/ai-search/hybrid-search/index/)
- [Valkey documentation](https://valkey.io/topics/introduction/)
- [KServe documentation](https://kserve.github.io/website/docs/intro)
- [Keycloak documentation](https://www.keycloak.org/documentation)
- [OpenFGA documentation](https://openfga.dev/docs/fga)
- [Open Policy Agent documentation](https://www.openpolicyagent.org/docs)
- [Argo CD documentation](https://argo-cd.readthedocs.io/en/stable/)
- [OpenTelemetry documentation](https://opentelemetry.io/docs/)

## 19. Related Telynt Documentation

- [Industry Solution Composition Model](/documentation/platform/industry-solutions)
- [Composable Package, Customization, and Marketplace Architecture](/documentation/platform/packages-marketplace)
- [Technology Consulting & Delivery Package Composition](/documentation/technology-consulting-delivery/included-packages)
- [Technology Consulting & Delivery Connected Workflows](/documentation/technology-consulting-delivery/connected-workflows)
- [Agentic Platform Specification](/documentation/platform/agentic-platform)
- [Package Agent Index](/documentation/packages/agent-index)
- [Agentic and LLM Technology Baseline](/documentation/platform/agentic-llm-technology)
- [Technical AI Architecture](/documentation/platform/ai-architecture)
- [Product Definition](/documentation/platform/product-definition)