Most AI frameworks stop at the model call. They make it easier to send a prompt, parse a response, and wire up a tool. That is a real problem they solve. It is not, however, the problem that keeps a CTO up at night.
The harder problem is what happens around the model: which data it is allowed to see, which model may handle a sensitive workload, which actions require a human before they run, and whether you can prove any of that later. TramAI is built around that second problem, and its roadmap is now aimed squarely at the part that decides whether a governed system is something a team can actually operate — not just embed.
TramAI 0.6.0 is out and published to Maven Central. It is the governed runtime. The 0.7.0 release in progress is something different: an operational control plane. Here is where the project is, and where it is going.
Where TramAI is today: the governed runtime
The 0.6.0 line is the foundation. It is a Kotlin-first JVM runtime that puts AI governance into the execution path rather than into prompts and scattered glue code. Six capabilities are the backbone:
- Typed contracts. Kotlin interfaces with typed inputs and outputs, structured-output generation and validation, and deterministic testing — no raw prompt plumbing in application code.
- Governance in the execution path. Model and tool policy enforced at runtime before providers, tools, and responses proceed. Every decision is ALLOW, DENY, or REQUIRE_APPROVAL — explicit, testable, auditable.
- Human-controlled execution. Approval gates, suspension, and replay-safe continuation, so a high-risk operation does not run until a person says it may.
- Controlled routing. Provider selection based on workflow classification and data policy — a RESTRICTED workload can be kept off an unauthorized provider.
- Evidence and recovery. Tamper-evident audit sequencing, runtime evidence export, and JDBC and file-backed persistence when configured.
- Composable adoption. Standalone or Spring Boot; adopt only what you need, with no mandatory hosted control plane.
The Sovereign Runtime reached a release-candidate milestone in this line: JDBC-backed persistence, transactional approval mutation, worker-lease coordination for multi-node deployments, and a regulated claim-triage end-to-end proof. That is the “governed runtime” part — the thing that enforces.
What it is not: it is not a model, not a no-code agent builder, not a hosted multi-tenant SaaS, and it does not claim compliance or certification. It is a governance runtime that sits under a compliance process.
The principle behind the roadmap: governance is the invariant
The most important thing about TramAI’s roadmap is not what is coming. It is what is staying fixed.
TramAI’s releases are layered on top of one invariant: the authority model. Every capability added later has to compose with the existing governance decision — never bypass it, and never create a second one. This shows up as concrete, testable rules:
selected ∈ viableandviable ⊆ authorized. Preference, cost, health, and latency signals may never create governance authority.organization ∩ environment ∩ workload = effective policy. A lower scope cannot widen a higher-level denial.cancelled(run) ⇒ no subsequent authoritative execution(run). Once a suspended run is authoritatively cancelled, a late approval or a process restart cannot bring it back.- One policy engine. No authoring surface — annotations, YAML, DSL, debugger — may create a second one.
That last rule is the whole discipline in one sentence. A lot of AI tooling adds a “governance” layer that quietly becomes a parallel engine, and the two disagree in production. TramAI’s roadmap is explicitly built so that cannot happen.
The roadmap: one question per release
The project plans each release as a single product question, which is what keeps it coherent instead of a feature list:
| Release | Theme | The question it answers |
|---|---|---|
| 0.7.0 | Governed AI Control Plane | Can operators see, understand, control, and reconstruct a governed workload? |
| 0.8.0 | Governance DX & Intelligence | Can developers define, test, and explain governance easily? |
| 0.9.0 | Enterprise Deployment & Security | Can an enterprise adopt and operate it without building the platform itself? |
| 0.10.0 | Governed Learning & Optimization | Can it learn and optimize from governed outcomes without weakening governance? |
| 1.0 | Stable API | Are the public contracts mature enough for a long-term compatibility commitment? |
0.8.0 is where governance becomes something you can reason about before production: policy simulation and decision previews, deterministic replay where the evidence permits, contract testing, and a developer-local debugger — all surfaces over the one canonical governance model. 0.9.0 makes it deployable as an enterprise component: identity integration (OIDC, Entra ID, Okta, Keycloak), a cryptographic key lifecycle, and a reference deployment. 0.10.0 is the most constrained: learning and optimization may choose or further constrain within the authorized set, but “optimization may never create authority” — and no raw-content learning capture ships before the capture, retention, and deletion boundaries are explicit and proven.
Why 0.7.0 — the control plane — is the turning point
Before 0.7, TramAI can govern execution. After 0.7, an operator can see and control it. The release thesis is blunt: the model proposes, TramAI decides, and the control plane shows why.
The 0.7.0 boundary is one coherent loop:
identify → classify → constrain → authorize → select → release → execute
→ evidence → observe → control → reconstructThe release step is the one most frameworks miss. It is not “may this provider be used?” but “what exact representation may cross into it?” — a data-release decision with typed semantics (DENY, ALLOW_RAW, ALLOW_WITH_MINIMIZATION) that is recomputed if a retry or fallback changes the deployment. A projection authorized for one trust boundary cannot be silently reused for another.
The rest of 0.7.0 is the operational surface: an authoritative typed evidence model, a control-plane projection and query API, a semantic execution timeline, OIDC-backed authentication with capability-based server-side authorization, authoritative cancellation of suspended runs with future-resume fencing, and forensic reconstruction without side effects. A first-party Dashboard 2.0 is a client of those APIs — it never becomes a second policy engine.
There is also a deliberate architecture proof in 0.7.0: TramAI governing a boundary initiated by a non-TramAI JVM workload — Spring AI is the reference target. That is the statement that the governance contract, not the framework shape, is the stable commitment.
What this means for EU AI Act deployers
For a deployer under Article 26, the obligation is not a model. It is the ability to show that AI-assisted decisions were made under defined conditions, that sensitive data was handled according to policy, that a human approved what required approval, and that the trail is reconstructable.
TramAI does not make an organization compliant — that claim is deliberately out of scope. What it provides is the runtime substrate a compliance process is built on: the enforcement, the decisions, and the evidence, in the same execution path. That is the difference between a PDF that says the controls exist and a system that demonstrates they ran. The control plane in 0.7.0 is exactly that “show, not tell” surface — audit evidence and the reconstruction story, as a first-class product.
The honest status
TramAI is under active development, and the roadmap says so plainly. What is not claimed:
- A stable 1.0 public API.
- A production certification, or “compliant out of the box.”
- Guaranteed sovereignty or air-gapped-by-default.
- Production-grade enterprise IAM and reviewer UI (deferred to 0.9.0).
- Key rotation (deferred).
That is the credibility. A roadmap that names what is not done is worth more than one that claims everything.
Where this points for JVM teams
If your AI touches real customer data or makes consequential decisions, the question is not “which model?” It is “who governs it, and can we prove it?” The direction TramAI is taking — from a governed runtime to a governed control plane, with the authority model held fixed across every release — is a concrete answer to that question for the teams whose production systems already run on Java and Kotlin.
Frequently asked questions
What is TramAI? TramAI is a Kotlin-first JVM runtime for governed AI workflows. It puts model and tool policy, sensitive-data handling, human approval, controlled provider routing, and audit evidence into the execution path, so governance is enforced in code rather than left in prompts. It runs standalone or in Spring Boot and is published to Maven Central.
What is the difference between 0.6.0 and 0.7.0? 0.6.0 is the governed runtime — it enforces policy, approval, routing, and evidence during execution. 0.7.0 is the governed control plane — it lets an operator see, understand, control, and reconstruct that governance through a headless API and a first-party dashboard. One is the enforcement; the other is the operational surface over it.
Does TramAI make an organization EU AI Act-compliant? No, and it deliberately does not claim that. TramAI provides the runtime substrate a compliance process is built on: enforcement, decisions, and reconstructable evidence. It supports the obligations a deployer has to evidence, but compliance itself is an organization-level responsibility.
Which providers does TramAI support? OpenAI, Anthropic, Azure OpenAI, Bedrock, Gemini, DeepSeek, and local Ollama, plus an MCP workflow server. Providers are selected by policy and classification rather than hard-wired, so a restricted workload can be routed to a local or trusted deployment.
How is TramAI different from Spring AI and LangChain4j? Spring AI and LangChain4j are integration libraries that make model calls, tools, and prompts easier to manage. TramAI is a governed runtime and, from 0.7.0, a control plane: its primary concern is policy, approval, data handling, and evidence, with typed contracts on top. It can even govern a boundary initiated by a non-TramAI framework such as Spring AI.
Explore further
You can explore the project and its examples at tramai.dev. For a code-level view of how this compares with Spring AI and LangChain4j, read TramAI vs LangChain for the EU AI Act and Java for Production AI Agents. If you are deciding where governed AI fits into a workflow that must stand up to an audit, book a consultation or start with the AI Readiness Audit.
