Onboarding

Your agents keep working. TIE keeps the record.

Fourteen steps. Nine of them once.

Your AI agents keep working exactly as they do today.

TIE sits beside them, never in front of them, and keeps the record: what each agent was given, what it did, and the proof of both.

You hold that record in your own account, under a key that only you hold.

Anyone you choose — a regulator, a court, an auditor, a counterparty — can verify it without trusting us, and without TIE being present.

01Once, at onboarding

Nine steps, done once. Every one of them is a declaration you make, not a change to how your agents act.

Choose your engines

You decide

Every deployment runs on TIE Fortress — the sealed record of what your agents did. Add TIE Attest when that record must be believed by someone outside your walls: a regulator, a court, a counterparty, a customer. Add TIE WELLSPRING when your agents work from rules you hold — your policies, protocols and standards, versioned and citable. One rule decides Attest: proof follows the audience. Sign for outsiders only where outsiders must verify.

Declare the vocabulary

You declare

The verbs your agents perform — represented, approved, denied, escalated, deferred — the objects those verbs take, their classes, and the outcome types. This becomes the pack. Adding a verb later is a dated, authored act, never drift.

Declare who may report

You declare

The agent itself, a supervising human, or both. A report from anyone else is queued and visible, never silently dropped. Where an agent and its supervisor disagree, both accounts stand in the record as a divergence.

Declare the ruler

You declare

The conditions your agents’ work is measured against — stable ids with versioned meaning — so that a condition declared on one date is comparable with one declared on another. The ruler is sealed; nothing re-means history.

Mount your rules, if you have them

You declare · optional

Policies, protocols, underwriting guidelines, clinical pathways: your own knowledge system. Ruler first; then the foundation — which laws and codes it rests on, or lawfully none; then any published authority adopted by reference, never retyped; then the boundary map, where the rules have never been exercised. A narrow first seal is enough. Or skip this step and begin with conduct alone — record first, declare second, serve third.

Generate the root key in your own account

Your KMS or HSM

The key is generated inside your own cloud key service or hardware security module — hardware that neither you, we, nor the cloud provider can extract it from. Every use is written to your own audit log. TIE never holds a signing key. The ceremony is a few permission steps and one tool run. The root signs once a week; a root that signs at any other time is an incident you can alarm.

Mint the two credentials

Your operator

The AI client’s bearer and the operator’s secret, minted from your own operator’s shell. The record never carries either. Rotation is yours, whenever you choose.

Issue the grant

You decide

Which tools which AI client may call, bound by hash to the session’s key and expiring with it. Tools not granted never appear to the client. Granting nothing is a fully supported way to use the system, and the absence of a grant is as provable as its presence.

Point your agents at TIE

Over MCP

Your agents connect over the protocol they already use, with the bearer, and no TIE software on their side. What they see is exactly what their grant allows. Nothing about how they act changes.

02Every day

Two steps. Neither one waits for TIE.

Ask before acting.
Report after acting.

Your agents

Before the act, the agent asks for the rules in scope — the Closed Manifest, every rule that applies to its declared conditions with the count that makes the set complete — and checks its basis: does the rule exist, is this version in force, do the conditions fall in its scope. After the act, it submits one declaration: who reported, who acted, what was done, when, under which conditions, citing which rules, with what outcome. It never waits for a reply. The acknowledgment is a receipt of the declaration, never an approval of the act.

Read the standing status

Your operator

A read, never a write: the deployment’s standing and the seal head of the latest cycle. Sealing, chaining, signing and receipting happen without you. Every day’s cycle closes at the day boundary or the entry ceiling, chained to the cycle before it and signed by the session key your root certified.

The door out — ask

Ten tools. Only the granted ones appear.

resolve_system · get_ruler · rules_in_scope · get_rule · boundary · system_diff · check_citation · verify · get_receipts · juxtapose_use

Every answer carries its standing in-band — version served, current version, seal date, review status — because models read content, not headers. Every answer is deterministic and receipted. A request for judgment returns a typed refusal that names what was refused, why, and the lawful path instead.

The door in — report

One declaration. Asynchronous by construction.

Reporter, actor, the attributed verb and its objects, the subject, when it happened and when it was observed, the conditions declared, the rules cited by pinned hash and version, the serve it drew on, the outcome, the tool it acted through — or, for an act not taken, the disposition: refused, aborted, escalated, deferred, with the reason.

An empty basis is lawful and says something: “no rules mounted” and “rules mounted, none cited” are two different facts, and the record keeps them apart.

03When it happens

Three steps for the days that matter.

When examined, answer from the record

Regulator · court · auditor

Every examination asks two questions in the same order: did they know, and did they comply. resolve_system(as_of) gives the rules in force on that date. get_receipts gives what the agent was served. juxtapose_use gives what it was served, what it cited, and what it left unapplied — an arithmetic remainder no human examination could ever produce. verify gives the seal, the chain, the signature. Then hand the examiner the export and the free verifier: two single files, one in Node and one in Python, importing nothing of ours, run from an empty directory, offline. No TIE engine is required.

Version your rules as they change

You declare

A rule changes as evolution — a new version of what was right for its time — never as correction. Yesterday’s rule still answers for yesterday. current_version travels in every subsequent answer, so an agent working from an old serve is told so in-band. Exceptions and out-of-scope applications arriving from the record land as evidence pressure in the next declaration cycle; nothing evaporates between sessions.

On departure, close the store and take the archive

Exit is an event, never a negotiation

The closure declaration, the handover of the archive with its owner-signed head, and the purge with its receipt are standard product behaviour. You leave with the sealed cycles, the chains and heads, the signatures with their key ids, every declaration, your own knowledge system, and the access chronicle — in open format, verifiable forever with free tools. Leaving TIE does not un-examine your history. The record outlives the engine.

04What you never have to do

TIE is a witness, never a gate.

Nothing in your systems waits for TIE. It never approves, blocks, scores, or ranks an act. A witness that cannot intervene has nothing to gain from what it writes — which is why the record is believable.

Never

Change how your agents act

An adapter at the serving door and one declaration at the reporting door. TIE is not in the execution path and adds no latency to it.

Never

Let TIE decide

No approving, blocking, ranking, recommending, scoring or grading. If you want a check before an act, you build it, outside TIE; nothing on our side may require one.

Never

Give TIE a key

No vendor-held signing key exists. The root is yours, in your own hardware, in your own audit log.

Never

Lose access to your own record

Open format, a free verifier, a free reader, and an exit that is a product behaviour rather than a negotiation.

Never

Share anything you do not choose to

Every grant is scoped, dated and recorded on your side. Sharing nothing is a fully supported way to use the system.