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.

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:

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 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.

The relationship is:

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

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

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

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

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:

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

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.

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

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
• Apache Kafka documentation
• Temporal documentation
• CloudNativePG high availability
• Ceph Object Gateway
• OpenSearch hybrid search
• Valkey documentation
• KServe documentation
• Keycloak documentation
• OpenFGA documentation
• Open Policy Agent documentation
• Argo CD documentation
• OpenTelemetry documentation

19. Related Telynt Documentation

• Industry Solution Composition Model
• Composable Package, Customization, and Marketplace Architecture
• Technology Consulting & Delivery Package Composition
• Technology Consulting & Delivery Connected Workflows
• Agentic Platform Specification
• Package Agent Index
• Agentic and LLM Technology Baseline
• Technical AI Architecture
• Product Definition