What Termin guarantees

This page is the definitive public statement of what Termin structurally enforces, what requires a vetted provider, and what remains the responsibility of the application author or the deployment operator.

Every Tier 1 claim links to the conformance test that backs it. If a claim is not backed by a conformance test, it is not on this page.

The eight primitives that make these guarantees structural — Content, Compute, State, Events, Presentation, Channels, Boundaries, and Identity — are enumerated on the Termin model page along with how they compose.

# The three tiers

Termin uses a three-tier model to describe what the platform enforces. The tier determines the strength and scope of the guarantee.

• Tier 1 — Structural. Enforced by the structure of the language and the runtime. Cannot be violated by an application author, an operator, or an agent authoring a .termin file, because the language has no construct for expressing the violation.
• Tier 2 — Vetted provider. A Compute, Channel, or Presentation provider that has passed the conformance suite and undergone a documented security review inherits Tier 1 properties at its boundary.
• Tier 3 — Custom provider. Applications that use providers outside the vetted set take on the responsibility for reviewing those providers.

# Tier 1 — Structural guarantees

The following properties are enforced structurally by every conforming Termin runtime. Each is validated by the conformance suite.

# Injection resistance

Every data access is parameterized by the compiler. The language has no construct for assembling queries as strings or for concatenating user input into executable commands. SQL injection, command injection, expression injection, and template injection are not achievable through Termin application code because the language does not provide the machinery to produce injectable constructs.

Scope: Content access, State queries, Channel payloads, Presentation rendering.

Caveat: Custom providers (Tier 3) may introduce injection vectors if they construct queries from untrusted input. Vetted providers (Tier 2) are reviewed for injection resistance as a condition of certification.

Evidence: tests/test_field_validation.py, tests/test_crud.py.

# Access control

Every operation is scope-checked against the caller's identity. The language requires declaring who can perform each operation, and the runtime enforces the declaration on every call. There is no code path that bypasses access control. Access control is not a library the developer chooses to use — it is a property of the runtime contract.

Scope: Content create/read/update/delete operations (CRUD), State transitions, Compute invocations, Channel sends, Presentation rendering.

Caveat: Correct scope assignment to roles is the responsibility of the application author. Termin enforces that scopes are checked. It does not enforce that the scope assignments are appropriate for your organization.

Evidence: tests/test_access_control.py.

# State transition enforcement

State transitions are declared explicitly in the .termin source. Every transition specifies the source state, the destination state, and the scope required to perform it. The runtime rejects transitions that are not declared, transitions from a state other than the declared source, and transitions attempted by identities without the required scope.

Scope: All Content with declared state machines.

Caveat: The set of states and transitions is determined by the application author. Termin enforces that declared transitions are the only transitions possible.

Evidence: tests/test_state_machines.py.

# Data flow boundaries

Data does not cross a Boundary except through a declared Channel. Channels are typed, schema-validated, and identity-scoped. Cross-boundary data flow cannot occur through side channels, shared memory, or undeclared exports.

Scope: All Content and Compute within a Boundary.

Caveat: Presentation rendering within a Boundary is not a cross-boundary flow. Observation of Content by Presentation within the same Boundary is permitted by default.

Evidence: tests/test_data_isolation.py.

# Confidentiality redaction

Fields declared as confidential are redacted in any response returned to an identity without the required scope. Redaction happens at the runtime layer before data leaves the Boundary. Taint propagation ensures that computed values derived from confidential fields inherit the confidentiality of their inputs. Explicit reclassification is required in the source and is auditable.

Scope: Declared confidential fields across Content, Compute outputs, Channel payloads, and Presentation rendering.

Caveat: The set of confidential fields is declared by the application author. Termin enforces that declared confidential fields are redacted. It does not automatically identify which fields should be confidential.

Evidence: tests/test_confidentiality.py.

# Audit log completeness

Every action that modifies Content or triggers a State transition generates an audit log entry. Entries record the identity of the caller, the operation performed, the affected record, and a timestamp. Audit levels (none, actions, debug) control verbosity but not existence. At the default actions level, field values are not recorded, so confidentiality-protected data is not leaked through the audit log.

Scope: All Content and State operations.

Caveat: debug level records field values and is intended for development environments. Production deployments should use actions.

Evidence: tests/test_runtime_coverage.py.

# Deterministic compilation

The same .termin source compiled by the same compiler version produces the same IR (intermediate representation — a JSON artifact the runtime consumes). The IR is open: it can be inspected, validated against the IR schema, and compared across versions. The compilation pipeline has no sources of nondeterminism.

Scope: The compiler and the IR format.

Caveat: The application identity (app_id UUID) is generated on first compile and written back to the source. Once generated, it is deterministic.

Evidence: tests/test_roundtrip.py, tests/test_ir_schema_validation.py.

# Conformance verifiability

Every Tier 1 guarantee is tested by one or more conformance tests. Any runtime that passes the conformance suite enforces these guarantees. A runtime that does not pass the conformance suite is not a conforming Termin runtime and cannot claim Tier 1 guarantees.

Scope: Every runtime implementation.

Caveat: The conformance suite evolves. A runtime that passed an earlier version may fail a later version. Runtimes must be re-validated against the current suite to maintain their conformance claim.

Evidence: The conformance suite README.

# Tier 2 — Vetted provider guarantees

Vetted providers extend Termin's capabilities while maintaining Tier 1 properties at their boundary. A provider becomes vetted when it has:

1. Passed the Termin conformance suite (or the subset relevant to its capability).
2. Undergone a security review by a qualified reviewer.
3. Documented its own guarantees and caveats in a provider manifest.

# Currently vetted providers

As of v0.8.0, no providers have completed the formal vetting process. Providers shipped with the reference distribution are maintained alongside the runtime but have not undergone external review.

Reference providers in v0.8.0:

• ai-agent — integrates Anthropic and OpenAI APIs for agent-mode Compute nodes.
• cel — evaluates Common Expression Language expressions.
• http — outbound HTTP and inbound webhook Channel support.
• websocket — WebSocket Channel support.

Until the Tier 2 provider review framework is published, treat reference providers as Tier 3 for formal guarantee purposes.

# Provider review framework

A provider-review framework is on the roadmap. It will specify:

• Security review requirements.
• Conformance test requirements per provider type.
• The provider manifest schema.
• The revocation process if a vetted provider is found to have vulnerabilities.

# Tier 3 — Custom provider responsibilities

Applications using custom providers take on the responsibility for reviewing those providers. Custom providers can do anything Termin does not structurally prevent — they can issue arbitrary queries, exfiltrate data through side channels, and introduce any class of vulnerability present in the code they execute.

# What Termin still guarantees with custom providers

Even when a custom provider is in use, the following Tier 1 properties hold for the non-provider parts of the application:

• Access control on Compute invocations — the decision to call the provider is scope-checked.
• Boundary isolation — the custom provider's Boundary is still a Boundary.
• Audit logging of provider invocations.
• Confidentiality scope on inputs passed to the provider.

# What Termin does not guarantee with custom providers

• Injection resistance inside the provider.
• Correct output scoping from the provider.
• Resource consumption bounds.
• Any behavioral guarantee about what the provider does with the data it receives.

# Recommendation

Treat custom providers the same way you would treat any external dependency. Review the code. Pin the version. Monitor for vulnerabilities. Consider whether the capability can be expressed by composing Tier 1 primitives or vetted providers before reaching for a custom provider.

# What Termin does not guarantee

This section exists to prevent overclaim. The following are not Termin guarantees.

# Correctness of business logic

Termin does not guarantee that an application does the right thing for its users. An application can be structurally safe and still have incorrect business logic. A help desk that routes every ticket to the wrong team is not a Termin failure — it is a requirements failure.

# Correctness of scope assignments

Termin enforces that declared scopes are checked. It does not enforce that the declared scopes are appropriate for your organization's security policy. If an application grants salary.view to all employees, Termin will check the scope on every access — it will not tell you that the grant is inappropriate.

# Availability and performance

Termin does not guarantee any service level. A runtime can be overloaded, can crash, can run slowly, or can be deployed on infrastructure that fails. Availability is a property of the deployment, not the language.

# Protection against insider threats

An administrator with access to the runtime's data store can read and modify records directly, bypassing the runtime's enforcement. Termin enforces guarantees for applications running on the runtime — it does not prevent abuse by those who control the runtime.

# Protection against compromised dependencies

If a library the runtime depends on has a vulnerability, the runtime inherits that vulnerability. Dependencies should be monitored and updated per normal security practice.

# Long-term storage format compatibility

The IR format follows semantic versioning. Minor-version changes are forward-compatible. Major-version changes may require recompilation. Termin does not guarantee that a .termin.pkg compiled against IR version 0.5 will run on a runtime that only supports IR version 2.0. Runtime version constraints are documented in each package manifest.

# Compliance-regime mapping

Termin is a platform, not a compliance certification. Running a Termin application in a regulated environment remains a deployment question — the operator is responsible for the controls required by the relevant regime.

Several of Termin's structural guarantees map directly to control requirements you would otherwise need to demonstrate with bespoke engineering. The table below is a summary; an auditor still needs to review your specific deployment.

These are mappings, not certifications. The surface area an auditor reviews is smaller and more consistent than in a hand-written application, but the audit itself is still required.

# How to use this page

Developers — read Tier 1 for what you get automatically. Read "What Termin does not guarantee" before you plan around a property. If a property you need is in that section, Termin does not solve it.

Security engineers — this page is the scope of the review. The conformance suite is the evidence. For a Termin application that uses only Tier 1 primitives and vetted Tier 2 providers, the review surface is the runtime itself plus the provider manifests. For Tier 3 custom providers, the review surface includes those providers' code. See /security for the threat model summary and disclosure process.

Product leaders — the claims you can make about a Termin application are the claims on this page. A reasonable public statement: "Our application is built on Termin, an open-source platform whose structural guarantees against SQL injection and broken access control are backed by a public conformance suite. Details at termin.dev/guarantees." Statements that go beyond this page are your responsibility.