Legal
Terms of Service
Effective date: November 8, 2026
Ticinuum is pre-launch. Nothing is purchasable, and nothing can be delivered today.
No deployment model is generally available, no software has been released to any outside party, and nothing in this document is an offer, a quotation, a price, or a statement of availability. We intend to sell two deployment models. A third, the multi-tenant hosted service these Terms govern, is a direction, not an offer. These Terms are published now so that a prospective customer can read, in advance, the agreement that would govern a hosted deployment if and when one is offered. They bind nobody until a Customer accepts them under §0.2, and Ticinuum will not accept an order or a signature against them until the model they govern is offered.
Model Where it stands State Hybrid — Ticinuum operates the control plane, the Customer operates the Executors inside its own network. The lead commercial model. Not governed by these Terms. Nothing architectural blocks it. The Executor is a separate binary that holds no platform database, object-store, cache, analytics, encryption or git-host credential; that property is enforced three ways — by the binary’s own dependency closure, by a start-up refusal triggered on the mere presence of any such variable in its environment, and by the deployment chart. It obtains all authority from an organisation-scoped credential and writes every state change back through an authenticated API. Residency is the Customer’s choice; the default is Ticinuum’s storage. By default artifacts land in Ticinuum’s object storage — a snapshot of the agent’s working tree (git history excluded), written on every human-approval or token-limit pause, alongside diffs, plans, rendered prompts, model-generated summaries, run-log archives and repository surveys. Two shipped controls change that: a data residency policy turns off, per blob family, what Ticinuum stores at all — of fourteen families, nine can be turned off, by preset or individually, and five cannot because a paused run cannot resume without them — refused at the gateway and never produced by the Executor; and bring your own storage points every run artifact, run-log archive, repository survey, attachment and webhook archive at the Customer’s own S3-compatible bucket, with an optional read-only grant for in-app rendering. Under the strictest preset without a bucket of its own, the paused run’s conversation state, plans, summaries and uploaded attachments still land on Ticinuum’s storage; the control plane holds the bucket’s write credential encrypted and signs each upload; bring-your-own-storage is verified at the storage layer and not yet end-to-end or against AWS; and live run-log streaming is a separate switch that defaults on. Not available. Its own agreement is in counsel review and its commercial terms are not set. On-Prem (licensed) — the Customer operates everything. Governed by the separate licence instrument, not by these Terms (§2.2(a)). No production signing key, and no issuance. A signed, offline-verifiable licence file exists: the software reads it, verifies its signature, records what it found, and displays it. That mechanism is warn-only by construction and by test — verification cannot return an error, the licence’s own refuse_startposture is recorded and acted on by nothing, and a deployment running a forged, expired or entirely absent licence behaves identically to a licensed one. It is also inert in a shipped build: the set of signing keys compiled into the binary is empty, so a stock build reports every licence, including a genuine one, as untrusted. The only key that makes verification succeed today is one the operator supplies — which is also how an operator self-issues. There is no key custody, no issuance ceremony, no ordering or entitlement plane, and no buyer-facing distribution path. There is no check-in and no Ticinuum-bound network traffic of any kind, by design.Not available. Multi-tenant hosted SaaS (these Terms) — Ticinuum operates everything, for mutually distrusting tenants. Deferred. Agent sandboxing is designed and not built: the build, test and shell commands an agent runs still execute as unconfined child processes of the agent loop, under the Executor’s own operating-system user, with no kernel boundary, no per-run container, no namespace, seccomp profile, or resource quota. What has changed is the blast radius, not the boundary — an escape no longer reaches platform-wide secrets or any Ticinuum datastore, and one Executor process can only ever be handed one organisation’s work — but no containment control has been built, and the gate has not moved. Not offered. A direction, not a commitment. See the roadmap statement at §2.2(b). What stands between today and an offer is commercial readiness, not architecture or licensing. Every third-party component linked into the shipped binaries carries a licence that permits redistribution, and the release pipeline checks that before it publishes anything. What remains is pricing and an Order Form; the Hybrid Deployment Agreement, which is in counsel review; a production licence-issuance path for On-Prem; the policies these Terms incorporate — the Acceptable Use Policy, the Data Processing Addendum, the subprocessor list and the security policy — which are not yet published; and a first run of the release pipeline. Ticinuum gives no date for any of it.
On the model these Terms govern, specifically. The agent execution environment does not provide isolation between tenants. Customer-supplied build, test and shell commands run as unconfined child processes of the agent loop, under the Executor’s own operating-system user, with no kernel boundary and no per-run container, namespace, seccomp profile or resource quota. That gap, and not credential co-residency, is the reason the model is deferred; the Executor holds no platform datastore or cross-tenant credential, and a registration carries exactly one Organization, so one Executor process is only ever handed one Organization’s work. The residual exposure is many single-Organization Executor processes co-scheduled on one unsandboxed kernel. Ticinuum will not provision a shared hosted account for any customer today, and if a multi-tenant hosted service is ever offered will not provision one for a customer whose threat model requires isolation from other tenants until agent sandboxing ships. See §2.2, §6.11, §11.5 and §12.5.
TERRITORIAL SCOPE: UNITED STATES ONLY AT LAUNCH.
At launch the Hosted Service is offered only to customers established in the United States, for Users located in the United States. Ticinuum does not offer it in the European Economic Area, the United Kingdom or Switzerland and does not direct it to residents of those territories. This is a deliberate commercial scope decision to keep complexity and cost bounded, not a technical barrier; expansion follows the US market. See §0.6.
NO INDEMNITY FOR OUTPUT. READ THIS BEFORE READING ANYTHING ELSE ABOUT RISK.
Ticinuum does not indemnify Customer for anything an Agent generates. There is no output indemnity, no “copyright shield”, no IP-claim defence for generated code, and no undertaking to defend or pay a claim that Output infringes, misappropriates or contaminates a third party’s rights. Output is provided as-is. It may be inaccurate, insecure, non-functional or infringing. The Platform performs no licence scanning, provenance detection or duplication filtering, so Output can reproduce licensed material with no indication that it has.
What Ticinuum does offer is narrower and is capped: an indemnity for Ticinuum’s own platform code — the Hosted Service as Ticinuum wrote it, not what an Agent generates with it — limited to the general liability cap in §13.2, with procure-a-licence / modify-or-replace / refund-and-terminate as Ticinuum’s sole obligation (§14.1, §13.5.1). Customer’s indemnity, by contrast, is uncapped and expressly covers Customer’s use of Output, its repositories and data, its configuration of the guardrails, and its merge decisions (§14.3).
This allocation is stated plainly rather than buried because it is the central commercial term of the agreement, and because it is the one a buyer must price. See §13.0 for why it is drawn this way and §6.4 for the review covenant it is paired with.
HOW PRODUCT CLAIMS ARE MARKED. Product claims in this document are marked: (live) = built, verified, on by default; (opt-in) = built, but off by default (requires a flag, token, election or environment setting); (roadmap) = designed or proposed, not built — never a commitment. The source of truth is the Documentation’s published capability list. Where this document and that list disagree, the list wins and this document is wrong.
Table of contents
- Definitions
- The Service; access rights; deployment models
- Accounts, Organizations and Users
- Orders, subscriptions, trials and early access
- Customer Data and Customer Code
- Artificial intelligence, agents and autonomous action
- Intellectual property
- Third-party services, model providers and BYOK
- Fees, metered usage, billing and taxes
- Term, suspension, termination, export and deletion
- Warranties and disclaimers
- Beta, pre-GA, opt-in and roadmap features
- Limitation of liability
- Indemnification
- Confidentiality
- Publicity and references
- Export control and sanctions
- Government users
- Changes to the Service and to these Terms
- General
0. Parties, acceptance and effective date
0.1 Parties. These Terms of Service (the “Terms”) are entered into between Ticinuum Labs, LLC, a Colorado limited liability company (“Ticinuum”, “we”, “us”), and the entity identified on the applicable Order Form or in the account registration record (“Customer”, “you”). Ticinuum and Customer are each a “party” and together the “parties”.
0.2 Acceptance. These Terms become binding on the earliest of: (a) execution of an Order Form that references them; (b) Customer’s acceptance of them through an online registration or click-through flow; or (c) Customer’s first access to or use of the Hosted Service. The individual accepting represents that they are authorized to bind Customer. If they are not, or if Customer does not agree, Customer must not access the Hosted Service. The parties consent to contract by electronic means, and Customer’s electronic acceptance of these Terms has the same legal effect as a handwritten signature.
0.3 Effective Date. November 8, 2026 or, for a Customer, the date of its first acceptance under §0.2 if later. Last updated: November 7, 2026.
0.4 Consumers. The Hosted Service is offered to businesses and organizations for their business purposes. It is not offered to consumers and must not be used for personal, family or household purposes.
0.5 Relationship to other instruments. These Terms are the master agreement for the Hosted Service. Order Forms, the Data Processing Addendum, the Acceptable Use Policy and any schedule signed by both parties are incorporated by reference. The self-hosted (licensed) and hybrid deployment models are not licensed by these Terms (§2.2): self-hosted is governed by a separate written licence agreement, and hybrid by a separate Hybrid Deployment Agreement, which is in counsel review and is not yet available to sign. Neither of those instruments is extended or varied by these Terms, and no clause here may be read as covering either model by cross-reference. Pre-general-availability participation is governed by the written Pre-GA Program Terms a participant signs; the Early Access waitlist, which grants no product access of any kind, is governed by the Waitlist terms (§4.5). Order of precedence is at §20.10.
0.6 Territorial scope. At launch the Hosted Service is offered only to Customers established in the United States, for Users located in the United States. Ticinuum does not offer the Hosted Service in the European Economic Area, the United Kingdom or Switzerland, does not direct it to residents of those territories, and does not represent that it meets the requirements of any non-US data-protection regime. Customer represents that it is established in the United States and will not permit Users outside the United States to access the Hosted Service without Ticinuum’s prior written agreement. Where the parties do agree to non-US scope, the optional EU/UK annex to the Data Processing Addendum applies and must be executed before any Customer Data of an EU/UK data subject is processed. This §0.6 is a commercial scope decision; it does not limit §17 (export control and sanctions), which applies regardless of where Customer sits.
1. Definitions
Capitalized terms have the meanings below. Terms defined elsewhere in these Terms have the meaning given where defined.
1.1 “Affiliate” means an entity that controls, is controlled by, or is under common control with a party, where “control” means ownership of more than 50% of the voting interests.
1.2 “Agent” means a software process operated by the Platform that issues requests to a Model Provider, interprets the responses, and invokes tools — including reading and writing files in a working copy of a repository, executing shell commands, running tests, creating commits, opening, reviewing, commenting on and merging pull requests, and fetching web content. An Agent is not a person and has no legal authority (§6.9).
1.3 “Agent Run” or “Run” means a single execution attempt of a Work Item by an Agent, recorded as a durable run record with its metrics, logs and artifacts.
1.4 “Approval Gate” or “Gate” means a governance checkpoint in the Platform that holds a Ticket or Work Item pending a decision — including gates of type human approval, policy check, security review and change window — together with the durable human-in-the-loop pause the Agent can itself invoke. Both are time-bounded, and neither proceeds on silence: a typed Approval Gate expires after seven (7) days and expiry is treated as a rejection that closes the Ticket (fail-closed), while the conversational pause is an Ask whose wait ends at the Ask’s answer window — 72 hours by default, configurable per Organization — and whose expiry holds the Run rather than resuming it. Both behaviors are set out in §6.6 and in the Documentation. This definition concerns gates only; the Platform’s separate, unbounded holds — the on-hold flag, the quarantine flag, the Organization halt and the global kill switch — are at §6.6.3(a) and §6.7.
1.5 “Acceptable Use Policy” or “AUP” means the acceptable use policy published at ticinuum.com/acceptable-use before any deployment model is offered, as updated in accordance with §19.
1.6 “Autonomous Action” means any action an Agent takes against a Customer system or a Third- Party Service without a contemporaneous human approval — including committing code, pushing a branch, opening a pull request, submitting a review, posting a comment, and merging a pull request.
1.7 “Beta Feature” has the meaning in §12.1.
1.8 “BYOK” (“bring your own key”) means Customer’s election to supply its own Model Provider API credential for its Organization, as described in §8.5. Read §8.5 before relying on this term: a stored BYOK credential is used only on the Platform’s own auxiliary model calls and is not used on Agent Runs, which run on the credential present in the Executor’s environment (§8.5.1).
1.9 “Confidential Information” has the meaning in §15.1.
1.10 “Customer Code” means source code, configuration, build scripts, tests, binaries and other repository contents belonging to or licensed by Customer that the Platform reads, copies, transmits, modifies or generates changes against. Customer Code is a subset of Customer Data and is Confidential Information regardless of marking (§15.1(b)).
1.11 “Customer Data” means all data, content and materials that Customer, its Users, or a system acting on Customer’s instruction submit to or generate within the Hosted Service. It includes Customer Code, Tickets and their specifications, comments, operator notes, attachments, human-task answers, Inputs, Outputs, Run logs, artifacts, diffs, generated pull-request bodies, captured prompts, conversation transcripts, resume snapshots, mission findings, workstation session metadata ingested under §6.13, and the account and User records described in the Privacy Policy. Customer Data does not include Usage Data (§1.27) or the Platform.
1.12 “Documentation” means the technical documentation Ticinuum makes available for the Hosted Service, including its published capability list and the operator and architecture documents referenced from it.
1.13 “Executor” means the separate Platform process that performs Agent Runs — cloning repositories, running the tool-calling loop, executing Customer-supplied build, test and shell commands, opening pull requests, and metering cost. An Executor obtains its authority from a registration scoped to a single Organization and is only ever handed that Organization’s work; it holds no platform database, object-store, cache, analytics, encryption or git-host credential (§6.11). For fee purposes an Executor is one registered runner process (§9.2), which is the same unit the self-hosted licence agreement licenses. Under the Hosted Service Ticinuum operates the Executors; under the hybrid model the Customer does (§2.2(c)).
1.14 “Feedback” has the meaning in §7.7.
1.15 “Hosted Service” means the Platform as operated by Ticinuum on infrastructure Ticinuum controls, made available to Customer over a network, including the API, the web interface, and the orchestration and Executor roles. It excludes the Self-Hosted Software.
1.16 “Input” means the text, files, repository contents, tool results and other material the Platform transmits to a Model Provider in connection with an Agent Run or an auxiliary model call.
1.17 “Kill Switch” means the Platform control that halts Agent dispatch — globally across all organizations, for a selected set of organizations, or for a single organization — as described in §6.7.
1.18 “Model Provider” means a third party that provides the large-language-model inference used by an Agent Run or auxiliary model call. As of the Effective Date the models are Anthropic’s, and the Platform can reach them over three transports (§8.2.1): Anthropic’s own API (live); Anthropic’s command-line tool against a consumer subscription (opt-in), §8.6; and Amazon Web Services’ Bedrock service (opt-in), §8.2.1 — on which AWS, not Anthropic, is the party that receives the Input, serves the inference and bills for it, and is therefore the Model Provider for those calls. Substitution and notice are governed by §8.7.
1.19 “Order Form” means an ordering document executed by both parties, or an online order Customer completes, that references these Terms and specifies the subscription tier, deployment model, term, fees, the licensed Executors and Concurrent Agent Runs (§9.2), metering basis, and any variables the Order Form is stated to control.
1.20 “Organization” or “Org” means the tenant boundary within the Platform. Tickets, projects, budgets, secrets, integrations, audit records and memberships are scoped to an Organization.
1.21 “Output” means the material an Agent produces, including generated and modified source code, commits, branches, pull-request titles and bodies, code-review text, comments, plans, summaries, reports, mission findings and other artifacts of an Agent Run.
1.22 “Platform” means the Ticinuum software, in all its roles, together with its Documentation, prompts, agent definitions, models of workflow and orchestration, user interfaces, and all improvements to and derivatives of the foregoing.
1.23 “Self-Hosted Software” means the Ticinuum binary and associated materials when deployed and operated on infrastructure Customer controls, under a separate licence instrument (§2.2(a)).
1.24 “Subscription Term” means the period stated on the Order Form during which Customer is entitled to access the Hosted Service, including renewals.
1.25 “Third-Party Service” means a service not operated by Ticinuum that the Hosted Service transmits data to or receives data from at Customer’s direction or as a necessary part of the Hosted Service — including Model Providers and the inference transports at §8.2 (Anthropic; Amazon Web Services, where the Bedrock transport is selected), source-code hosts (GitHub and GitLab, §8.3), transactional email (Postmark), external issue trackers (Jira, Linear), Customer’s own OIDC identity provider where single sign-on is configured (§3.4), any OpenTelemetry collector Customer points the Platform at (§8.4), payment processing (Stripe), where self-serve purchase of capacity is enabled (§9.11), and any host an Agent’s web-fetch tool reaches at a destination the model selected (§6.12).
1.26 “Ticket” means a durable, machine-readable unit of intent in the Platform, together with its specification (goal, success criteria, non-goals, scope, repositories, constraints, inputs, required outputs, validation and execution settings).
1.27 “Usage Data” means data Ticinuum derives from operation of the Hosted Service that does not identify Customer, any User, or any natural person, and does not contain Customer Code, Input or Output — for example aggregate counts of runs, error rates, latency distributions and token volumes. Usage Data is governed by §5.6.
1.28 “User” means a natural person Customer authorizes to access the Hosted Service under Customer’s Organization, including employees, contractors and Affiliates’ personnel.
1.29 “Work Item” means an executable unit derived from a Ticket, executed by one or more Agent Runs.
1.30 “Data Residency Policy” means the per-Organization, per-blob-family election an
Organization administrator records in Settings → Data residency, choosing for each family of
stored object whether Ticinuum stores it (platform) or never produces it (off), by preset or
individually, as described in §5.9.
1.31 “Storage Profile” means an Organization’s verified configuration of its own S3-compatible object-storage bucket, together with the write credential and any read-only credential the Organization supplies for it, to which the Hosted Service routes the Organization’s stored objects as described in §5.9.
1.32 “Workstation Credential” means a revocable credential a User obtains for a workstation client —
an OAuth grant approved in the browser through the tici login flow, or a static credential issued
for CI and hooks — so that an MCP-speaking agent or command-line tool on that machine may act as
that User within one Organization, as described in §6.13.
2. The Service, access rights and deployment models
2.1 Grant of access
Subject to these Terms, the applicable Order Form, and payment of fees, Ticinuum grants Customer a limited, revocable, non-exclusive, non-transferable, non-sublicensable right during the Subscription Term to access and use the Hosted Service for Customer’s internal business purposes, and to permit its Users and its Affiliates’ personnel to do so. Customer is responsible for its Users’ and Affiliates’ compliance with these Terms as if their acts were Customer’s own, and all rights not expressly granted are reserved by Ticinuum (§7.1).
2.2 Three deployment models — what these Terms cover, and what is sellable
The Platform is described in three deployment shapes. These Terms govern only the second. As of the Effective Date none of the three is generally available, nothing is purchasable, and nothing can be delivered. The business intends to sell two of them — self-hosted (On-Prem) at (a) and hybrid at (c), of which hybrid is the lead commercial model. The third, the multi-tenant hosted service at (b) that these Terms govern, is a direction and not an offer. The earlier position, that all three must be complete and ready before launch, is retired; nothing in these Terms may be read as restating it. What stands between today and an offer of either launch model is set out in the pre-launch notice at the head of this document.
(a) Self-hosted / licensed — an intended launch model; not available today. Customer runs every component on infrastructure Customer controls. All Tickets, Run logs, diffs, artifacts, resume snapshots, encrypted credentials and audit records reside in Customer’s own datastores. The Platform performs no call-home of any kind: telemetry export is off unless the operator points it at the operator’s own collector (opt-in), the metrics endpoint is pull-only, and all browser assets are embedded in the binary rather than fetched from a content-delivery network (live). In this model Ticinuum receives essentially no Customer Data and acts as neither controller nor processor of it.
Blocker: no production signing key, and no issuance. A signed, offline-verifiable licence file
exists — the software reads it, verifies its signature, records what it found, and displays it —
but that mechanism is warn-only by construction and by test: verification cannot return an
error, the licence’s own refuse_start posture is recorded and acted on by nothing, and a
deployment running a forged, expired or entirely absent licence behaves identically to a licensed
one. It is also inert in a shipped build, because the set of trusted signing keys compiled into
the binary is empty, so a stock build reports every licence — including a genuine one — as
untrusted. The only key that makes verification succeed today is one the operator supplies, which
is also how an operator self-issues. There is no key custody, no issuance ceremony, no ordering or
entitlement plane, and no buyer-facing distribution path. There is no check-in and no
Ticinuum-bound network traffic of any kind, by design (§17.3).
The undertaking this paragraph used to carry is re-cut, not discharged. It read: Ticinuum will not licence the Self-Hosted Software for production use until either an offline-verifiable licence file or a check-in mechanism ships. That condition has been satisfied on its face — the offline-verifiable file shipped, and the check-in branch was deliberately not taken and is not on the roadmap — but it was written to secure protection against overuse, and a warn-only mechanism with no trusted key provides none. The undertaking is therefore restated on the facts that now govern: Ticinuum will not licence the Self-Hosted Software for production use until (i) a production signing key exists under key custody Ticinuum controls and is compiled into the shipped build, (ii) an issuance path exists by which a Customer receives a licence Ticinuum minted, and (iii) the commercial prerequisites in the pre-launch notice are met. Every representation about overuse rests on self-reporting, audit rights and termination in the separate licence instrument — never on the software, which will not refuse, degrade or disable anything. Self-hosted deployment is licensed under a separate written licence agreement and is not granted by these Terms.
(b) Multi-tenant hosted SaaS (Ticinuum-operated) — governed by these Terms; deferred and not offered. Ticinuum operates the control plane and the Executor. Ticinuum’s systems clone Customer repositories, hold repository write credentials, hold Customer’s Model Provider credentials where BYOK is used, and store Run logs, diffs, captured prompts, conversation transcripts and resume snapshots containing Customer Code.
Blocker: agent sandboxing is designed and not built (roadmap, RFC-0004). The build, test and
shell commands an Agent runs execute as unconfined child processes of the agent loop, under the
Executor’s own operating-system user, with no kernel boundary, no per-run container, no
namespace, no seccomp profile and no resource quota. What has changed since an earlier draft is
the blast radius, not the boundary: an escape no longer reaches platform-wide secrets or any
Ticinuum datastore, and one Executor process can only ever be handed one Organization’s work. No
containment control has been built, and the gate has not moved (§6.11, §11.5).
Roadmap statement. Ticinuum intends, as a matter of product direction, to offer a multi-tenant hosted service in which Ticinuum operates both the control plane and the Executors. It is not offered, not available, and not sold today, and Ticinuum commits to no date for it. This statement describes intended direction only. It is not a commitment to deliver that service, to deliver it in any particular form, scope or capability, or to deliver it at any particular time; it creates no right, warranty, service level or entitlement; no fee payable under any Order Form is consideration for it; and no party may rely on its delivery, its timing or its form in any decision, procurement process, or plan. If Ticinuum offers that service, it will be offered under a separate instrument on the terms then stated, and this instrument confers no right to be offered it.
See the pre-launch notice at the head of this document, §6.11 and §11.5: the Hosted Service is not generally available, and Ticinuum will not represent that tenant workloads are isolated from one another.
(c) Hybrid — the lead commercial model; built, and not yet offered. The shape is a hosted control plane with a Customer-registered Executor: Customer signs up for the hosted control plane and then registers its own Executor running in its own environment. Executors are intended to be distributable as a Helm chart, a container image, a tarball with a systemd unit, and possibly a desktop installer for Windows and macOS.
The blocker this paragraph used to state is gone. The Executor is a separate binary that holds no platform database, object-store, cache, analytics, encryption or git-host credential. That property is maintained three ways — by the binary’s own dependency closure, by a start-up refusal triggered on the mere presence of any such variable in its environment, and by the deployment chart — and the Executor obtains all authority from an organisation-scoped registration credential and writes every state change back through an authenticated API. Each of those three layers is a test rather than a warranty: they bind where CI runs them, and the chart check skips silently when its tool is absent. They are stated as a maintained property, not as a guarantee, and §11.4 is unaffected.
Residency is the Customer’s choice; the default is Ticinuum’s storage. By default artifacts land in Ticinuum’s object storage — a snapshot of the agent’s working tree of the Customer’s repository (git history excluded), written on every human-approval or token-limit pause, alongside diffs, plans, rendered prompts, model-generated summaries, run-log archives and repository surveys. Two shipped controls change that (§5.9): a Data Residency Policy turns off, per blob family, what Ticinuum stores at all — nine of the fourteen families can be turned off, by preset or individually — refused at the gateway and never produced by the Executor; and a Storage Profile points every run artifact, run-log archive, repository survey, attachment and webhook archive at the Customer’s own S3-compatible bucket. Under the strictest preset without a bucket of its own, the paused run’s conversation state, plans, summaries and uploaded attachments still land on Ticinuum’s storage; workstation-attached artifacts are written through Ticinuum’s store only; the control plane holds the bucket’s write credential encrypted and signs each upload; bring-your-own-storage is verified at the storage layer and not yet end-to-end or against AWS; and live run-log streaming to Ticinuum’s infrastructure is a separate per-Organization switch that defaults on. No statement in these Terms, and no statement anywhere else, may say or imply that Customer Code never leaves Customer’s network under this model — the Model Provider receives it on every turn, and what Ticinuum stores is whatever the Customer’s election leaves. Hybrid is not yet offered because its own agreement is in counsel review and its commercial terms are not set, not because of anything in the software.
Hybrid deployment is not available, is not sold, nothing in these Terms may be read as a commitment to deliver it or to deliver it by a date, and no distribution format listed above is a commitment. That this is now the model the business intends to lead with does not make it available, and does not narrow this paragraph. Hybrid is not governed by these Terms. Its own instrument, the Hybrid Deployment Agreement, is in counsel review and is not yet available to sign (§0.5).
2.3 Ticinuum responsibilities
During the Subscription Term Ticinuum will: (a) make the Hosted Service available in accordance with the Documentation, subject to §11 and §12; (b) maintain the technical and organisational measures set out in Annex II of the Data Processing Addendum, or measures providing an equivalent or higher level of protection; (c) provide support at the level, and during the support hours, stated on the Order Form; and (d) comply with laws applicable to Ticinuum’s provision of the Hosted Service. No service-level agreement applies unless an SLA exhibit is attached to a signed Order Form; §12.2 excludes Beta Features from any SLA that is attached.
The security overview published at ticinuum.com/security is informational and is not incorporated into these Terms. It is a candid description of Ticinuum’s posture at a point in time, including the controls it does not have; it is not a warranty, not a specification, and not a maintenance floor, and Ticinuum may revise it as the product changes. The contractual security obligation is limited to §2.3(b) above. Ticinuum operates no facility of its own, so it makes no representation as to physical safeguards beyond those its hosting provider operates (§8.1).
2.4 Customer responsibilities
Customer will: (a) configure the Organization’s execution modes, Approval Gates, budgets, halt controls, repository scopes and branch protections to match its own risk tolerance (§6.5, §6.7); (b) maintain the security of its User credentials and its identity-provider configuration; (c) obtain and maintain all rights, consents and licences necessary for the Platform to process Customer Data and Customer Code and to act on Customer’s repositories; (d) review all Output before merging or deploying it — an affirmative covenant, not a recommendation (§6.4); (e) keep secrets out of repositories, Tickets, comments and attachments (§5.7); (f) use the Hosted Service in compliance with the AUP and applicable law; and (g) promptly notify security@ticinuum.com of any suspected compromise of its account.
2.5 Restrictions
Customer will not, and will not permit any person to:
2.5.1 copy, modify, translate or create derivative works of the Platform, except as expressly permitted;
2.5.2 reverse engineer, decompile or disassemble the Platform, or attempt to derive its source code, except to the extent this restriction is prohibited by applicable law, including non-waivable rights of decompilation for interoperability;
2.5.3 rent, lease, resell, sublicense, time-share, or operate the Hosted Service as a service bureau for a third party, or make it available to anyone other than Users;
2.5.4 use the Hosted Service to build, train or improve a competing product, or to extract the Platform’s prompts, agent definitions, orchestration logic or model configuration for that purpose;
2.5.5 circumvent or disable the Kill Switch, budget breakers, per-run caps, Approval Gates, rate limits, tenant-scoping checks, the Agent’s outbound-request guard (§6.12), or the prompt-injection safety gate, or exceed or circumvent the licensed Executors and Concurrent Agent Runs stated on the Order Form (§9.2) — the two units the Platform enforces where Ticinuum operates the control plane, and which this restriction binds Customer to regardless of whether it does;
2.5.6 perform penetration testing, vulnerability scanning, load testing or red-teaming against the Hosted Service without Ticinuum’s prior written consent, which will not be unreasonably withheld for a scoped test window — except that good-faith security research conducted in accordance with the vulnerability disclosure policy published at ticinuum.com/security is not a breach of this §2.5, is not a breach of §2.6, and does not trigger Customer’s indemnity under §14.3(e) or the cap exclusion at §13.5(c);
2.5.7 point the Hosted Service at repositories, systems or accounts Customer is not authorized to modify, or grant an Agent credentials whose scope exceeds what the engagement requires;
2.5.8 configure a Model Provider endpoint other than one Ticinuum has approved in writing, or otherwise redirect Input to a destination Ticinuum has not disclosed as a Third-Party Service; or
2.5.9 use the Hosted Service in violation of the AUP.
2.5.10 Benchmarking. Customer may publish performance or quality measurements of the Hosted Service, provided the publication states the version tested, the configuration and model used, the tasks and repositories used, the metering basis, and enough methodological detail for a third party to attempt replication. Ticinuum asks for, but does not require, an opportunity to review for factual accuracy before publication.
2.6 Acceptable Use Policy
The AUP is incorporated into these Terms. It governs both conventional service abuse and agent-specific conduct — including directing an Agent at systems Customer does not control, using an Agent to generate malware or to exfiltrate data, and using the Platform to circumvent another party’s access controls. Ticinuum may update the AUP under §19.2. A material breach of the AUP is a material breach of these Terms.
2.7 Suspension
Ticinuum may suspend Customer’s access to the Hosted Service, in whole or in part, or halt Agent dispatch for Customer’s Organization, where: (a) continued operation poses a material security risk to the Hosted Service, to Ticinuum’s other customers, or to a third party; (b) Customer’s use violates the AUP or §2.5; (c) Ticinuum is required to do so by law or by a Third-Party Service; or (d) fees are overdue under §9.7. Ticinuum will give notice before suspending where practicable, will limit the suspension to what the cause requires, and will restore access promptly once the cause is resolved. Suspension does not relieve Customer of payment obligations except where the suspension results from Ticinuum’s own material breach.
3. Accounts, Organizations and Users
3.1 Registration. Customer creates an account by providing accurate, current and complete registration information and keeping it current, and Ticinuum may rely on that information. Self-service signup is a (opt-in) capability that is off by default; where it is enabled, an account is created only after a double-opt-in email confirmation completes.
3.2 Organizations and memberships. Access is scoped to an Organization. A person holds a distinct role in each Organization they belong to; identity is global to the Platform but authorization is per-Organization (live).
3.3 Roles. The Platform enforces a four-level role hierarchy — system administrator, organization administrator, user, viewer — at both the API and the web interface (live). Customer is responsible for assigning roles appropriately and for reviewing them periodically. Certain controls in these Terms (halting execution, approving a quarantined Ticket, rotating a stored credential, changing budgets) are available only to organization administrators.
3.4 Single sign-on. Customer may bind its Organization to an OIDC identity provider, with email-first realm discovery and just-in-time provisioning behind a verified-domain check (live). SCIM provisioning and de-provisioning is not built (roadmap); removal of a User’s access is performed through the Platform’s membership controls or through the identity provider.
3.5 Ticinuum administrative access. Ticinuum personnel with the system-administrator role can read audit records across Organizations and operate platform-wide controls. Ticinuum limits this access to personnel who need it to operate, support and secure the Hosted Service, and every such action that the Platform records as an auditable event is attributed to an actor (live). Ticinuum does not access Customer Code except as necessary to provide, support or secure the Hosted Service, to comply with law, or at Customer’s request.
3.6 Account security. Customer is responsible for all activity occurring under its Users’ credentials, including every Workstation Credential a User obtains (§6.13), whether or not authorized by Customer, and will promptly notify Ticinuum of any known or suspected unauthorized use of its account or credentials. Customer is responsible for maintaining the confidentiality and security of its credentials, identity-provider configuration, repository access grants and the machines on which its Users hold Workstation Credentials, and Ticinuum is not liable for any loss arising from Customer’s failure to do so. A Workstation Credential can be revoked by its holder or by an Organization administrator at any time, and revocation takes effect immediately.
4. Orders, subscriptions, trials and early access
4.1 Order Forms. Each Order Form specifies the subscription tier, deployment model, Subscription Term, platform fee, the licensed Executors and Concurrent Agent Runs (§9.2), metering basis and rates, any included usage allotment, and any variables the Order Form is stated to control (including any cap variable under §13). An Order Form takes effect when executed by both parties or, for an online order, when Ticinuum confirms it.
4.2 Subscription Term and renewal. The initial Subscription Term is stated on the Order Form. Unless the Order Form says otherwise, the subscription renews for successive periods equal to the initial term unless either party gives written notice of non-renewal at least thirty (30) days before the end of the then-current term.
4.3 Adding capacity. Customer may add licensed Executors, Concurrent Agent Runs or usage allotments mid-term through an additional Order Form, co-terminous with the existing term and prorated unless otherwise agreed. Pricing is not per-seat; users, projects and repositories are unlimited and are never a basis for a fee, so the Platform’s commercial model prices governed work, not headcount. Where the self-serve path at §9.11 is enabled, capacity may also be added by subscription without an Order Form, on the terms stated there — which differ from this §4.3 on term, proration and cancellation.
4.4 Trials and evaluation access. Ticinuum may make the Hosted Service available at no charge or at a reduced charge for evaluation. Evaluation access is provided as-is, carries no warranty, no SLA and no support commitment, may be modified, limited or withdrawn at any time without liability to Customer, and ends on the earlier of the stated evaluation end date or Customer’s entry into a paid Order Form. Ticinuum’s total liability for evaluation access is limited as set out in §13.3. Sections 5, 6, 7, 11, 12, 13, 14, 15 and 20 apply in full to evaluation access.
4.5 The Early Access waitlist, pre-GA programs and design-partner engagements. Three different instruments sit here and they must not be confused:
4.5.1 The Early Access waitlist grants no product access. “Early Access” is a waitlist only — an email address submitted through a marketing website, together with demo material and correspondence. It confers no login, no account, no hosted environment, no software, and no right to any of them, and being on the list is not an offer or a promise of future access. It is governed solely by the Waitlist terms. These Terms do not apply to a waitlist member and are not accepted by joining the list.
4.5.2 Pre-GA programs. A curated subset of waitlist members may, after meetings and qualification, be invited into the Design Partner or Founding Customer programs. Software terms for those programs — no warranty, no SLA, no uptime commitment, the right to change or withdraw capabilities, data-loss risk, autonomous-agent behavior and the customer’s duty to keep approval gates and spend caps configured, the feedback licence, confidentiality of pre-release features and roadmap, and conversion at general availability — are carried by the Pre-GA Program Terms, which those agreements incorporate by reference.
4.5.3 Precedence. Where Customer has signed a design-partner or founding-customer agreement, that instrument governs that engagement, including its term, fees, liability cap, notice periods and confidentiality survival, and controls over these Terms as to that engagement (§20.10). These Terms govern any hosted access that is not covered by such an instrument.
4.6 Free tiers. Any free tier Ticinuum offers is subject to usage limits stated in the Documentation, may be changed or discontinued on notice, and carries the same disclaimers as evaluation access under §4.4.
5. Customer Data and Customer Code
5.1 Ownership
As between the parties, Customer owns and retains all right, title and interest in and to Customer Data and Customer Code, including all intellectual property rights in them. Nothing in these Terms transfers ownership of Customer Data or Customer Code to Ticinuum. Output is addressed separately at §7.3.
5.2 Licence to operate
Customer grants Ticinuum and its subprocessors a non-exclusive, worldwide, royalty-free, fully paid and (solely to Ticinuum’s subprocessors, for the purposes below) sublicensable licence, during the Subscription Term and for the limited post-termination periods in §10, to host, copy, store, cache, transmit, display, transform and otherwise process Customer Data and Customer Code solely to: (a) provide, maintain, secure and support the Hosted Service; (b) execute the Tickets, Work Items and Agent Runs Customer initiates or configures, including transmitting Input to a Model Provider and writing to repositories through a source-code host as Customer has authorized; (c) prevent and investigate abuse, security incidents and violations of the AUP; and (d) comply with law. Customer represents and warrants that it has all rights, consents, licences and authority necessary to grant this licence and to have the Hosted Service process Customer Data and Customer Code and act on the repositories in scope, and Ticinuum may rely on Customer’s instructions, authorizations and configuration without independently verifying Customer’s rights. This licence is limited to the foregoing purposes and grants no other right, except that it is irrevocable to the extent necessary to give effect to actions lawfully taken before termination and to the records Ticinuum is permitted to retain under §5.6, §10.6 and §15.
5.3 What the Hosted Service actually does with Customer Code
Customer should understand the following as facts about how the Platform operates, not as disclaimers. Each is verifiable in the Documentation.
| Flow | What happens | Fence |
|---|---|---|
| Repository clone | The Executor clones the repository into a per-run working directory and deletes it on cleanup | (live) |
| Model transmission | Tool results — file contents, command output, test output, diffs — are appended to the model conversation and the entire conversation is re-sent to the Model Provider on every turn, so a substantial portion of the repository can cross to the Model Provider over a Run | (live) |
| Server-side web search | The Model Provider’s own web-search tool is enabled for Agent Runs by default, so search queries derived from Customer context leave through the Model Provider’s search infrastructure | (live), default on |
| Prompt capture | The fully rendered system and user prompts, including interpolated Ticket text, are stored as artifacts | (live), default on |
| Paused runs | On a human-in-the-loop, token-limit or iteration-limit pause, a snapshot of the working tree (git history excluded) is archived unless the Organization’s Data Residency Policy turns that family off, and the full conversation transcript — including all tool results — is stored durably in object storage in every case; both land in Ticinuum’s bucket by default or in Customer’s own bucket under a Storage Profile (§5.9) | (live), default on |
| Diffs, logs | The unified diff and the Run log are stored as artifacts (the generated pull-request body goes to the git host and is not stored as an artifact); Run logs are also held transiently in the cache layer with a 48-hour expiry measured from the last log line | (live) |
| Injection scanning | Every agent-visible Ticket field is sent to a classifier model on create and update, before any dispatch | (live) |
| Intake triage | Before a Request becomes a Ticket, one short model call reads it to say where it belongs; it is metered, scanned for injection first, and an Organization may turn it off | (live), default on |
| Repository context | The Platform reads the repository’s own agent-context files on its default branch, and unless the Organization turns the survey off an Agent surveys the repository before starting a Ticket | (live), default on |
| Embeddings | Where an Organization elects it, Ticket, comment, finding, Request and Initiative text is sent to an embedding provider (Voyage AI) for similarity search, and the vectors and a copy of the embedded text are stored | (opt-in), off by default |
| Mission findings | Where autonomous missions are used, findings include a verbatim code excerpt (truncated) and file/line reference, stored in the analytics stream | (live) |
Customer acknowledges, accepts and assumes the risk of the data flows described in this §5.3. Transmission of Customer Code to the Model Provider is inherent in the Hosted Service and cannot be disabled while the Hosted Service functions. These data flows are inherent characteristics of the Hosted Service, are disclosed here in full, and are not defects or breaches of any Ticinuum obligation. Prompt capture and server-side web search can be turned off by configuration, and so — per blob family, under the Data Residency Policy in §5.9 — can the storage of workspace snapshots, diffs, rendered prompts, run-log archives, executor reports, repository surveys, webhook archives, finding evidence and workstation-attached artifacts. Conversation state, plans, summaries and attachments cannot be turned off, but every stored object can be routed to Customer’s own bucket under a Storage Profile (§5.9). Customer is solely responsible for configuring the Hosted Service to match its own data-handling requirements.
5.4 No training on Customer Data — Ticinuum’s own conduct, and what is not represented
(a) Ticinuum’s commitment. Ticinuum does not use Customer Data, Customer Code or Output to train, fine-tune, benchmark or otherwise improve any machine-learning model. No training, fine-tuning, evaluation-set or benchmarking export path exists anywhere in the Platform. Ticinuum will not create one without amending these Terms under §19.2. This commitment does not restrict: (i) Ticinuum’s use of Usage Data under §5.6; or (ii) processing that is strictly necessary to provide, secure and support the Hosted Service, including abuse detection and incident response.
(b) What Ticinuum does not represent about the Model Provider. Ticinuum makes no representation as to whether the Model Provider trains on, retains, or human-reviews Input or Output, and Customer must not assume zero retention or a no-training term. Whether such a term exists depends on the agreement in force between Ticinuum and the Model Provider; as of the Effective Date no such term has been confirmed, and the Platform sets no zero-retention or no-training header on its API calls. Ticinuum will state the position expressly, in the subprocessor list at ticinuum.com/subprocessors and in the Data Processing Addendum, once the term is executed — and only then. Where a Model Provider term is executed, Ticinuum will not knowingly enable a provider-side feature that retains Input or Output for model-improvement purposes; that is a forward commitment conditional on the term, not a present representation.
(c) Server-side provider tools. The Model Provider’s own server-side web-search tool is enabled for Agent Runs by default (live) and its queries execute on the provider’s infrastructure under the provider’s terms, which Ticinuum does not hold and cannot flow down. Customer may disable it by configuration (§8.2).
(d) BYOK. Where a call runs on a credential Customer supplied (§8.5), Customer’s own agreement with the Model Provider governs what that provider may do with Input and Output. Ticinuum makes no representation about the terms attached to a credential Customer supplies. Customer must not read this limb as covering Agent Runs: a stored BYOK credential is used only on the Platform’s auxiliary model calls, so under the Hosted Service the Input and Output of an Agent Run are governed by Ticinuum’s own provider relationship and by §5.4(b), not by Customer’s (§8.5.1). BYOK is additionally inoperative on the subscription-CLI backend described at §8.6, and a stored Anthropic credential has no application at all where the Bedrock transport is selected, because that transport authenticates to AWS (§8.2.1).
5.5 Aggregation across Organizations
Ticinuum does not combine one customer’s Customer Data with another’s, and does not disclose one customer’s Customer Data to another. Analytics within the Hosted Service are scoped to the requesting Organization; the sole cross-Organization read path is the operator audit view described at §3.5.
5.6 Usage Data
Ticinuum may collect, generate and use Usage Data to operate, secure, support, analyze and improve the Hosted Service and Ticinuum’s other current and future products and services, and may create, use, retain and publish aggregated and de-identified statistics, models and benchmarks derived from it, during and after the Subscription Term. Usage Data must not identify Customer, any User or any natural person, and must not contain Customer Code, Input or Output. As between the parties, Ticinuum exclusively owns all Usage Data and all aggregated and de-identified materials derived from it, and no such use is restricted by §5.4. This §5.6 survives expiry or termination.
5.7 Customer’s content responsibilities
Customer is solely responsible for Customer Data and Customer Code, including their legality, accuracy and the rights to use them. In particular Customer will:
5.7.1 not store live credentials, private keys, or other secrets in repositories, Tickets, comments, operator notes or attachments that an Agent can read. The Platform applies a best-effort pattern-based scrub to log and diff output; this is not a data-loss-prevention control, tool output is not scanned before it enters the model conversation, and Customer must not rely on it;
5.7.2 not submit personal data beyond what is necessary, and not submit special categories of personal data, payment card data, protected health information, or data subject to export-controlled or classified handling requirements, unless a written addendum permits it;
5.7.3 scope repository access grants to the minimum required, and maintain branch protection rules and required-review settings on any branch whose contents Customer is unwilling to have changed without human review; and
5.7.4 treat Tickets, imported issues, webhook payloads, pull-request comments and repository contents as untrusted instruction channels (§6.8); and
5.7.5 Credentials in the execution environment — the case §5.7.1 does not reach. §5.7.1 is
about secrets stored in repositories and Tickets. This limb is about secrets present at
runtime, which is where they actually live. The Platform executes Customer-supplied shell, build
and test commands (§5.3, §6.1), and an Agent may invoke any command-line tool reachable in that
environment — including one already holding live credentials (for example aws, gcloud,
kubectl, terraform, gh, npm publish, or a CI token materialised into the environment by
Customer’s own build). Nothing in the Platform bounds what such a tool may reach. Customer will
therefore not make available in the execution environment any credential, token, role or
ambient-identity grant whose scope exceeds the repositories in scope for the Ticket, and will
prefer short-lived, least-privilege credentials scoped to the Ticket. Customer’s compliance with
this §5.7.5 is warranted at §11.3(f) and indemnified by Customer at §14.3(h).
5.7.6 Sole responsibility and assumption of risk. Customer is solely responsible for, and assumes all risk arising from, Customer Data and Customer Code and the instructions, configurations, credentials and repositories it directs or permits the Hosted Service to act on. Ticinuum has no obligation to review, validate, correct, filter or monitor Customer Data or Customer Code, and no such obligation may be implied. Customer’s failure to comply with this §5.7 is not a breach by Ticinuum and gives rise to no Ticinuum liability, and any claim arising from Customer Data, Customer Code or Customer’s breach of this §5.7 is within Customer’s indemnity under §14.3.
5.8 Data protection
Where the Hosted Service processes personal data on Customer’s behalf, the Data Processing Addendum at ticinuum.com/dpa applies and is incorporated by reference. It sets out the processing instructions, subprocessor authorization and notice mechanism, security measures, breach notification, and assistance with consumer- and data-subject requests. The current subprocessor list, including Model Providers, is published at ticinuum.com/subprocessors. Both are published before any deployment model is offered.
Governing regime at launch. Consistent with the US-only territorial scope at §0.6, the Data Processing Addendum is anchored on CCPA/CPRA service-provider terms and the other US state privacy laws as its primary regime: Ticinuum is a service provider (and not a third party) processing Customer’s personal information solely to perform the Hosted Service, and does not sell it, share it for cross-context behavioural advertising, retain, use or disclose it for any purpose other than the business purposes the Data Processing Addendum specifies.
EU/UK is an optional annex, not the default. The GDPR machinery — the Standard Contractual Clauses, the UK International Data Transfer Addendum and the Art. 28 mapping — is retained in a clearly-labelled optional annex to the Data Processing Addendum, marked not offered at launch; available if the parties agree to EU/UK scope (§0.6). It is retained rather than deleted because US enterprise procurement frequently requires a GDPR-shaped addendum even for a purely domestic deal. Executing that annex is what brings the EU/UK terms, and the international transfer mechanisms, into force; absent execution they do not apply.
Data protection enquiries go to privacy@ticinuum.com. No EU/UK
representative or data protection officer is appointed: one is appointed only if and when the
optional annex is executed, and none is required while §0.6 holds. The hosted control plane runs
on Google Cloud in the us-central1 region (Iowa, United States), and its object storage is
Google Cloud Storage.
5.9 Data residency policy and storage profiles — the Customer’s residency election
5.9.1 What is stored, and where, by default. §5.3 lists what the Hosted Service stores. Every stored object belongs to one of fourteen blob families — the workspace snapshot, the conversation state, the diff, the plan, the summary, the rendered prompt, the Run-log archive, executor reports (change-surface, test and deploy reports), the repository survey, uploaded attachments, webhook archives, Ticinuum’s own prompt templates, finding evidence (screenshots and traces) and workstation-attached artifacts — and by default every family lands in Ticinuum’s object storage. The workspace snapshot excludes the repository’s git history.
5.9.2 The Data Residency Policy. An Organization administrator may, in Settings → Data
residency, set a family’s mode to off, individually or by preset. The Standard preset
changes nothing; Restricted turns off workspace snapshots, diffs, repository surveys and
webhook archives; Minimal turns off every family that can be turned off — Restricted plus
rendered prompts, the Run-log archive, executor reports, finding evidence and workstation-attached
artifacts. An off family is refused by the Platform when an Executor asks to store it and is
never produced by the Executor at all. Five families cannot be turned off because the Service
cannot function without them — the conversation state, plans, summaries, uploaded attachments and
Ticinuum’s own prompt templates — and those land in Ticinuum’s storage unless a Storage Profile is
in use. Before the Platform accepts a change it shows, in prose, what stops working and what still
works; a change is not retroactive — turning a family back on recovers nothing from Runs that
already happened — and the Platform says so before the change is accepted. Every change is audited
with the family, the old and new mode, the actor and the time. Customer acknowledges that a family
it turns off degrades the Hosted Service in exactly the way the pre-change disclosure describes;
that an Executor must be at a version that understands the policy before a Run in that
Organization is dispatched to it; and that live Run-log streaming is a separate, default-on,
per-Organization setting (“Stream run logs live”) that the policy does not turn off.
5.9.3 The Storage Profile. An Organization administrator may configure a Storage Profile — the endpoint, region, bucket and path prefix of an S3-compatible bucket Customer operates, with a write credential and, optionally, a read-only credential. The Platform verifies the profile by a screened round trip before using it, re-verifies it on demand and, where enabled, on a schedule, and does not use a profile that fails verification. Once verified, every object the Hosted Service would have stored for that Organization is written to, and read from, Customer’s bucket instead: run artifacts of every family, Run-log archives, repository surveys, attachments and webhook archives. Objects stored before verification stay where they were and remain readable; nothing is migrated. Customer acknowledges each of the following:
(a) the Platform holds the write credential encrypted and decrypts it to sign each upload.
The Executor never receives it and the Platform never proxies the bytes, but “Ticinuum never holds
our storage credential” is not a statement this design supports;
(b) without a read-only credential the Hosted Service renders references only for stored
objects — type, key, size, timestamps and lineage — and offers to render content if one is
supplied; a read-only credential is used solely to sign short-lived read URLs for signed-in members
of the Organization, and whether it is genuinely read-only is enforced by Customer’s own access
policy, which the Platform can test for but cannot prove;
(c) the profile is Organization-wide — it cannot route one family to Customer’s bucket and another
to Ticinuum’s — and it supports S3-compatible storage only;
(d) while a Storage Profile is in use, a child Agent cannot read its parent’s plan, so planner
decomposition is degraded until the Platform converts that read path;
(e) bring-your-own-storage is verified at the storage layer — against a local S3-compatible
store, including that the bucket itself refuses an object above a family’s size ceiling — and
not yet end-to-end, and not yet against Amazon S3 or any third-party backend;
(f) Customer’s bucket is Customer-operated infrastructure: its unavailability, a revoked or
rotated write credential, or an access policy that refuses a write fails the affected Runs, is
outside any service level Ticinuum offers, and is Customer’s to keep working; retention of what
lands in Customer’s bucket is Customer’s own; and
(g) workstation-attached artifacts are written through Ticinuum’s store only and never route to
Customer’s bucket, so their only residency control is the off mode at §5.9.2.
5.9.4 What the election does not change. A Data Residency Policy and a Storage Profile govern stored objects. They do not change what the Model Provider receives (§5.3), what the control plane holds as records — Tickets, comments, events, metrics, audit rows and object references — or whether live Run-log lines are streamed. Ticinuum will describe Customer’s residency position only in the terms of this §5.9 for the election actually in force, and will not represent that Customer Code never leaves Customer’s network (§2.2(c)).
6. Artificial intelligence, agents and autonomous action
This section is the operative allocation of risk for the Platform’s agentic behavior. It should be read together with §11 (warranties), §13 (liability) and §14 (indemnities).
6.1 How the Agent operates
An Agent Run executes a loop: the Platform sends Input to a Model Provider; the model requests a tool call; the Platform executes it against a working copy of Customer’s repository or against a Third-Party Service; the result is fed back; the loop repeats until the Work Item completes, a bound is hit, or a human intervenes. Tools available to a coding Agent include reading and writing files, executing shell commands, running tests, fetching web content, creating commits, and opening, reviewing, commenting on and merging pull requests. Shell commands, build steps and tests defined in Customer’s repository are executed by the Platform. Autonomous mission Agents are read-only with respect to the repository: their tool policy denies commit and pull-request creation, and their durable output is findings and Tickets (live).
6.2 Output is machine-generated, is provided as-is, and is not warranted
Output is generated by a statistical model. Output is provided AS-IS. Generated code may be inaccurate, insecure, non-functional or infringing. Ticinuum does not warrant that Output is correct, complete, secure, functional, performant, original, non-infringing, or fit for any purpose, and Ticinuum does not indemnify Customer against any claim arising from Output (§14.2). Customer assumes all risk of, and is solely responsible for, any use of Output. Customer acknowledges that the following failure modes are inherent to the technology and are not defects in the Hosted Service, and that this list is illustrative and not exhaustive:
(a) Factual and logical error. Generated code may be wrong, may not compile, may pass tests while being incorrect, or may silently change behavior the Ticket did not contemplate.
(b) Insecure patterns. Generated code may introduce injection flaws, unsafe deserialization, weak cryptography, authorization gaps, or other vulnerabilities, and may do so in code that looks idiomatic.
(c) Hallucinated dependencies and APIs. Generated code may import packages that do not exist, call APIs that do not exist, or pin versions that do not exist — including package names that an attacker could subsequently register.
(d) Open-source licence contamination. Output may reproduce or closely resemble code from training data, including code under copyleft or attribution-requiring licences, without any indication of provenance and without the required notices. The Platform performs no licence scanning, provenance detection or duplication filtering. Customer must run its own licence and provenance controls in its pipeline.
(e) Non-determinism. The same Ticket run twice may produce materially different Output. Model behavior changes when the Model Provider updates, deprecates or reweights a model, and Ticinuum does not control that.
(f) Similarity across customers. Output is not exclusive. Similar or identical Output may be produced for other customers from similar Inputs.
(g) Non-copyrightability. Material generated without sufficient human authorship may not attract copyright protection in some jurisdictions. Ticinuum makes no representation that Output is protectable, and Customer should not assume that it is (§7.4).
6.3 Not advice
Output — including security findings, review comments, architectural recommendations, mission findings and generated documentation — is not legal, security, compliance, financial, medical or professional advice, and is not a substitute for qualified human judgment or for Customer’s own testing, review and assurance processes. Any reliance on Output is at Customer’s sole risk.
6.4 Human review — an affirmative Customer covenant
6.4.1 The covenant. Customer will review all Output before merging or deploying it. In particular, Customer will review Output before merging it into any branch that reaches a production, customer-facing, or otherwise consequential system, and before deploying or executing it outside a disposable environment.
This is an affirmative covenant of Customer, not a recommendation and not a disclaimer. It is an obligation Customer owes under these Terms, and a Customer that merges or deploys unreviewed Output is in breach of this §6.4. Ticinuum provides the Hosted Service, and prices it, in reliance on Customer’s performance of this covenant. Consequently:
(a) breach of this §6.4 is a breach of these Terms and is a Customer warranty breach under §11.3(d);
(b) Customer’s failure to comply is a defence, and a ground for apportionment, against any claim Customer brings against Ticinuum arising from Output that a competent review would have caught; and
(c) anything arising from Customer’s merge or deployment of Output — reviewed or not — is within Customer’s uncapped indemnity at §14.3(b). Ticinuum owes no indemnity for Output in any event (§14.2), so this §6.4 is not a condition of a Ticinuum Output indemnity; there is none to condition.
Customer determines how it discharges this obligation — code review by a qualified person, static and dynamic analysis, licence and provenance scanning, dependency verification, tests, staged rollout, or a combination.
6.4.2 The human-approval architecture — stated factually, including its limits. The Platform is built so that a chain of human decisions can sit between Output and any consequence, and — where Customer configures it to — does. Customer should understand exactly what that chain is and is not:
- Customer configures the gates. Execution mode, Approval Gates, budgets, repository scopes and branch protections are Customer’s settings, not Ticinuum’s (§2.4(a), §6.5.4, §11.3(c)). Whether a human approval is required at all is Customer’s execution-mode decision (§6.5).
- Where a human approval is required, a human gives it. A supervised Ticket creates a typed human-approval gate that a person must clear before the change can settle (live), and the background dispatch loop’s automatic reconciliation never merges an unapproved pull request — it only completes a Ticket whose pull request a person already merged out of band (live).
- By default the Platform does not merge an autonomous Ticket’s pull request on its own. An approved autonomous Ticket waits in review for a person’s Merge unless the Organization has elected agent merge — off by default, recorded against a disclosure, lapsing ninety (90) days after it is recorded, and unavailable to an Organization with GitLab repositories (opt-in). A Ticket a human gate approved is never held back by that election, and a revert is always merged by a person.
- Separation of duties applies to that approval. The approver cannot be the Ticket’s author (reporter) or its owner; approval requires a second person (live). One principal cannot drive an attacker-influenced or unreviewed diff from Ticket to merge end to end. The one exception is an Organization with no second eligible person: its sole administrator may approve, and the Platform records that self-approval as an audit event before it takes effect (live).
- An Agent approval is not a human approval. The independent review step performed by a second Agent under a separate identity is not a human decision and is not treated as one (§6.5.3).
- A one-off “send to agent” revision run merges the pull request as its post-step, but that run happens only because a person invoked it on that Ticket (live).
Ticinuum does not overstate this. Four honest limits qualify it, and Customer must read them in the same breath:
(i) A typed Approval Gate expires after seven (7) days and expiry closes the Ticket (§6.6.1, §1.4). The chain is time-bounded; a gate is not an indefinite pause awaiting a human.
(ii) Autonomous is the system-wide default execution mode (live), and an autonomous Ticket is groomed, implemented, reviewed by a second Agent and revised with no human in the loop unless Customer changes the default or the per-Ticket mode (§6.5). No typed human-approval gate is created for an autonomous Ticket. By default its pull request then waits for a person’s Merge; where the Organization has elected agent merge, the merge proceeds on the second Agent’s review, which is not a human approval. The human-approval chain described above is the chain that operates when Customer has configured it to operate.
(iii) Branch protection and required-review rules on the source-code host are the only review control Ticinuum cannot override (§6.5.2, §6.6.3). The Platform’s holds stop work from starting; they do not stop an already-generated diff from being merged.
(iv) A default deployment starts no work on its own (live). Work starts when a person asks for it, when a patrol an administrator scheduled fires, or when a plan a person started releases its children. The Platform’s background dispatch loop, and every other start a person did not cause — an agent-created Ticket, a finished groom, a dependency cascade — are off by default and two-tier: a system administrator exposes the capability, and an Organization administrator elects it against a disclosure whose acceptance is recorded (opt-in). Where elected, the loop promotes, dispatches and grooms eligible Tickets on a cadence under a work-in-progress limit and spends against Customer’s budget without a human triggering each action; it is bounded by the stop controls at §6.7 — the kill switch, the halts, the budget breaker, the on-hold and quarantine flags, and per-Organization and per-cycle caps — and it never merges an unapproved pull request.
None of §6.4.2 dilutes §6.4.1. The architecture is a support for Customer’s covenant, not a substitute for it, and Ticinuum warrants nothing about Output on the strength of it (§6.2, §11.4).
6.5 Execution modes and defaults — read this clause carefully
The Platform supports three execution modes per Ticket: manual, supervised, and autonomous.
An autonomous Ticket runs the pipeline — grooming, implementation, a second Agent’s review and revision — with no human in the loop, and by default stops before the merge: the resulting pull request waits for a person’s Merge unless the Organization has elected agent merge (§6.4.2). Autonomous is the Platform’s system-wide default for newly created Tickets (live). An Organization administrator may set the Organization’s default to supervised in the Organization’s safety settings, and a Ticket’s mode may be set per Ticket.
Customer therefore acknowledges and agrees that:
6.5.1 unless Customer changes the Organization default or the per-Ticket mode, changes an Agent authors may be committed, pushed and reviewed by a second Agent without any human approval, and — where the Organization has elected agent merge — merged without one;
6.5.2 the source-code host’s own controls — branch protection, required reviewers, required status checks, CODEOWNERS, environment protection rules — are the enforcement layer Customer controls independently of Ticinuum, and Customer is responsible for configuring them;
6.5.3 the independent review step is performed by a second Agent under a separate identity, not by a human, and an Agent approval is not a human approval (live); and
6.5.4 Customer warrants that its configuration of execution modes, Approval Gates, budgets, repository scopes and branch protections reflects Customer’s own risk decision. Misconfiguration by Customer is Customer’s responsibility and is indemnified by Customer under §14.3.
6.6 Approval Gates and the two human-in-the-loop timeouts — read this clause carefully
The Platform provides two distinct in-workflow human-oversight controls. Both are time-bounded. Neither of these two blocks indefinitely, and neither lets a Run proceed on silence; Customer must understand what each does at its bound before relying on either. This is a statement about gates, not about the Platform as a whole: the Platform’s holds are unbounded, and §6.6.3(a) lists them.
| Control | What it is | Bound | What happens on expiry |
|---|---|---|---|
| Typed Approval Gate (human approval, policy check, security review, change window) | A governance checkpoint that holds the Ticket pending a decision | 7 days (live) | Fails closed — expiry is treated as a rejection and the Ticket is CLOSED |
| Conversational pause (an Ask) | An Agent’s in-run question to a person, which suspends the Work Item and resumes the same Run once answered (live) | The Ask’s answer window — 72 hours by default, configurable per Organization from 1 hour to 30 days, or the window the asker names (live) | Holds — the Run ends with a hold that a late answer releases. An Ask may instead be set to escalate once with a fresh window, kick the work back or decline it; only a safe default its asker named in advance lets the Run proceed, and never while the Kill Switch is on or the Organization’s budget is exhausted |
6.6.1 Approval Gates expire; they do not hold forever. An Approval Gate left pending for seven days is treated exactly as a rejection: the Ticket is closed. This is fail-closed and is defensible as a safety default, but the practical consequence is not intuitive — a Customer who leaves a gate pending over a holiday or a vacation loses the Ticket rather than keeping the Run parked. Any statement, in any Ticinuum document or conversation, that typed gates “do not auto-resolve” or “block indefinitely” is incorrect; this §6.6.1 governs.
6.6.2 The conversational pause does not proceed on silence. If no person answers an Ask within its window, the Run does not continue on its own: it ends with a hold, or takes the escalate, kick-back or decline action the Ask was given, and a late answer can release the hold. The one way a Run carries on is a safe default an Agent named when it asked, which the asker chose in advance and which is disabled while the Kill Switch is on or the Organization’s budget is exhausted. An Ask is still time-bounded and is not a hold a person must clear; Customer must not treat it as a review control.
6.6.3 What an actual hard stop is — unbounded holds exist; unbounded gates do not. The correct distinction, and the one Customer must carry away from §6.6 and §6.7, is between a hold and a gate:
(a) Unbounded holds do exist, and there are five of them. Each blocks dispatch and grooming for as long as it is set, with no timer anywhere in the Platform — nothing expires them, nothing retries past them, and only a person clears them (live): the Ticket’s on-hold flag; the Ticket’s prompt-injection quarantine flag; the per-Organization halt; the cross-Organization halt; and the global kill switch. Cancelling the Ticket is a sixth durable stop and is terminal rather than a hold. Any statement, anywhere in this suite, that the Platform has no unbounded stop is incorrect; this §6.6.3 governs.
(b) No hold is a review control. Every control in (a) stops work from starting. None of them stops an unreviewed diff from being merged, and none of them recalls, reverts or blocks a merge that the Platform has already performed or that a person performs by hand on the source-code host. A hold set after a pull request is open bounds what happens next; it does not undo what happened (§6.7.2).
(c) Branch protection is the only review control Ticinuum cannot override. Branch protection, required reviewers, required status checks, CODEOWNERS and environment protection rules on the source-code host (§6.5.2) are the one layer Ticinuum neither operates nor can bypass, and are therefore the layer Customer should treat as authoritative for “nothing merges here without a human looking at it”. Customer configures them; Ticinuum cannot.
(d) Gates are the thing that is bounded. Neither a typed Approval Gate nor the conversational pause is in the list at (a): both end on the timers in the table above — a gate by closing the Ticket, an Ask by holding the Run.
6.6.4 Change. Ticinuum may change either timeout or either failure direction; any change will be reflected in the Documentation and, where it materially and adversely affects Customer, noticed under §19.2.
6.7 Stop controls — what exists
The following controls are built and are the contractual and operational basis for stopping autonomous work. Each is authorized server-side and recorded with an actor and reason.
| Control | Scope | Fence |
|---|---|---|
| Global kill switch | All Organizations; read fail-closed on every dispatch decision | (live) |
| Cross-Organization halt | A selected set of Organizations, by a system administrator | (live) |
| Organization halt | Customer’s own Organization, by an organization administrator | (live) |
| Per-Organization daily budget breaker | Fails closed and auto-pauses dispatch for the Organization when the daily spend ceiling is reached; default ceiling is USD 100 per Organization per day and is configurable | (live) |
| Multi-scope spend budgets | Organization / project / user / team, per day / week / month / total | (live) |
| Per-Run token cap | New input and output tokens, carried across an Ask resume; default 1,000,000 tokens; pauses the Work Item rather than continuing, and a pause not resumed within seven (7) days fails the Work Item | (live) |
| Per-Run spend ceiling | Default USD 25 per attempt, cache reads included; pauses the Work Item for a person | (live) |
| Spend-family ceilings | A daily ceiling on the Platform’s own curation and intake-triage model calls (default USD 1 per Organization per day) that stops those calls and nothing else | (live) |
| Bounded loops | The tool-calling loop and the review-and-revise loop are round-capped | (live) |
| Operator hard stop | Cancels any non-terminal Ticket and terminates its workflow | (live) |
| Prompt-injection quarantine | An always-on pattern layer plus a default-on semantic classifier hold a suspicious Ticket out of dispatch and grooming until a person approves it; unbounded — no timer | (live) |
| On-hold flag | Parks a Ticket so no autonomous action — dispatch or grooming — is taken on it; unbounded — no timer | (live) |
6.7.1 Ticinuum’s right to halt. Ticinuum may operate the global or cross-Organization halt, or halt Customer’s Organization, where §2.7 permits suspension or where Ticinuum reasonably believes continued execution risks material harm to Customer, to Ticinuum, or to a third party. Ticinuum will notify Customer promptly.
6.7.2 These controls are bounds, not guarantees. They limit dispatch and spend; they do not guarantee that an Agent will not produce harmful Output within the bounds Customer has set, and they do not undo actions already taken. A budget breaker stops future work; it does not revert a merged pull request.
6.7.3 Approval Gates are not in this table, and that is deliberate. The holds above are unbounded — the on-hold flag, the quarantine flag, the Organization halt, the cross-Organization halt and the global kill switch each block dispatch and grooming with no timer, until a person clears them (live). Approval Gates and the conversational pause are time-bounded (§6.6): the gate closes the Ticket after 7 days, and an Ask holds the Run when its window ends. Unbounded holds exist; unbounded approval gates do not.
6.7.4 A hold is not a review control. Nothing in the §6.7 table reviews a diff. These controls stop work from starting — they gate dispatch and grooming, and they gate spend. They do not prevent an unreviewed diff from being merged, they do not revert a merge, and they are not a substitute for Customer’s covenant at §6.4 or for branch protection at §6.5.2 (§6.6.3(b)–(c)).
6.8 Prompt injection and untrusted instruction channels
Text a model reads can be crafted to redirect the model’s behavior. In the Hosted Service, Ticket text, imported issues, inbound webhook payloads, pull-request and issue comments, attachments, and the contents of the repository itself are all channels through which such text can reach an Agent.
Ticinuum operates a two-layer safety gate over agent-visible fields — an always-on normalization and pattern layer, plus a semantic classifier — which quarantines a suspicious Ticket and blocks its dispatch pending human approval (live). Ticinuum will maintain safeguards of this kind that it considers commercially reasonable, but this is a description of current functionality and not a warranty or service level, and Ticinuum may change or discontinue any such safeguard. Ticinuum does not warrant that injection attempts will be detected or prevented — no known technique reliably separates instructions from data in a language model — and Customer must not rely on the safety gate as a control.
Customer is responsible for the content of the repositories and issue sources it points the Hosted Service at, and for the consequences of instruction-bearing content that Customer or Customer’s third-party contributors introduce into those channels. Claims arising from injected content are excluded from Ticinuum’s indemnity under §14.1(e) and are within Customer’s indemnity under §14.3.
6.9 An Agent has no authority
An Agent is a tool. It is not Customer’s agent in the legal sense, it is not Ticinuum’s representative, and it has no authority to enter into, accept, vary or waive any contract, to make any representation, or to create any obligation binding on either party or on any third party. Where an Agent posts text to a Third-Party Service — a pull-request body, a review, a comment, an issue-tracker update — that text is Output and is subject to §6.2 and §7.3, and neither party may rely on it as a statement of the other’s position.
6.10 Logging, attribution and evidence
The Hosted Service records: the Ticket and its mutation history; each Work Item and Run with token counts, dollar cost, duration and tool-call counts; the Run log including tool names, arguments and output; the rendered prompts (default on, configurable); Approval Gate and human-task decisions with actor attribution; and an append-only audit stream of sensitive non-Ticket mutations that is per-Organization hash-chained (sequence number, previous-row hash, row hash) at insert time and periodically re-verified (live).
Commits an Agent authors are attributed in git metadata to a Ticinuum agent identity and are pushed under the credential Customer authorized. Customer is responsible for its own internal attribution, sign-off and provenance requirements, including any developer-certificate-of-origin or signed-commit policy.
Customer may export a Ticket and its Runs, logs, artifacts and attachments as a self-contained archive (live), and may export a filtered slice of the audit stream where the audit export toggle is enabled (opt-in, off by default). Retention is governed by §10.6 and the Data Processing Addendum.
6.11 Multi-tenancy — an explicit disclosure
Isolation between Organizations in the Hosted Service is enforced in the application layer: authorization compares a resource’s Organization against the caller and returns “not found” on mismatch (live). There is no PostgreSQL row-level security, no per-tenant database, and no per-tenant object-storage credential.
The execution environment for Customer-supplied build, test and shell commands is not sandboxed (roadmap — not built). Those commands run as unconfined child processes of the agent loop, under the Executor’s own operating-system user, with no kernel boundary, no per-run container, no namespace, no seccomp profile and no resource quota. Nothing bounds what such a process may read on that host or which sockets it may open (§6.12).
Two things about this disclosure have changed, and neither closes the gap. First, the Executor process itself holds no platform database, object-store, cache, analytics, encryption or git-host application credential — it holds its own organisation-scoped registration credential, its own Model Provider credential, and an expiring git credential the platform brokers to it for the Run (live). The reach of that git credential differs by host and Customer should not assume the narrower case. On GitHub the platform mints an installation token scoped to the single repository in scope, so a token brokered for one repository is refused by GitHub against any other. On GitLab there is no equivalent: an OAuth grant’s reach is whatever the authorising account can reach and GitLab exposes no API to mint a narrower one, so the credential handed to the Executor is as broad as the connected GitLab account (§8.3). Second, a registration carries exactly one Organization and the work-claim query filters on it, so one Executor process is only ever handed one Organization’s work (live); Agent Runs for two Organizations are not concurrent activities in one process. What this changes is the blast radius of an escape, not the existence of a boundary. The residual exposure — and the reason this deployment model is deferred (§2.2(b)) — is many single-Organization Executor processes co-scheduled on one unsandboxed kernel, where an escape reaches whatever that host and that operating-system user can reach.
Ticinuum will not represent otherwise. The deployment model this disclosure concerns is deferred and is not offered, so Ticinuum provisions shared hosted access to no customer today (§2.2(b)); and if that model is ever offered, Ticinuum will not provision it to a customer whose stated requirements are inconsistent with this disclosure until agent sandboxing ships. §11.5 and §12.5 apply.
6.12 Agent-initiated outbound requests — the destination is chosen by the model
An Agent has a web-fetch tool, and the destination of any request it makes is selected by the model, from context, at run time — not by Customer and not by Ticinuum. Two limbs, and they are not the same:
(a) The web-fetch tool is guarded by default (live, default on). Requests are refused to loopback, RFC 1918 private, link-local (including the cloud instance-metadata addresses), carrier-grade NAT, IPv6 unique-local, multicast and broadcast ranges, and to their IPv4-mapped, NAT64 and 6to4 encodings. The check runs in the dialer immediately before connect, after name resolution, so a hostname that resolves to a public address when checked and an internal one when dialled does not get through. Redirects are capped at five hops and the response body is capped. A default-deny host allow-list posture is available (opt-in), and the denylist applies underneath it. The public internet remains reachable in the default posture: this control is about the pivot inward, not about restricting which third-party sites an Agent may read.
(b) That guard does not reach Customer-supplied shell, build or test commands, and nothing else does either. A command an Agent executes under §6.1 can open any socket the execution host and its operating-system user can open. Egress from those commands is unmitigated, and it is unmitigated for the same reason the execution environment is not sandboxed (§6.11).
Customer therefore acknowledges and agrees that:
6.12.1 enabling or leaving enabled the tools that permit outbound requests is Customer’s configuration decision under §6.5.4, and the risk of the requests those tools make is Customer’s;
6.12.2 an Agent may issue a request that scrapes a third party’s site in breach of that party’s terms, or performs a state-changing request against a system nobody authorised — the guard in (a) bounds where a web-fetch may connect, and bounds nothing about what the request does at a permitted destination — and a shell, build or test command an Agent runs may reach a cloud instance-metadata or other internal endpoint reachable from the execution environment, which (a) does not cover; and
6.12.3 claims arising from a request an Agent issued to a destination the model selected are within Customer’s indemnity at §14.3(i) and excluded from Ticinuum’s indemnity at §14.1(i), whether the request was made by the web-fetch tool or by a command an Agent executed.
Ticinuum may change or extend these controls under §19.1; the allow-list posture at (a) is available on request and is not enabled by default.
6.13 Workstation agents — the MCP server and workstation session metering (opt-in)
6.13.1 The surfaces. Where the operator of the Hosted Service enables them, the Platform
exposes two surfaces to software running on Users’ own machines. The MCP server lets an
MCP-speaking client — Claude Code first, any conforming client thereafter — and the tici
command-line tool read and act on Tickets, Requests, Initiatives, findings, Runs, Run logs,
Executors, landing and settings, through more than one hundred and fifty tools, as the User whose
Workstation Credential it presents and within the scopes granted to that connection. Workstation session metering lets a User’s
own Claude Code session report its model usage to the Platform so that it is attributed to the
Ticket the User has activated and recorded in the same usage ledger as Agent Runs. Both are off by
default; the operator turns each on deliberately, and either may be withdrawn under §19.1.
6.13.2 Workstation Credentials. A Workstation Credential is scoped to its holder’s own role in
one Organization and never carries system-administrator authority. Identity and Organization are
taken from the credential alone; no tool accepts an Organization identifier. Customer is
responsible for every Workstation Credential its Users hold and for the machines that hold them
(§3.6), may list and revoke them at any time, and must revoke a credential it believes to be
compromised. A credential is issued either as an OAuth grant approved in the browser — the tici login flow,
by loopback redirect or by device code — or as a static credential for CI and hooks, which expires
after ninety (90) days unless its holder sets a different period of up to one year. Requests over a
Workstation Credential are rate-limited per credential, and Ticket creation is capped per
credential. Tools that start paid work — dispatching, retrying or re-running a Ticket, sending it
to an agent, running a patrol, landing a change — require a separate dispatch scope that the User
grants to that connection deliberately; a start made through it is a person’s start under
§6.4.2(iv).
6.13.3 What a workstation agent cannot do. An MCP client without the dispatch scope cannot start an Agent Run; with it, it may take only the acts the User could take in the console. It cannot reach any Organization other than the credential’s, and cannot bypass any control in §6.5–§6.8: every write it makes passes through the same prompt-injection gate as the console and is audited with the credential’s identifier, and every read returns content the client is told to treat as untrusted data. Content a workstation agent writes is Customer Data, and Customer is responsible for it under §5.7 and §6.4 exactly as for content a User types.
6.13.4 Workstation session metering — what is collected. When enabled, the Platform accepts from a User’s Claude Code session only session lifecycle events and usage measures — the session’s start and end, token counts, cache counts, model, latency, request and prompt identifiers, and the client’s own cost figure — and attributes them to a Ticket, Initiative and Project control-plane side, from the User’s activation, never from a value the client asserts. Prompt content is never collected. Cost is recomputed from the reported tokens through the Platform’s pricing catalog with no markup of any kind; sessions funded by a subscription rather than an API key are priced at zero, and Ticinuum makes no representation about their value. Events with no open session are rejected. The resulting metadata is Customer Data (§1.11) about Customer’s own personnel: Customer is responsible for giving its Users any notice its law requires before enabling metering, and for deciding who within the Organization may see per-User figures.
6.13.5 Status. The MCP server and workstation session metering are (opt-in) under §12.1. A
combined autonomous-plus-workstation cost dashboard and any collection of prompt content are not
built and are not promised.
7. Intellectual property
7.1 Ticinuum ownership. Ticinuum and its licensors own all right, title and interest in and to the Platform, including the Hosted Service, the Self-Hosted Software, all software, prompts, agent definitions, orchestration models, schemas, interfaces, documentation, and all modifications, enhancements and derivative works of them, and all intellectual property rights in the foregoing. Except for the limited access right in §2.1, no licence or other right is granted to Customer, whether by implication, estoppel, exhaustion or otherwise, and all rights not expressly granted are reserved. Customer will not challenge, or assist any third party in challenging, Ticinuum’s ownership of, or the validity of Ticinuum’s rights in, the Platform.
7.2 Improvements informed by use. Ticinuum may develop and freely use improvements, enhancements, corrections and other modifications to the Platform based on its operation of the Hosted Service and on Feedback, and owns all right, title and interest in them and all related intellectual property rights. Nothing in this §7.2 permits Ticinuum to use Customer Data or Customer Code contrary to §5.2 or §5.4, or grants Ticinuum any right in Customer Code.
7.3 Output ownership. As between the parties, and subject to §7.1, §7.4 and Ticinuum’s rights in the Platform, Customer owns the Output generated for Customer’s Organization. To the extent Ticinuum holds or acquires any right, title or interest in that Output, Ticinuum hereby irrevocably assigns it to Customer, effective upon Customer’s payment in full of the fees applicable to the Agent Run that produced it, and until such payment Ticinuum retains all such right, title and interest. To the extent an assignment is not or cannot be made effective, Ticinuum grants Customer, subject to the same payment condition, a perpetual, irrevocable, worldwide, royalty-free, fully paid, sublicensable and transferable licence to use, reproduce, modify, distribute and create derivative works of that Output for any purpose. This §7.3 assigns and licenses no right in the Platform itself, including the prompts, agent definitions and orchestration logic used to produce Output (§7.4(d)). Ticinuum will, at Customer’s reasonable request and expense, execute documents needed to perfect this assignment.
7.4 Limits on the Output grant. §7.3 conveys only what Ticinuum has. It is not:
(a) a warranty that Output is original, non-infringing, or free of third-party rights;
(b) a warranty that Output is protectable by copyright or any other intellectual property right — material lacking sufficient human authorship may not be (§6.2(g));
(c) an exclusive grant — similar Output may be produced for others (§6.2(f)); or
(d) a grant of any right in the Platform itself, including the prompts, agent definitions and orchestration logic used to produce Output, which remain Ticinuum’s under §7.1.
7.5 Customer Code in Output. Where Output is a modification of Customer Code, Customer’s pre-existing rights in that code are unaffected and are not diminished by §7.3.
7.6 Open-source and third-party components. The Platform includes third-party and open-source components licensed under their own terms, identified in the notices Ticinuum makes available with the Platform. Those terms govern those components and, to the extent they conflict with these Terms as to those components, they control. Nothing in these Terms restricts Customer’s rights under an applicable open-source licence.
7.7 Feedback. “Feedback” means suggestions, ideas, enhancement requests, bug reports, usability observations and other input about the Platform that Customer or its Users provide. Customer grants Ticinuum a perpetual, irrevocable, worldwide, royalty-free, fully paid, sublicensable and transferable licence to use, disclose, reproduce, modify and exploit Feedback for any purpose without restriction, attribution or compensation. Feedback is provided voluntarily and is not Customer’s Confidential Information. Feedback does not include Customer Code, Customer Data or Output, and this licence grants no right in any of them. This §7.7 survives termination.
7.8 Trademarks. Neither party may use the other’s names, logos or trademarks except as §16 permits.
8. Third-party services, model providers and BYOK
8.1 General. The Hosted Service transmits data to, and receives data from, Third-Party Services. Those services are operated by third parties under their own terms and privacy policies, which govern Customer’s use of them. Customer is responsible for reviewing and complying with those terms and for any accounts and credentials it holds with a Third-Party Service. Ticinuum does not control and is not responsible for a Third-Party Service’s availability, performance, security, changes, deprecations, pricing, data-handling practices, or acts and omissions, makes no representation or warranty regarding any Third-Party Service, and its obligations under these Terms are suspended to the extent performance is prevented or impaired by a Third-Party Service failure. Customer’s use of a Third-Party Service is at Customer’s own risk.
8.2 Model Provider. Agent Runs require a Model Provider. As of the Effective Date the models are Anthropic’s, and Input is transmitted as described in §5.3. Customer authorizes that transmission. Anthropic’s server-side web-search tool is enabled for Agent Runs by default and can be disabled by configuration; when enabled, queries derived from Customer context reach Anthropic’s search infrastructure, and it is unavailable on the Bedrock transport. Ticinuum contracts with the Model Provider on terms consistent with §5.4 and lists it as a subprocessor.
8.2.1 Three transports, and they are not the same recipient. The Platform reaches those models over one of three transports, selected by the configuration of the Executor process that performs the Run — not per Organization, and not by Customer under the Hosted Service, where Ticinuum operates the Executor:
| Transport | Who receives the Input and serves the inference | Whose account is billed | Fence |
|---|---|---|---|
| Anthropic’s API (default) | Anthropic | The account holding the API credential in the Executor’s environment (§8.5.1) | (live), default |
Anthropic’s claude command-line tool against a consumer Max/Pro subscription | Anthropic | The subscription holder, typically the individual operating the host (§8.6) | (opt-in) |
| Amazon Web Services Bedrock | AWS, in the AWS region the transport resolves | The AWS account whose credentials resolve on the Executor host | (opt-in) |
The Bedrock transport changes the recipient, the contract and the region. Inference is served by AWS under Customer’s or Ticinuum’s agreement with AWS — not under any Anthropic agreement — and the same Ticket text, repository file contents and tool output that would have reached Anthropic reach AWS instead. The AWS credential is resolved on the Executor host by the standard AWS credential chain (environment, a shared profile or SSO session, a container or instance role, or the instance metadata service); Ticinuum stores no AWS credential for Customer. A region must resolve or the transport refuses to start, so unlike the Anthropic API path — where Ticinuum’s client pins no region — Bedrock traffic is region-pinned to a region the operator of that Executor chooses. Model identifiers, rate cards and available server-side tools all differ from the Anthropic API path; spend on this transport is priced from its own catalog block. Nothing in §5.4(b) is a representation about AWS, and where the Bedrock transport is selected AWS is a recipient that must appear in the subprocessor list before it processes anything (§8.7).
8.3 Source-code hosts — GitHub and GitLab. Two hosts are supported, and the host is selected from the repository’s own URL: a repository URL whose host matches a configured GitLab origin takes the GitLab path, everything else takes the GitHub path, and a URL that matches neither is refused rather than falling back. Both hosts use the same two distinct identities — a developer identity that writes code and opens and merges pull or merge requests, and a reviewer identity that submits reviews (live). Each host receives the same material: repository clones, branch pushes, pull- or merge-request titles and bodies, and review comments. Customer is responsible for the scope of the connection and for the branch protections applied to the repositories in scope, and may disconnect either host at any time; disconnecting revokes the Hosted Service’s write access and will cause Runs that need it to fail.
8.3.1 The credential posture differs materially between the two hosts, and Customer should price that difference. On GitHub (live), Customer installs a GitHub App; Ticinuum stores no GitHub token, minting a short-lived installation token per Run from the App’s private key and scoping it to the single repository in scope. On GitLab (opt-in — off unless Ticinuum has registered the two OAuth applications and configured their client secrets), gitlab.com and self-managed origins are both supported; Customer authorizes each of Ticinuum’s two applications from a GitLab account, and because a GitLab application’s access and refresh token pair is the credential, Ticinuum stores that grant encrypted, one record per Organization and role, and refreshes it on use. Two consequences follow and are stated rather than left to be inferred: (a) a compromise of Ticinuum’s encrypted credential store exposes live GitLab grants, where it would expose no GitHub token; and (b) a GitLab grant cannot be narrowed to one repository — its reach is whatever the authorizing account can reach (§6.11). The narrowing on that host is the membership of the account Customer authorizes, so Customer should authorize the developer application from a purpose-made account whose project membership is limited to the repositories in scope. The two applications must be authorized by different GitLab accounts, because GitLab does not permit a merge request’s author to approve it.
8.4 Optional integrations. Transactional email (opt-in), external issue trackers such as Jira and Linear (opt-in), and telemetry export (opt-in) are off unless configured. Enabling any optional integration is Customer’s configuration decision under §6.5.4, and Customer’s use of, and any data shared with, a Third-Party Service through that integration is at Customer’s risk. Where Customer enables them, Ticinuum transmits to them only what the integration requires — which, for email, can include Ticket keys and titles and an Agent’s question to a human, and for issue trackers, Ticinuum-authored status text carrying Ticket identifiers and links. The MCP server for workstation agents and workstation session metering (§6.13) are likewise (opt-in); they are inbound surfaces rather than integrations, and neither transmits anything to a third party. Where an Organization elects embeddings (opt-in), Ticket, comment, finding, Request and Initiative text is sent to the embedding provider named in the subprocessor list (Voyage AI). Where a User installs Ticinuum’s mobile application, push notifications reach that device through Apple’s push service (live); by default the payload carries only the Ticket key, the Organization identifier and decision identifiers, an Organization may add the Ticket title, and a Ticket’s body text is never sent. A Storage Profile (§5.9) is not an integration with a third party either: the bucket it names is Customer’s own, and its operator is not a Ticinuum subprocessor.
8.5 BYOK — bring your own key. Customer may supply its own Model Provider credential for its Organization. The credential is stored encrypted with AES-256-GCM under versioned encryption keys (live). What it covers is narrower than the name suggests, and Customer must read §8.5.1 before treating BYOK as an answer to a question about Agent Runs.
8.5.1 What a stored credential is, and is not, used for — read this before relying on BYOK. A stored BYOK credential is resolved and used only on the Platform’s own auxiliary model calls: Ticket drafting and grooming, the prompt-injection classifier, conversation summarisation, intake triage, curation where elected, the error explainer, the reranker, Initiative sparring and, where elected, embeddings. Whether the Platform’s own credential may serve those calls at all is an Organization setting (allow, deny, or unset). It is not used on Agent Runs. The Executor that performs a Run does not resolve a per-Organization credential and structurally cannot: the encryption keys that would decrypt one are refused in that process’s environment as a condition of start-up, and no endpoint hands it one. Every Agent Run therefore executes on the Model Provider credential present in the environment of the Executor process that runs it, and that fact — not Customer’s election — determines whose provider account receives the Input and pays for the tokens. Under the Hosted Service Ticinuum operates the Executor, so Agent Run spend lands on Ticinuum’s provider account and carries the markup at §9.3 whether or not Customer has stored a credential. Under the hybrid model, where the Customer operates the Executor, the reverse holds by construction (§9.3(b)). A statement anywhere that BYOK covers all Model Provider traffic for an Organization is wrong and must not be relied on.
8.5.2 No markup on tokens Ticinuum did not purchase. Where spend lands on a provider account Ticinuum does not hold — an auxiliary call that ran on Customer’s stored credential, or any segment reported by a Customer-operated Executor — Ticinuum’s charge for the period is a platform and governance fee and not a markup on those tokens (§9.3). The converse is equally operative and is stated here rather than left to be discovered: spend that lands on Ticinuum’s own credential carries the markup, including an auxiliary call served on the platform credential because Customer’s own was absent or unusable (§9.3(c)).
8.5.3 Where a call does run on Customer’s stored credential, Customer’s own agreement with the Model Provider governs that provider’s use, retention and training treatment of Input and Output; Ticinuum’s §5.4 commitment binds Ticinuum and its own subprocessors, not Customer’s provider relationship;
8.5.4 Customer is responsible for the credential’s scope, rotation and revocation, and for any spend incurred on it, including spend caused by a misconfiguration or by a Ticket Customer dispatched. A stored credential that is present but unusable — revoked, rotated out, or otherwise undecryptable — is not silently replaced with Ticinuum’s: the affected call is refused unless Customer’s Organization has expressly permitted Ticinuum’s credential to serve it, and where it is permitted the rescue is recorded against that Organization and the spend carries the markup (§9.3(c)); and
8.5.5 Customer may not configure a provider endpoint Ticinuum has not approved in writing (§2.5.8).
8.6 The claude-local subscription backend — it does not avoid the Model Provider. An
alternative backend named claude-local is available (opt-in) in deployments configured for it.
Its name is misleading and Ticinuum states the position plainly: it is not a local model and it
does not remove the Model Provider leg. It shells out to Anthropic’s own claude command-line
tool running against an Anthropic Max/Pro consumer subscription. The same Ticket text, the same
repository file contents and the same tool output reach the same provider, Anthropic. Only the
billing relationship changes — from an enterprise API agreement to a consumer subscription
agreement, typically held by the individual operating the host rather than by Customer.
Consequently:
8.6.1 every disclosure in §5.3, §5.4(b) and §6.11 applies unchanged when this backend is selected;
8.6.2 BYOK is inoperative on this backend. The subscription belongs to the host, not to the Organization, so a Customer-supplied credential is ignored; any statement elsewhere that BYOK covers all Model Provider traffic does not hold in this configuration; and
8.6.3 the consumer subscription’s terms — not an enterprise agreement, and not §5.4(b) — govern the processing. Whether a consumer subscription may lawfully be used to process a third party’s data at all is an open question Customer must resolve for itself. Ticinuum does not represent that it may.
No document, questionnaire answer or conversation may describe this backend as removing the Model Provider leg, as avoiding Anthropic, or as keeping content on-premises.
8.7 Substitution and subprocessor changes. Ticinuum may add, remove or substitute a Model Provider, model, transport, or other subprocessor. Ticinuum will update the subprocessor list and give notice as the Data Processing Addendum requires, and will not make a substitution that materially degrades the security commitments in the Data Processing Addendum. A change of model may change Output (§6.2(e)); that is not a defect. No such change is a breach of these Terms, and any change, deprecation, rate limit or discontinuation of a model, feature or service by a Model Provider or other Third-Party Service is outside Ticinuum’s control and is not a Ticinuum default (§8.1, §20.7).
9. Fees, metered usage, billing and taxes
9.1 Fees. Customer pays the fees stated on the Order Form. Fees are stated in United States dollars unless the Order Form says otherwise, and, except as §11.2 and §10.4 provide, are non-cancellable and non-refundable. Fees are based on the rights granted and the commitments made under the Order Form and are payable regardless of Customer’s actual usage of the Hosted Service.
9.2 Structure. The commercial model has three components: (a) a platform fee, charged per Organization per period, which carries the governance substrate — the audit trail, budget breakers and auto-pause, Approval Gates and durable human-in-the-loop, the Kill Switch and per-Run caps, and the cost ledger; (b) licensed throughput, being the number of Executors and Concurrent Agent Runs stated on the Order Form; and (c) metered usage, where the Order Form provides for it.
Pricing is not per-seat, and throughput is not a seat. The number of Users (§1.28), Organization memberships, repositories, projects, and configured agent definitions is unlimited and is never a basis for a fee. A Concurrent Agent Run is one Agent Run held in a claimed state at a single instant; an Executor is a registered runner process. Those two units, and those definitions, are the same ones the self-hosted licence agreement defines as its Governed Throughput licence metric (that agreement’s §2.5), so a Customer holding both instruments holds one metric and not two; seats are foreclosed in both. Customer therefore pays for how much work may run at once, not for how many people, agents, or projects it has.
Where Ticinuum operates the control plane, the Platform enforces both limits itself, and neither is billed as overage (live). A registration beyond the Organization’s Executor ceiling is refused inside the insert that would create it; a claim beyond its concurrent-run ceiling is not granted, so the work waits for a slot rather than running and being invoiced. Three honest qualifications, and the second and third are the ones a Customer relying on the ceiling must read:
(i) the concurrency ceiling is applied when work is claimed, so a Run already claimed continues to completion, and lowering a ceiling never revokes an existing registration;
(ii) the check fails OPEN. If the entitlement lookup itself fails, or an entitlement reader is not wired, the claim proceeds unthrottled rather than failing the Customer’s fleet — a deliberate inversion of the budget breaker’s fail-closed posture (§9.5), chosen because being briefly over throughput costs margin whereas refusing every claim on a control-plane fault stops a paying Customer’s entire fleet. Over-throughput is therefore possible during a control-plane incident; and
(iii) this enforcement is a property of a control plane Ticinuum operates, and does not travel with the metric. It holds for the Hosted Service, where Ticinuum operates everything, and for the hybrid model, where Ticinuum operates the control plane that answers the registration and the claim. It does not hold for a self-hosted deployment: there the ceiling is a database row the Customer’s own operator sets, is never derived from or compared against any licence file, and may be raised at any time to any number without contacting Ticinuum. Nothing in these Terms, and no representation about overuse in any instrument, may rest on the software refusing work — see the self-hosted licence agreement’s §2.5 and §3.4, which make staying within the licensed quantity a covenant for exactly this reason.
None of the three creates a charge Customer did not authorise. What (ii) and (iii) do create is the possibility of Customer running above its licensed quantity, which is a breach of §2.5.5 and is answered by the contract rather than by an invoice.
9.2.1 Promotional capacity — a gratuitous, term-limited grant. Ticinuum may make a promotional capacity grant available to an Organization that raises its Executor and Concurrent-Agent-Run ceilings for a fixed term without an Order Form and without a fee (live). Where such a grant is offered and redeemed: it may be redeemed once per Organization per promotion, ever; it is term-limited and expires without notice at the end of that term; it may only raise a ceiling and never lowers one, so on expiry the Organization’s ceilings revert to what it purchased and never below it; and it creates no entitlement to the grant, to its renewal, to its extension, or to any successor promotion. A promotional grant is not consideration for any fee, is not an Order Form term, and may be discontinued at any time as to future redemptions. Customer must not plan capacity on it, and Ticinuum gives no notice before it lapses.
9.2.2 Requesting more capacity. An organization administrator may request additional Executors or Concurrent Agent Runs in-product (live); the request notifies Ticinuum and is a request, not a purchase. Capacity changes by Order Form, by the self-serve path at §9.11 where that path is enabled, or not at all.
9.3 Metering. The billable unit, the rates, any included allotment, and the treatment of overage are stated on the Order Form. The Platform prices each metered segment from a version-controlled catalog keyed by provider and model, and records both the raw provider cost and the billed cost for every metered event as one append-only row in its usage stream (live). For platform-credential spend, the billed cost is the provider cost plus the markup stated on the Order Form.
The waiver is defined by where the spend landed, not by whether Customer stored a credential with Ticinuum. Ticinuum applies no token markup to spend that landed on a provider account Ticinuum does not hold, and that is decided per metered segment on the two grounds at (a) and (b), whose converse is stated at (c) (live):
(a) by plane — every metered segment reported by a Customer-operated Executor is treated as Customer-funded, whether or not Customer has stored a credential with Ticinuum, because the platform’s own credential cannot reach such a process at all: it is refused in that process’s environment and no endpoint brokers one, so the model call was necessarily paid on a credential Customer holds. This is a property of the metering code, not of the Order Form, and an Order Form cannot vary it; and
(b) by credential, on the Platform’s own auxiliary model calls — where such a call ran on the credential Customer supplied under §8.5, the billed cost equals the provider cost (§8.5.2).
(c) And the converse, which Customer must read as part of the same rule. Two consequences follow from defining the waiver by where the spend landed, and they run in opposite directions:
- An Organization that has stored no credential with Ticinuum still pays no markup on any segment its own Executor reported. Storing a credential is not a condition of the waiver.
- An Organization that has stored a credential still pays the markup on any spend that landed on Ticinuum’s account. That includes every Agent Run performed by an Executor Ticinuum operates — which, under the Hosted Service, is every Agent Run, because a stored credential is not used on that path at all (§8.5.1) — and it includes an auxiliary model call served on Ticinuum’s credential because Customer’s own was absent, or was present and unusable and Customer’s Organization had permitted the substitution (§8.5.4). Each such call is recorded against the Organization as platform-funded.
The usage stream records, for every metered event, which plane produced it and which funding source paid for it, alongside both cost figures (live). Where an Order Form defines “BYOK” as Customer having supplied a credential to Ticinuum, that definition does not match this clause and does not control it — the billing engine decides by account, and §9.3 controls.
None of the above applies to the platform fee or to licensed throughput under §9.2, which are payable regardless of whose credential funded a Run.
9.4 Metering accuracy and the dispute window. Ticinuum meters in good faith from the usage stream and makes the underlying per-Run and per-Ticket cost records available to Customer in the Hosted Service. Metering depends on token counts reported by the Model Provider and on the Platform’s own accounting, and may be imprecise in edge cases. Customer may dispute a metered charge by written notice within thirty (30) days of the invoice date, identifying the Runs or period disputed; the parties will work in good faith to reconcile against the usage stream, and Ticinuum will credit any amount shown to have been over-billed. Charges not disputed within that window are final. Metered amounts derive from token counts reported by the Model Provider, which Ticinuum does not independently verify.
9.5 The budget breaker is a control, not a spend guarantee. The per-Organization daily budget breaker fails closed and auto-pauses dispatch when the ceiling is reached, and multi-scope budgets apply at Organization, project, user and team level (live). These are ceilings on dispatch, enforced at the granularities the Documentation describes; they are not a contractual cap on Customer’s spend and not a guarantee that spend will not exceed a figure Customer has in mind. In particular, a Run already in flight continues until it completes or hits its own token cap, and spend that lands on a provider account Customer holds — every segment a Customer-operated Executor reports, and any auxiliary call that ran on a credential Customer supplied — is billed to Customer by that provider directly and sits outside Ticinuum’s billing entirely, so a Ticinuum-side ceiling does not bound it. Customer is responsible for setting its ceilings and for the spend incurred beneath them.
9.6 Invoicing and payment. Ticinuum invoices as the Order Form specifies. Undisputed invoices are payable within thirty (30) days of the invoice date, in full and, except for amounts Customer disputes in good faith under §9.4, without set-off, counterclaim, deduction or withholding. Payment is by the method stated on the Order Form.
9.7 Late payment. Undisputed amounts more than thirty (30) days overdue accrue interest at the lesser of 1.5% per month or the maximum permitted by law, and Ticinuum may suspend under §2.7(d) after giving at least ten days’ written notice and an opportunity to cure. Customer reimburses reasonable collection costs, including reasonable attorneys’ fees. These remedies are in addition to Ticinuum’s other rights and remedies under these Terms and at law.
9.8 Taxes. Fees exclude taxes. Customer pays all sales, use, value-added, goods-and-services, withholding and similar taxes and duties on the transaction, excluding taxes on Ticinuum’s net income. Where Customer must withhold, Customer grosses up so Ticinuum receives the invoiced amount. Customer provides any exemption certificate it relies on.
9.9 Price changes. Ticinuum may change fees effective at the start of a renewal term on at least sixty (60) days’ written notice before the renewal date. Fees for a committed term do not change during that term.
9.10 Third-party charges. Charges Customer incurs directly with a Third-Party Service — including Model Provider charges on a credential Customer holds (whether supplied to Ticinuum under §8.5 or resident in a Customer-operated Executor), AWS charges where the Bedrock transport is selected on Customer’s own AWS account (§8.2.1), and any source-code-host charges — are Customer’s responsibility and are not part of the fees.
9.11 Self-serve purchase of capacity — where enabled. Where the deployment is configured for it (opt-in — off unless Ticinuum has configured a payment processor), an organization administrator may purchase additional Executors and Concurrent Agent Runs from within the Hosted Service. That path works as follows, and the differences from §9.1–§9.9 are material:
9.11.1 The processor, and what Ticinuum does not receive. Payment is taken by Stripe, which hosts the checkout page. No card number, expiry, security code or other payment instrument detail is transmitted to, processed by, or stored on the Platform. The identifiers the Platform places on the transaction are the purchasing Organization’s and the purchasing User’s, both taken from the authenticated session; what comes back is the subscription’s identifier, its status and the quantities purchased. Stripe processes the payment under its own terms and is a Third-Party Service (§1.25); it must be listed as a subprocessor before it processes anything (§8.7), with its role for that traffic stated there.
9.11.2 A subscription, not an Order Form. A purchase made this way creates a recurring Stripe subscription and no Order Form. Quantities purchased are added to the baseline capacity included with the platform fee and take effect when Ticinuum receives and verifies the subscription event from Stripe — not at the moment of payment. Ticinuum treats a verified event as the sole authority for a capacity change; an unverified request changes nothing.
9.11.3 Authority, and Customer’s responsibility for it. The Platform restricts this path to a User holding the organization-administrator role and takes the purchasing Organization and the purchasing User from the authenticated session rather than from anything submitted. Customer is responsible for who holds that role (§2.4(b), §3.3): a purchase made by an administrator Customer authorized is Customer’s purchase, and Ticinuum does not verify that person’s internal authority to commit Customer’s funds. A single checkout is bounded to one hundred units of each kind, which is a typographical guard and not a commercial limit.
9.11.4 Cancellation, and what happens to capacity. Customer may cancel the subscription through the payment processor. On cancellation or lapse the Organization’s capacity reverts to the platform default rather than to zero, so an Organization that cancels retains the capacity included with the platform fee and loses only what it purchased. Purchased capacity is not withdrawn at a period boundary and continues until Ticinuum receives a cancellation event; a delayed event therefore favours Customer. No refund or proration is offered for a cancelled period, and §9.1’s non-cancellable and non-refundable rule applies to amounts already charged.
9.11.5 Price changes on this path. Because a self-serve subscription has no committed term, §9.9’s renewal-notice mechanic does not apply to it. Ticinuum may change the price of a self-serve subscription on notice, effective at the start of the next billing cycle, and Customer’s sole remedy for a price change it does not accept is to cancel the subscription before that cycle begins.
10. Term, suspension, termination, export and deletion
10.1 Term. These Terms begin on the Effective Date and continue until all Order Forms have expired or been terminated and no Customer access to the Hosted Service remains.
10.2 Termination for cause. Either party may terminate these Terms or an affected Order Form on written notice if the other party materially breaches and fails to cure within thirty (30) days of written notice describing the breach. Ticinuum may terminate immediately on notice for a breach of §2.5 (Restrictions), §2.6 (AUP), or §17 (Export control and sanctions) that in Ticinuum’s reasonable judgment cannot be cured or presents an immediate risk. Customer’s failure to pay undisputed fees when due is a material breach of these Terms.
10.3 Termination for insolvency. Either party may terminate immediately if the other becomes insolvent, makes a general assignment for the benefit of creditors, or becomes subject to a bankruptcy or similar proceeding not dismissed within sixty days.
10.4 Termination for convenience by Ticinuum. Ticinuum may terminate an Order Form for convenience on thirty (30) days’ written notice, in which case Ticinuum refunds prepaid, unused fees for the terminated period on a pro-rata basis. Ticinuum may also discontinue the Hosted Service, or a deployment model, under §19.1.
10.5 Effect of termination. On expiry or termination: (a) Customer’s right to access the Hosted Service ends; (b) Customer must stop using the Hosted Service and remove any credentials granting the Hosted Service access to Customer’s systems, including uninstalling the source-code-host App; (c) all fees accrued through the effective date become due, and where Ticinuum terminates for Customer’s uncured material breach all fees for the remainder of the then-current Subscription Term become immediately due and payable; and (d) each party returns or destroys the other’s Confidential Information in its possession, subject to §10.6, §15.5 and routine backup retention. Termination does not relieve Customer of obligations accrued before the effective date, and except as expressly provided in §10.4, §11.2 or §19.1, Customer is not entitled to any refund on termination.
10.6 Export and deletion
10.6.1 Export window. For thirty (30) days after the effective date of expiry or termination, on Customer’s written request Ticinuum will make Customer Data available for export in a machine-readable format. Ticinuum has no obligation to retain Customer Data after that window.
10.6.2 Export mechanisms available today. The Hosted Service provides a per-Ticket archive containing the Ticket manifest, a summary, every Run’s log, and artifact and attachment blobs (live), and a filtered audit export in CSV, JSONL or JSON where the export toggle is enabled (opt-in, off by default, subject to a row ceiling). A single-action, whole-Organization export does not exist as a product feature. Where Customer requires a full-tenant export, Ticinuum will produce it as an operational task within the window; the Order Form may specify the format.
10.6.3 Deletion — stated as what operations can actually perform. Read this clause together with §10.6.3(b). It deliberately does not promise more than the product can do.
(a) The obligation. After the export window, Ticinuum will, on Customer’s written request, delete Customer Data — all Customer Data as defined at §1.11, not only personal data — from its production systems, and will procure deletion by its subprocessors, on the single timeline stated in the Data Processing Addendum. There is one deletion timeline for the Hosted Service and it is the Data Processing Addendum’s; this §10.6.3 states no separate or shorter one, so that the two instruments cannot diverge. Where the Data Processing Addendum’s timeline is expressed for personal data, it applies equally to all other Customer Data under this clause.
(b) Disclosure — there is no automated tenant-deletion capability, and this is discharged by hand. Ticinuum states plainly, and Customer acknowledges, that as of the Effective Date:
- there is no organisation-delete function, route or service method anywhere in the Platform, and no user-deletion path with a caller; removing a member revokes access and erases nothing;
- the analytics streams expire unevenly, by decision. Findings analytics and the daily cost, velocity and efficiency rollups expire 400 days after their date, and slow-request records after 30 days; the Ticket timeline, time-in-state and prompt-lineage streams carry no expiry; and the audit stream and the usage (billing) stream never expire — the first because a gap in the hash chain is indistinguishable from tampering, the second because it is the billing record. Purging any of them is a manual statement executed by an operator;
- no object-storage lifecycle or expiry policy exists. Object storage holds, by default, a copy of Customer’s working tree (git history excluded) on every pause, together with full conversation transcripts, verbatim rendered prompts, diffs, repository surveys and Run-log archives. None of it expires on its own. A Data Residency Policy stops several of those families from ever being written, and a Storage Profile places everything written after it is verified in Customer’s own bucket under Customer’s own retention; neither moves or deletes what was written before (§5.9). The only blob-erasure paths are the deletion of an attachment and the deletion of a Ticket no work ran on;
- two housekeeping jobs run by default: delivered events older than thirty (30) days are purged from the Platform’s event outbox, and in-app notifications older than thirty (30) days are dropped. The purges of CI-run records and git-host call records ship off by default (opt-in);
- a Ticket can be deleted only while no work ever ran on it. An Organization administrator’s delete removes the Ticket’s PostgreSQL rows, withdraws any open question on it, writes a tombstone and an audit record, and removes its attachments’ files; it leaves the ClickHouse timeline, usage rows and prompt lineage in place. A Ticket that was dispatched, ran, or has a branch or pull request is cancelled, never deleted, and its Run artifacts stay; and
- no backup or restore procedure is documented for the hosted control plane, so a purge cannot be certified effective against backups, and Ticinuum makes no representation about backup rotation (§10.6.4(b)).
Deletion is therefore an operational task performed manually by an operator, not a product
feature, and Ticinuum does not warrant that it is complete, verifiable or repeatable. A
tenant-scoped purge routine with a verifiable completion record is (roadmap) — not built.
(c) Condition precedent. Ticinuum will not accept a signature against these Terms from a Customer whose own erasure obligations require more than §10.6.3(a) and (b) describe, until the purge routine in (b) ships.
10.6.4 Carve-outs from deletion. Ticinuum may retain: (a) data it must retain by law, and for as long as the law requires; (b) data in routine backups, which are not selectively editable and which remain subject to §15 while retained — Ticinuum states no backup rotation period, because no backup programme exists (§10.6.3(b)); this carve-out is therefore open-ended and Customer should price that in; (c) Usage Data under §5.6; and (d) records in the per-Organization hash-chained, append-only audit stream.
As to (d): the stream is append-only and hash-chained (sequence number, previous-row hash, row hash), so that alteration or deletion is detectable and breaks the tamper-evidence for every subsequent row for that Organization. It is tamper-evident, not immutable — rows are physically deletable by an operator, and the Data Processing Addendum expressly offers, at Customer’s direction, to delete a row and record the resulting chain break. Ticinuum will not describe the stream as immutable and will not refuse an erasure request on a ground of technical impossibility. The carve-out rests instead on the integrity of the record and Ticinuum’s need to establish, exercise or defend legal claims and to comply with a legal obligation — the basis the Data Processing Addendum uses. Where the audit stream contains personal data, the Data Processing Addendum governs how a deletion request against it is handled; Customer should raise any conflict between this carve-out and its own erasure obligations before signing.
10.6.5 Self-hosted and hybrid. Neither this §10.6 nor the Data Processing Addendum applies to data held in a Customer-operated deployment; Customer controls and deletes that data itself. That limit is about where data is held, not about which deployment model produced it. Under the hybrid model the Customer operates the Executors but artifacts — including the working-tree archive, diffs, rendered prompts, transcripts, summaries and Run logs — land in Ticinuum’s object storage by default (§2.2(c)), and everything this §10.6 says about deletion, including the absent capabilities disclosed at §10.6.3(b), applies to that data in full. Hybrid is not governed by these Terms (§0.5); this cross-reference exists so that no reader infers from “Customer-operated” that Ticinuum holds nothing.
10.7 Survival. Sections 1, 2.5.4 (no competing product; no extraction of prompts, agent definitions or orchestration logic), 5.1, 5.4 (as to data already received), 5.6, 6.2, 6.3, 6.9, 7, 9 (as to amounts accrued), 10.5, 10.6, 10.7, 11.3 (Customer warranties), 11.4, 11.5, 12, 13, 14, 15, 16, 17, 19.3 and 20 survive expiry or termination. §2.5.4 survives because it protects the asset §7.1 and §15.1(b) identify as Ticinuum’s core intellectual property, which must outlive the term; §11.3 survives because the §14.3 indemnity depends on it.
11. Warranties and disclaimers
11.1 Mutual. Each party represents that it is duly organized and validly existing, that it has authority to enter into these Terms, and that its performance will not violate any agreement binding on it.
11.2 Ticinuum service warranty and exclusive remedy. Ticinuum warrants that during the Subscription Term the Hosted Service will perform materially in accordance with the Documentation. This warranty does not apply to Output, which is provided as-is under §6.2 and for which Ticinuum gives no indemnity of any kind (§14.2); does not apply to Beta Features, evaluation access, free tiers, or any feature marked (opt-in) or (roadmap); and does not apply to any non-conformity caused by Customer Data or Customer Code, Customer’s configuration, acts or omissions, use of the Hosted Service other than in accordance with the Documentation, or a Third-Party Service. Customer must report a claimed non-conformity to Ticinuum in reasonable detail within thirty (30) days of discovery. Customer’s exclusive remedy, and Ticinuum’s entire liability, for breach of this warranty is for Ticinuum, at its option, to correct the non-conformity, re-perform the affected service, or — if Ticinuum cannot do either within a reasonable period after written notice — terminate the affected Order Form and refund prepaid, unused fees for the affected period.
11.3 Customer warranties. Customer represents and warrants that: (a) it owns or has all rights necessary in Customer Data and Customer Code for the processing these Terms contemplate, including the right to permit an Agent to read, modify and commit to the repositories in scope; (b) the person who installs the source-code-host App and grants repository access is authorized by Customer to do so; (c) its configuration of execution modes, Approval Gates, budgets, repository scopes and branch protections reflects Customer’s own risk decision (§6.5.4); (d) it will comply with the review covenant at §6.4 and with §5.7 (content responsibilities); (e) its use complies with the AUP and with applicable law, including export and sanctions law (§17); (f) it will not make available in the execution environment any credential, token, role or ambient-identity grant whose scope exceeds the repositories in scope for the Ticket (§5.7.5); (g) it is established in the United States and will not permit Users outside the United States to access the Hosted Service without Ticinuum’s prior written agreement (§0.6); and (h) it will not put the Hosted Service or Output to any High-Risk Use (§11.6).
11.4 Disclaimer. EXCEPT FOR THE EXPRESS WARRANTIES IN §11.1 AND §11.2, THE HOSTED SERVICE, THE PLATFORM, ALL OUTPUT, AND ALL SUPPORT AND OTHER SERVICES ARE PROVIDED “AS IS” AND “AS AVAILABLE”. TICINUUM DISCLAIMS ALL OTHER WARRANTIES, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, NON-INFRINGEMENT, ACCURACY, AND ANY WARRANTY ARISING FROM COURSE OF DEALING OR USAGE OF TRADE. TICINUUM DOES NOT WARRANT THAT THE HOSTED SERVICE WILL BE UNINTERRUPTED, TIMELY, SECURE OR ERROR-FREE, THAT DEFECTS WILL BE CORRECTED, THAT DATA WILL NOT BE LOST, OR THAT THE HOSTED SERVICE WILL MEET CUSTOMER’S REQUIREMENTS. Some jurisdictions do not allow the exclusion of certain warranties; to that extent this §11.4 applies to the maximum extent permitted.
11.5 No certifications; security posture disclosure. Ticinuum holds no SOC 2 report, no ISO/IEC 27001 certification, no FedRAMP authorization, no HIPAA business-associate qualification, and no PCI-DSS attestation, and has not undergone an independent penetration test. Ticinuum will not represent otherwise in any questionnaire, proposal or marketing material. Ticinuum’s contractually committed security measures are those in Annex II of the Data Processing Addendum (§2.3(b)); the security overview is informational only. As built and verified they include: encryption of stored credentials with AES-256-GCM under versioned keys; JWT and session-cookie authentication; a four-level role hierarchy enforced at the API and the interface; per-Organization OIDC single sign-on; passkeys that require user verification and a recent sign-in to enrol or remove; sessions that are revoked on every request by a per-User session epoch and a sign-out denylist; an OAuth 2.1 authorization server with PKCE and a device flow for command-line and MCP clients; application-layer tenant scoping returning “not found” on mismatch; a tamper-evident (append-only, per-Organization hash-chained) audit stream; an Executor process that holds no platform database, object-store, cache, analytics, encryption or git-host application credential and is handed exactly one Organization’s work (§6.11); a default-on guard on the Agent’s web-fetch tool that refuses connections to loopback, private, link-local and metadata address ranges and caps redirects at five hops, applied in the dialer after name resolution and re-applied on every redirect (§6.12(a)); and the stop controls in §6.7. Two of those measures are narrower than they read and are qualified where they are stated rather than here: the git credential brokered to an Executor is scoped to a single repository on GitHub and is not narrowable on GitLab (§6.11, §8.3.1), and a GitLab authorization is held by Ticinuum as a stored, encrypted, refreshable grant where a GitHub token is minted per Run and never stored (§8.3.1). They do not include a second authentication factor, database row-level security, per-tenant databases, sandboxing of the agent execution environment or any egress control over the shell, build and test commands an Agent runs (§6.11, §6.12(b)), a security information and event management system, intrusion detection, file-integrity monitoring, a 24×7 on-call rota, a documented incident-response plan, or any backup or disaster-recovery programme. Customer has read this §11.5, §6.11 and §10.6.3(b) and accepts them as a material basis of the bargain.
11.6 High-risk activities. The Hosted Service is not designed, intended or authorized for use in any environment requiring fail-safe performance or in which the failure, error, inaccuracy or unavailability of the Hosted Service or of Output could reasonably be expected to lead to death, personal injury, or severe physical, financial or environmental harm — including the operation of nuclear facilities, aircraft navigation or communication systems, air-traffic control, life-support or other medical devices, weapons systems, and industrial or critical-infrastructure control systems (each, a “High-Risk Use”). Customer will not put the Hosted Service or Output to any High-Risk Use, and Ticinuum disclaims all express and implied warranties of fitness for any High-Risk Use. Any High-Risk Use is at Customer’s sole risk and is within Customer’s indemnity under §14.3.
12. Beta, pre-GA, opt-in and roadmap features
12.1 Definitions. A “Beta Feature” is any feature, capability, integration or deployment model that Ticinuum designates as alpha, beta, preview, early access, experimental or pre-GA, or that the Documentation marks (opt-in) or (roadmap). A feature marked (roadmap) is not built and its description is not a commitment, a specification, or a statement of fact about the Hosted Service.
12.2 Terms applicable to Beta Features. Beta Features are provided as-is and as-available for evaluation only. They: (a) carry no warranty of any kind, and are excluded from §11.2; (b) are excluded from any service-level agreement and any service credit; (c) carry no support commitment; (d) may be changed, limited, suspended or discontinued at any time, with or without notice, and without liability; (e) may be less reliable, less secure and less performant than generally available features; and (f) are excluded from Ticinuum’s indemnity under §14.1. Customer uses Beta Features at its sole risk, and any third-party claim arising from Customer’s use of a Beta Feature is within Customer’s indemnity under §14.3.
12.3 No production or regulated use. Customer must not use a Beta Feature in a production-critical workflow, against a system whose failure would cause material harm, or with special categories of personal data, protected health information, payment card data, or data subject to export-controlled or classified handling requirements. Customer assumes all risk arising from any use of a Beta Feature in breach of this §12.3, and Ticinuum has no liability for it.
12.4 Confidentiality of pre-GA material. Unreleased features, pre-GA capabilities, roadmap material and their existence and performance are Ticinuum’s Confidential Information under §15.1(c), regardless of marking, and remain so until Ticinuum makes them generally available.
12.5 The whole product is pre-GA — nothing is purchasable, and nothing can be delivered. As of the Effective Date the Hosted Service as a whole is pre-general-availability and is subject to this §12, and no deployment model is generally available (§2.2 and the pre-launch notice at the head of this document). In particular, and without limiting §6.11 or §11.5:
-
Agent sandboxing is
(roadmap)— designed, not built. This is the gate that defers the deployment model these Terms govern (§2.2(b), §6.11). -
A tenant-scoped purge routine with a verifiable completion record is
(roadmap)— not built (§10.6.3(b)). -
Egress control over the shell, build and test commands an Agent runs is
(roadmap)— not built. The guard on the Agent’s web-fetch tool is(live), default on, and does not reach those commands (§6.12). -
The multi-tenant hosted deployment model — the model these Terms govern — is deferred and is not offered. It is not a capability awaiting a flag; it is a direction, on the roadmap statement at §2.2(b).
-
The hybrid deployment model is built and is not yet offered. It is not
(roadmap): the Executor holds no platform datastore or cross-tenant credential and authenticates over an organisation-scoped API today. What stands before it is commercial readiness and counsel review of its own instrument (§2.2(c)); artifact residency, which used to sit in this sentence, became a Customer election on 2026-09-04 (§5.9). Marking it(roadmap)would be a misstatement in Ticinuum’s favour and must not be restored. -
The Data Residency Policy is
(live)and its default preset changes nothing; a Storage Profile is(live)and is verified at the storage layer only — not end-to-end, and not against AWS or a third-party backend — and degrades planner decomposition while in use (§5.9). -
The MCP server for workstation agents and workstation session metering are
(opt-in)and off until the operator enables them (§6.13). Thetici logincredential flow is built (live); a combined autonomous-plus-workstation cost dashboard and any ingestion of prompt content are(roadmap)— not built. -
Licence verification for the Self-Hosted Software is built and is
(live)in the narrow sense that the software reads, verifies, records and displays a signed licence file — and it enforces nothing. It is warn-only by construction and by test and inert in a stock build (§2.2(a), §17.3). It is not a control, it must never be described as one, and no representation about overuse may rest on it. -
Six capabilities are built and marked
(opt-in), so §12.2 applies to them in full: the GitLab source-code host (§8.3.1), the AWS Bedrock model transport (§8.2.1), self-serve purchase of capacity through a payment processor (§9.11), agent merge (§6.4.2), the background dispatch loop and other machine-caused starts (§6.4.2(iv)) and embeddings (§8.4). Each is off unless Ticinuum or Customer configures or elects it, and Customer should not assume any of them is available or enabled in a given deployment. The(opt-in)marking is not cosmetic: it excludes each from the §11.2 warranty, from any SLA, and from Ticinuum’s indemnity at §14.1.
Re-marking a capability corrects a fact; it does not extend a warranty. Nothing in this §12.5
brings the Self-Hosted Software, a Customer-operated Executor, or the hybrid model within the §11.2
warranty or within any SLA: none of them is the Hosted Service, and both other models are governed
by other instruments — the licence agreement for self-hosted, and for hybrid a draft that does not
exist in final form (§0.5). Conversely, a capability
marked (live) here is warranted only to the extent §11.2 warrants the Hosted Service, and §11.2
does not apply to Output.
Any hosted access granted before general availability is granted on the basis of this section and of the Pre-GA Program Terms, with the liability treatment in §13.3.
13. Limitation of liability
13.0 The liability posture, stated once and applied throughout. These Terms allocate risk on a single, deliberate principle: Ticinuum bears bounded liability for the code Ticinuum wrote; Customer bears the liability for what Customer does with what an Agent generates. Concretely:
(a) Ticinuum does not indemnify Customer for Output at all (§14.2). No output indemnity, no “shield”, no defend-and-pay obligation for a claim that generated code infringes.
(b) Ticinuum’s indemnity for its own platform code is capped at the general cap in §13.2 (§13.5.1, §14.1), with procure / modify-or-replace / refund-and-terminate as its sole obligation.
(c) Customer’s indemnity is uncapped (§13.5(a), §14.3) and expressly reaches Customer’s use of Output, its repositories and data, its configuration of the guardrails, and its merge decisions.
(d) Four things are uncapped in both directions: breach of §15 (Confidentiality), gross negligence, wilful misconduct, and death or personal injury caused by a party’s negligence (§13.5(d)–(f)).
This is asymmetric by design, and it is priced into the fees. Customer’s exposure is for conduct, content and configuration inside Customer’s control; Ticinuum’s exposure is for its own software. An open-ended obligation to defend and pay a third-party claim over machine-generated code is not an exposure a pre-revenue company with no bound insurance policy can carry, and Ticinuum will not pretend otherwise in order to win a deal.
13.1 Exclusion of indirect damages. NEITHER PARTY IS LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY OR PUNITIVE DAMAGES, OR FOR ANY LOST PROFITS, LOST REVENUE, LOST SAVINGS, LOSS OF GOODWILL, LOSS OF BUSINESS OPPORTUNITY, BUSINESS INTERRUPTION, OR COST OF SUBSTITUTE SERVICES, HOWEVER CAUSED AND UNDER ANY THEORY OF LIABILITY, EVEN IF ADVISED OF THE POSSIBILITY. Loss of or corruption of data is an indirect damage for the purposes of this §13.1 except where it results from a party’s breach of §15 — which is excluded from the caps altogether at §13.5(d) — or from Ticinuum’s failure to maintain the security measures the Data Processing Addendum requires, to which the §13.4 supercap applies.
13.2 General cap. EACH PARTY’S TOTAL AGGREGATE LIABILITY ARISING OUT OF OR RELATING TO THESE TERMS, WHETHER IN CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY, BREACH OF STATUTORY DUTY, OR ANY OTHER THEORY OF LIABILITY, AND WHETHER OR NOT THE POSSIBILITY OF SUCH LIABILITY WAS FORESEEABLE OR A PARTY WAS ADVISED OF IT, IS LIMITED IN THE AGGREGATE TO THE TOTAL FEES PAID OR PAYABLE BY CUSTOMER UNDER THE APPLICABLE ORDER FORM IN THE TWELVE (12) MONTHS PRECEDING THE EVENT GIVING RISE TO THE CLAIM. THIS §13.2 IS SUBJECT TO THE PRE-GA AND NO-FEE FLOOR IN §13.3, THE SUPERCAP IN §13.4, AND THE EXCLUSIONS IN §13.5. WHERE MORE THAN ONE ORDER FORM IS IN EFFECT, THE CAP IS CALCULATED BY REFERENCE TO THE ORDER FORM UNDER WHICH THE CLAIM AROSE, AND CLAIMS RELATING TO MORE THAN ONE ORDER FORM DO NOT AGGREGATE THE CAPS OF EACH.
13.3 Pre-GA and no-fee access. Where access is provided at no charge or under an evaluation, free tier, or pre-general-availability arrangement, Ticinuum’s total aggregate liability is limited to the greater of fees actually paid for that access or US $5,000 (five thousand United States dollars).
13.4 Supercap for a security-measures failure. For claims arising from Ticinuum’s failure to maintain the security measures required by the Data Processing Addendum resulting in unauthorized access to or disclosure of Customer Data, the cap in §13.2 is replaced by two (2) times the amount in §13.2. Breach of §15 (Confidentiality) is not in this §13.4: it is excluded from the caps altogether at §13.5(d).
13.5 Exclusions from the caps. The caps in §13.2, §13.3 and §13.4 do not apply to:
(a) Customer’s indemnification obligations under §14.3, which are UNCAPPED (§14.3, §13.5.2);
(b) Customer’s payment obligations;
(c) Customer’s breach of §2.5 (Restrictions) or §2.6 (AUP), other than good-faith security research within §2.5.6;
(d) either party’s breach of §15 (Confidentiality) — uncapped in both directions;
(e) either party’s fraud, wilful misconduct or gross negligence — uncapped in both directions;
(f) death or personal injury caused by a party’s negligence — uncapped in both directions; or
(g) any liability that cannot be limited or excluded under applicable law.
Limbs (d), (e) and (f) are mutual. Ticinuum does not ask for a cap on its own confidentiality breach, gross negligence, wilful misconduct, or death or personal injury caused by its negligence, and does not grant Customer one.
13.5.1 Ticinuum’s software indemnity is capped — the carve-out is one-directional. For the avoidance of doubt, Ticinuum’s indemnification obligations under §14.1 are NOT excluded from the caps. Ticinuum’s aggregate liability under §14.1, including defence costs, damages finally awarded and approved settlement amounts, is limited to the general cap in §13.2 — the fees paid or payable under the applicable Order Form in the twelve (12) months preceding the claim. That indemnity reaches only Ticinuum’s own platform code — the Hosted Service as Ticinuum built and provides it — and does not reach Output in any amount, capped or otherwise (§14.1(b), §14.2). The procure / modify-or-replace / refund-and-terminate ladder at §14.1 is Ticinuum’s sole obligation for any infringement claim.
13.5.2 Customer’s indemnity is uncapped, and what it reaches is stated expressly. Customer’s obligations under §14.3 are not subject to §13.2, §13.3 or §13.4. That uncapped indemnity expressly covers, without limitation: (i) Customer’s use of Output, including its merge, deployment, distribution and licensing; (ii) Customer’s repositories, Customer Code and Customer Data; (iii) Customer’s configuration of the guardrails — execution modes, Approval Gates, budgets, repository scopes, credential grants and branch protections; and (iv) Customer’s merge decisions, including a merge made in breach of the review covenant at §6.4.
This asymmetry is deliberate and is priced into the fees. Customer’s indemnity covers conduct, content and configuration within Customer’s control. An uncapped defend-and-pay obligation for a patent or copyleft claim over machine-generated code — code neither party can inspect the provenance of, produced by a third party’s model, merged on Customer’s decision — is an open-ended exposure a pre-revenue company with no bound insurance policy cannot carry, and Ticinuum does not accept it at any tier (§14.2).
13.6 Output-related claims. The parties acknowledge that Output is machine-generated and that Ticinuum has no ability to foresee or control what an Agent produces within the bounds Customer configures. Output claims are not subject to any separate sub-cap and sit under the general cap in §13.2.
This §13.6 governs only a direct liability claim Customer brings against Ticinuum in respect of Output. It is not an indemnity and does not create one: Ticinuum indemnifies Customer for Output in no amount (§13.0(a), §14.2). Consistent with the §13.0 posture, Output claims sit under the §13.2 general cap, with no separate sub-cap.
13.7 Allocation of risk. The parties agree that the limitations in this §13 are an essential basis of the bargain, are reflected in the fees, and apply even if a limited remedy fails of its essential purpose.
13.8 Time bar. Except for claims for non-payment, neither party may bring a claim arising out of these Terms more than twelve (12) months after the claim accrued.
14. Indemnification
14.0 The allocation in one line. Ticinuum indemnifies Customer for Ticinuum’s own platform code, capped (§14.1). Ticinuum indemnifies Customer for Output in no amount and on no condition (§14.2). Customer’s indemnity is uncapped (§14.3). §13.0 states why.
14.1 Ticinuum software indemnity — Ticinuum’s own platform code only, and capped. Ticinuum will defend Customer against any third-party claim alleging that the Hosted Service, as provided by Ticinuum and used in accordance with these Terms and the Documentation, infringes that third party’s patent, copyright, trademark or trade secret rights enforceable in the United States or in a country party to the Berne Convention, and will pay damages and costs finally awarded, or amounts in a settlement Ticinuum approves.
Scope. This indemnity covers the Platform’s own software and materials as Ticinuum wrote and supplied them. It does not cover Output, and no reading of “the Hosted Service” extends it to Output: what an Agent generates is carved out at §14.1(b) and refused outright at §14.2. It is capped, and the cap is stated below.
Exclusions. Ticinuum has no obligation under §14.1 to the extent the claim arises from:
(a) Customer Data or Customer Code, including any third-party material Customer introduces;
(b) Output — Ticinuum provides no indemnity for claims that Output infringes or misappropriates a third party’s rights (§14.2);
(c) combination of the Hosted Service with anything not provided by Ticinuum, where the claim would not arise but for the combination;
(d) modification of the Hosted Service by anyone other than Ticinuum, or use of a version or configuration other than the current one after Ticinuum has made a non-infringing one available;
(e) content injected into an untrusted instruction channel (§6.8), or actions an Agent took in response to it;
(f) Customer’s configuration, including execution mode, Approval Gate, budget, repository-scope and branch-protection settings (§6.5.4);
(g) a Beta Feature (§12.2(f)), evaluation access, or a free tier; or
(h) Customer’s continued use after Ticinuum has notified Customer to stop for infringement reasons; or
(i) an outbound request an Agent issued to a destination the model selected (§6.12).
Remedy ladder — Ticinuum’s sole obligation. If the Hosted Service is, or in Ticinuum’s reasonable opinion may become, the subject of a claim under §14.1, Ticinuum may at its option and expense: (i) procure the right for Customer to continue using it; (ii) modify or replace it so it is non-infringing while materially equivalent; or (iii) if neither is commercially reasonable, terminate the affected Order Form on notice and refund prepaid, unused fees. §14.1 states Ticinuum’s entire liability and Customer’s exclusive remedy for any claim of intellectual property infringement.
Cap. Ticinuum’s aggregate liability under this §14.1 — defence costs, damages finally awarded and approved settlement amounts together — is subject to the cap at §13.5.1 (the §13.2 general cap). §13.5(a) excludes only Customer’s indemnification obligations from the caps; it does not exclude Ticinuum’s.
14.2 No Output indemnity — none, at any tier, on any condition. Ticinuum does not indemnify Customer, or anyone claiming through Customer, for anything an Agent generates. There is no output indemnity in these Terms, none is available on an Order Form, and none is implied by any other clause. Specifically, Ticinuum will not defend, and will not pay damages, costs or a settlement in respect of, a third-party claim that Output:
(a) infringes a patent, copyright, trademark, database right or other intellectual property right;
(b) misappropriates a trade secret;
(c) reproduces material under an open-source licence — including a copyleft or attribution-requiring licence — without the required notices, licence text or source-availability obligations, or contaminates Customer’s own code with such an obligation; or
(d) is defamatory, unlawful, or otherwise actionable as content.
Paired warranty disclaimer. This refusal is paired with an express disclaimer, and the two must be read together: Output is provided AS-IS. Generated code may be inaccurate, insecure, non-functional or infringing. Ticinuum warrants nothing about Output (§6.2, §11.2, §11.4). The Platform performs no licence scanning, no provenance detection and no duplication filtering, so neither party can tell from the Output itself whether it reproduces someone else’s code (§6.2(d)). Ticinuum will not defend a claim about material it cannot inspect the provenance of, produced by a third party’s model, on a merge Customer decided to make.
What Customer has instead. Customer’s affirmative review covenant at §6.4, its own licence and provenance controls, and the human-approval architecture described at §6.4.2 are the agreed mitigation. They are Customer’s controls, operated by Customer, and Ticinuum makes no representation that they are sufficient.
No back door. No Order Form, questionnaire response, security review, proposal, marketing statement, sales conversation or course of dealing creates an Output indemnity. If Ticinuum ever offers one it will be by a signed written addendum expressly headed as an Output indemnity, and it will be conditioned on Customer’s use of specified filters, review gates and evidence-retention practices, and on a bound insurance policy that does not exclude AI output.
14.3 Customer indemnity — UNCAPPED. Customer’s obligations under this §14.3 are not subject to the caps in §13.2, §13.3 or §13.4 (§13.5(a), §13.5.2). Customer will defend, indemnify and hold harmless Ticinuum, its Affiliates and their personnel against any third-party claim arising from:
(a) Customer Data or Customer Code, including Customer’s repositories and their contents, and including allegations that they infringe or misappropriate a third party’s rights or violate law;
(b) Customer’s use of Output — including its review or non-review, merge, deployment, execution, distribution, sublicensing or licensing by Customer, any claim that Output infringes, misappropriates or carries an unmet open-source obligation, and any consequence of Customer’s failure to comply with the review covenant at §6.4;
(c) Customer’s configuration of the guardrails — execution modes, Approval Gates, budgets, repository scopes, branch protections and halt controls — or its grant of credentials exceeding the scope of the engagement;
(d) Customer’s merge decisions, including a decision to merge or deploy Output that a person did not review, that no Approval Gate was configured to hold, or that branch protection did not require a reviewer for;
(e) Customer’s breach of §2.5, §2.6, §5.7, §6.4, §11.3 or §17, other than good-faith security research within §2.5.6;
(f) an Agent acting on instructions introduced into an untrusted instruction channel within Customer’s control (§6.8);
(g) Customer’s use of the Hosted Service against a system Customer was not authorized to modify;
(h) any credential, token, role or ambient-identity grant Customer made available in the execution environment whose scope exceeded the repositories in scope for the Ticket (§5.7.5), and anything an Agent did with it;
(i) an outbound request an Agent issued to a destination the model selected (§6.12), including a claim that the request breached a third party’s terms of use, reached an internal or metadata endpoint, or changed state on a system nobody authorised; or
(j) any other breach by Customer of these Terms, an Order Form or the AUP.
Customer will pay damages and costs finally awarded, or amounts in a settlement Customer approves.
14.4 Procedure. The indemnified party will: (a) promptly notify the indemnifying party in writing of the claim (delay excuses the indemnifying party only to the extent it is prejudiced); (b) give the indemnifying party sole control of the defense and settlement, provided that the indemnifying party (i) uses counsel of suitable seniority and experience, (ii) keeps the indemnified party reasonably informed of material developments, and (iii) may not, without the indemnified party’s prior written consent (not to be unreasonably withheld, conditioned or delayed), enter into any settlement that imposes a non-monetary obligation, an admission of fault or liability, or any unindemnified liability on the indemnified party, or that fails to include an unconditional release of the indemnified party from all liability on the claims resolved; and (c) provide reasonable cooperation at the indemnifying party’s expense. The indemnified party may participate in the defense with its own counsel at its own expense. If the indemnifying party fails to assume or diligently conduct the defense within a reasonable time after receiving notice, the indemnified party may assume the defense and settlement of the claim without prejudice to its indemnity rights, and the indemnifying party remains responsible for the reasonable costs of that defense, subject to the applicable limits in §13.
15. Confidentiality
15.1 Definition. “Confidential Information” means non-public information a party (“Discloser”) discloses to the other (“Recipient”) that is designated confidential or that a reasonable person would understand to be confidential from its nature or the circumstances. It includes, without any requirement of marking:
(a) Customer Data and, specifically, Customer Code — source code, repository contents, architecture, and the working copies, diffs, conversation transcripts and resume snapshots derived from them are Customer’s Confidential Information regardless of marking;
(b) Ticinuum’s non-public technology, prompts, agent definitions, orchestration design, security posture details, and pricing; and
(c) pre-GA material — unreleased features, roadmap, and their existence, behavior and performance — which is Ticinuum’s Confidential Information and is treated as a trade secret (§12.4).
15.2 Obligations. Recipient will: use Confidential Information only to perform or exercise rights under these Terms; protect it with at least reasonable care and no less care than it uses for its own confidential information of like kind; and disclose it only to its personnel, Affiliates, professional advisors, and actual or potential investors, lenders, acquirers or successors (and their advisors) who need it and are bound by confidentiality obligations at least as protective, for whose compliance Recipient remains responsible.
15.3 Exclusions. Confidential Information does not include information that: (a) is or becomes public without Recipient’s breach; (b) Recipient knew without restriction before disclosure; (c) Recipient rightfully receives from a third party without restriction; or (d) Recipient independently develops without use of or reference to the Confidential Information.
15.4 Compelled disclosure. Recipient may disclose Confidential Information to the extent legally compelled, provided it gives Discloser prompt notice where lawful and reasonable cooperation, at Discloser’s expense, in seeking protective treatment, and discloses only what is required.
15.5 Duration. Confidentiality obligations continue for three (3) years after disclosure, except that obligations as to Customer Code, Customer Data, Ticinuum’s source code, and any information constituting a trade secret continue in perpetuity, for as long as the information remains a trade secret or confidential. The same period applies in every other Ticinuum instrument, so a Customer holding more than one holds one clock.
15.6 Equitable relief. Money damages may be inadequate for a breach of this §15, and the non-breaching party may seek injunctive and other equitable relief without posting a bond and without the necessity of proving actual damages, in addition to any other remedies available at law or in equity.
15.7 Return or destruction. On Discloser’s written request or on termination, Recipient will return or destroy Confidential Information in its possession, subject to §10.6.4 (backups, legal retention, and the tamper-evident audit stream) and to Recipient’s own legal retention obligations. Retained copies remain subject to this §15.
16. Publicity and references
16.1 Consent required. Neither party may use the other’s name, logo or trademarks, issue a press release about the relationship, or publish a case study or quotation, without the other’s prior written consent. Consent is per use, not blanket, and may be withheld for any reason.
16.2 Revocation. Either party may revoke consent prospectively on written notice. Revocation does not require withdrawal of materials already published or distributed, but the other party will stop new distribution within a reasonable period and will remove the material from properties it controls on request.
16.3 Customer lists. Notwithstanding §16.1, Ticinuum may identify Customer as a customer of the Hosted Service and display Customer’s name and logo on Ticinuum’s website. Customer may revoke this limited right prospectively on written notice under §16.2, after which Ticinuum will cease new use within a reasonable period and, on request, remove the material from properties it controls. Press releases, case studies and quotations remain subject to per-use consent under §16.1.
16.4 Reference calls. Neither party is obliged to serve as a reference. Any reference arrangement is separate and voluntary.
17. Export control and sanctions
17.1 Compliance. Each party will comply with applicable export control, import and economic sanctions laws, including those administered by the U.S. Department of Commerce and the U.S. Department of the Treasury’s Office of Foreign Assets Control, and equivalent laws of other jurisdictions with authority over the parties.
17.2 Customer representations. Customer represents and warrants that: (a) it is not, and is not owned or controlled by, and is not acting on behalf of, a person or entity on a restricted-party or sanctions list; (b) it is not located in, organized under the laws of, or ordinarily resident in a comprehensively sanctioned country or region; (c) it will not permit any User in such a location to access the Hosted Service; (d) it will not use the Hosted Service, or permit Output to be used, in connection with nuclear, chemical or biological weapons, missile technology, or any other end-use prohibited by applicable export control law; and (e) it will not export, re-export, transfer or otherwise make the Hosted Service or Output available in violation of applicable export control or sanctions law, and is responsible for its Users’ compliance with this §17.
17.3 Self-hosted note. The Self-Hosted Software reads and verifies a signed, offline licence file and records and displays what it found, but that mechanism enforces nothing: it is warn-only by construction and by test, it is inert in a stock build because the set of compiled-in trusted signing keys is empty, and it carries no activation step, no seat count, no usage reporting channel and no call-home (§2.2(a), §12.5). The limb that matters for this §17 is unchanged and survives intact: the Self-Hosted Software makes no outbound request to Ticinuum of any kind, and the licence file was deliberately designed so that it never would. Consequently Ticinuum has no technical means of detecting or preventing non-compliant use, and no denied-party, destination or end-use screening is possible at a self-hosted deployment — the shipped licensing design does not create the data flow that would make one possible, and Ticinuum does not undertake to create one. A Customer that operates a self-hosted deployment is therefore solely responsible for export and sanctions compliance in respect of that deployment, including re-export. This §17 applies regardless of Customer’s location and is not narrowed by the US-only territorial scope at §0.6.
The same analysis applies to the hybrid model, where the Customer operates the Executors: the Executor authenticates to Ticinuum’s control plane, so Ticinuum can revoke a registration, but Ticinuum does not screen where an Executor process runs. Hybrid is not governed by these Terms (§0.5); this note is recorded here because the export analysis follows the binary, and both launch models put one in the Customer’s hands.
17.4 Suspension. Ticinuum may suspend or terminate immediately if it reasonably believes continued provision would violate this §17, and Ticinuum will have no liability to Customer for any such suspension or termination.
18. Government users
18.1 U.S. Government. The Platform is “commercial computer software” and its documentation is “commercial computer software documentation” as those terms are used in 48 C.F.R. §12.212 and 48 C.F.R. §227.7202. U.S. Government end users acquire only the rights in these Terms, consistent with 48 C.F.R. §12.212 and §227.7202-1 through §227.7202-4. Any use, duplication, reproduction, release, modification, disclosure or transfer by the U.S. Government beyond the rights granted in these Terms requires a separate written agreement signed by Ticinuum.
18.2 No implied acceptance of government terms. Ticinuum does not agree to any federal, state, local or foreign government contracting term, flow-down clause, certification or representation except where Ticinuum has expressly agreed in a signed writing. FAR and DFARS clauses are not incorporated by reference through a purchase order.
18.3 No authorization claims. Ticinuum holds no FedRAMP authorization, no StateRAMP authorization, and no equivalent government cloud authorization (§11.5), and the Hosted Service must not be used for federal information systems requiring one.
19. Changes to the Service and to these Terms
19.1 Changes to the Hosted Service. Ticinuum may modify, add to or remove features of the Hosted Service. Ticinuum will not, during a paid Subscription Term, make a change that materially degrades the core functionality Customer subscribed to, except where required for security, legal compliance, or by a change in a Third-Party Service. If Ticinuum makes such a degrading change and does not remedy it within thirty days of Customer’s written notice, Customer may terminate the affected Order Form and receive a pro-rata refund of prepaid, unused fees. Ticinuum may also discontinue the Hosted Service, or any deployment model, on reasonable prior written notice; where it does so during a paid Subscription Term other than for Customer’s breach, Ticinuum will refund prepaid, unused fees for the terminated period. Discontinuation of a Beta Feature is never a material degradation (§12.2(d)).
19.2 Changes to these Terms and to policies. Ticinuum may update these Terms, the AUP and the Data Processing Addendum. For a change that materially and adversely affects Customer, Ticinuum will give at least thirty (30) days’ notice before it takes effect, and the change takes effect for Customer at the start of the next renewal term. Customer may decline a materially adverse change by giving written notice before it takes effect, in which case the prior version continues for the remainder of the then-current term and the change applies on renewal. Changes required by law, or needed to address a security risk, may take effect immediately on notice. Other changes take effect when posted. Continued use after a change takes effect is acceptance of it.
19.3 Notice of changes. Notice under this §19 is given by email to Customer’s administrative contact, by in-product notice, or both.
20. General
20.1 Independent contractors. The parties are independent contractors. Nothing creates a partnership, joint venture, agency, franchise, employment or fiduciary relationship. Neither party may bind the other.
20.2 Assignment. Neither party may assign these Terms without the other’s prior written consent, except that, subject to the following sentence, either party may assign in whole, on notice, to a successor in connection with a merger, acquisition, reorganization, or sale of all or substantially all its assets or of the business to which these Terms relate. The permitted-assignment right in the preceding sentence does not extend to, and a party may withhold consent to, an assignment to a direct competitor of the non-assigning party. Ticinuum may assign to an Affiliate on notice. Any other attempted assignment is void. These Terms bind and benefit permitted successors and assigns.
20.3 Subcontracting. Ticinuum may use subcontractors and subprocessors to perform, and remains responsible for their performance and for their compliance with Ticinuum’s obligations. Subprocessor authorization and notice for personal data are governed by the Data Processing Addendum.
20.4 Notices. Legal notices must be in writing and are effective: on delivery when delivered by hand or by an internationally recognized overnight courier with tracking; or on confirmed transmission when sent by email to the addresses below with a copy sent by courier within three business days. Operational and billing notices may be given by email or in-product notice alone.
- To Ticinuum: legal@ticinuum.com, with the courier copy to Ticinuum Labs, LLC’s registered agent on file with the Colorado Secretary of State.
- To Customer: the administrative and billing contacts on the Order Form or in the account record. Customer must keep them current.
20.5 Governing law. These Terms and any dispute arising out of or relating to them, including non-contractual disputes, are governed by the laws of the State of Colorado, without regard to its conflict-of-laws rules. The United Nations Convention on Contracts for the International Sale of Goods and the Uniform Computer Information Transactions Act do not apply.
20.6 Dispute resolution and venue. Before filing suit, a party will give the other written notice of the dispute, and the parties’ senior representatives will confer in good faith for thirty (30) days; this conferral is a condition precedent to filing but does not toll or extend any applicable limitations period. Thereafter the parties submit to the exclusive jurisdiction and venue of the state and federal courts located in Denver, Colorado, and each irrevocably waives any objection to that venue, any defense of inconvenient forum, and any right to a jury trial in any such proceeding. Nothing in this §20.6 prevents a party from seeking injunctive or other equitable relief in any court of competent jurisdiction to protect its intellectual property or Confidential Information.
20.7 Force majeure. Neither party is liable for a delay or failure in performance (other than a payment obligation) caused by an event beyond its reasonable control, including natural disaster, epidemic, war, terrorism, civil unrest, labour dispute, governmental action, and failure of a utility, network, hosting provider or other third-party infrastructure — including an outage, deprecation, rate limit or policy change at a Model Provider or source-code host. The affected party will notify the other and use reasonable efforts to resume. If the event continues for more than thirty consecutive days, either party may terminate the affected Order Form on notice, and Ticinuum will refund prepaid, unused fees for the unperformed period.
20.8 Severability and waiver. If a provision is held unenforceable, it will be modified to the minimum extent necessary to make it enforceable, or if it cannot be, severed, and the remainder continues in force. A waiver must be in writing and signed by the waiving party, and applies only to the instance and purpose given. Failure to enforce is not a waiver.
20.9 Entire agreement. These Terms, together with the documents they incorporate and any executed Order Form, are the entire agreement between the parties on their subject matter and supersede all prior or contemporaneous proposals, negotiations, representations and agreements on that subject matter. Neither party relies on any statement not set out in these Terms. Any pre-printed or click-through terms on a Customer purchase order, vendor portal, or procurement platform are of no effect, even if Ticinuum accepts or acknowledges the document.
20.10 Order of precedence. In the event of conflict, the following order controls, from highest:
- a signed Design Partner Agreement or Founding Customer Agreement, together with the Pre-GA Program Terms as that agreement incorporates them, for the engagement it covers and for the duration of that engagement (§4.5);
- an executed Order Form, as to the commercial variables it expressly addresses;
- the Data Processing Addendum, as to the processing of personal data;
- these Terms;
- the Acceptable Use Policy and other policies incorporated by URL;
- the Documentation.
An Order Form varies these Terms only where it expressly identifies the section it varies. The Waitlist terms are not in this chain: they govern the Early Access waitlist only, grant no product access, and never apply to a Customer of the Hosted Service in that capacity (§4.5.1).
20.11 Third-party beneficiaries. There are no third-party beneficiaries, except: (a) Ticinuum’s Affiliates and personnel are beneficiaries of §14.3; (b) Customer’s Affiliates are beneficiaries of §14.1; (c) where the parties have agreed EU/UK scope under §0.6 and the Standard Contractual Clauses apply, data subjects hold the directly enforceable third-party beneficiary rights those Clauses confer, and nothing in this §20.11 limits them; and (d) the vulnerability disclosure policy published at ticinuum.com/security is expressly intended to be relied upon by security researchers who are not parties to these Terms, and this §20.11 does not displace it (see §2.5.6).
20.12 Interpretation. Headings are for convenience only. “Including” means “including without limitation”. References to a section are to a section of these Terms. The parties have had the opportunity to review these Terms with counsel, and no rule of construction against the drafter applies.
20.13 Counterparts and electronic signature. An Order Form may be executed in counterparts, including by electronic signature, each of which is an original and all of which together are one instrument.
20.14 Language. These Terms are in English. Any translation is for convenience; the English version controls.
20.15 Cumulative remedies. Except where these Terms expressly provide that a remedy is exclusive (including the exclusive remedies in §11.2 and §14.1), all rights and remedies under these Terms are cumulative and in addition to, and not in lieu of, any other rights or remedies available at law or in equity.