Install the tik skill into Claude Code and Claude gains working knowledge of tik: it recognises a store, records facts with tik set rather than inventing a status field, reads tik explain before asking a person anything, and authors process definitions whose stages derive from evidence instead of listing activities.

That last part is the reason the skill exists. The failure mode for any model writing a tik process is a task list wearing a process costume — stages named after activities, with nothing following from anything. The skill carries the design law that rules it out, along with the closed guard vocabulary and the authoring loop that checks the result.

The skill lives in this repository under skills/tik/, packaged as a Claude Code plugin by the manifests in .claude-plugin/.

Install

Add this repository as a plugin marketplace, then install the plugin:

/plugin marketplace add metio/tik
/plugin install tik@tik

Claude activates the skill whenever a repository holds a tickets/ or .tik/ directory, an actors registry, or processes/*.edn — or when you mention tik, tickets, processes, or stages.

What it grants Claude

The skill teaches the CLI surface and the model behind it:

• The daily loop — tik ls, tik next, tik new, tik set, tik explain, tik status, and the selector grammar for filtering a board.
• Corrections — retract, dispute, and the fact that a dispute is answered only by a different value, so Claude does not try to clear one by retyping the same fact.
• Authoring — tik author, the guard vocabulary, and the lint, simulate, and test loop that proves a definition before a real ticket depends on it.
• The one design law — a stage is defined by what must be TRUE to reach it, never by who moved what.

It also knows when not to act: an unreachable step in explain means waiting is pointless and the definition or the role register needs fixing, not patience.

For agents generally

The skill is one surface over a derivation every tool can read. The gated agent commands enforce the same boundary without any prompt-side cooperation:

tik agent actions 3184 --actor bot
tik agent set 3184 severity=:high --actor bot

An agent sees only what the frontier admits for its role, and anything else is refused with the derived reason. Because the boundary is the derivation rather than an instruction, it cannot be talked around.

This site also publishes /llms.txt and /llms-full.txt, so a model can read the documentation directly.

If something can be derived, storing it as authoritative state is a bug. That is the whole law, and every design question in tik resolves against it.

A ticket’s stage is the obvious case. It is never written down anywhere. It is f(events, now) — a pure function of the ticket’s own event log, the process definition that ticket pinned, and the instant you are asking about. Ask twice with the same inputs and you get the same answer, forever.

What the law buys

Correctness by construction. A stored status can disagree with the facts; a derived one cannot. When somebody retracts the approval that a ticket’s :approved stage depended on, the stage regresses on the next read, with no rollback step, no cleanup job, and no window during which the board is lying.

Every question about every moment. Because now is an argument rather than an ambient clock, “what was true on March 1” is answered by evaluating March 1:

tik status 3184 --at 2026-03-01T00:00:00Z

Replication without coordination. There is no authoritative mutable cell to serialize behind a lock, so replicas merge by unioning their event sets and each derives the same answer independently. See Replication .

Auditability that survives the tool. The conclusion is reproducible from the signed bytes by anyone, including someone who does not run tik. tik bundle packs one ticket into a tarball that verifies with coreutils and ssh-keygen alone.

What the law costs

Derivation is work done on every read, and the law forbids the obvious shortcut of remembering the answer. tik pays that cost deliberately and keeps it bounded: the fold is linear in events and polynomial in the size of the process definition, which is authored and small. Fact lookups are served from indexes the fold maintains, so history length does not turn into a quadratic.

Performance problems get indexes, caches, or a different storage backend. They never get new authoritative state. A cache that some lens keeps is fine as long as nothing treats it as the truth — the truth is recomputed from the events.

The companion law

Coordination-free by construction: no leader, no lock, no consensus. Every operation is correct on arbitrarily many replicas that share nothing and reconcile only by eventually unioning their grow-only, content-addressed event sets.

Reads consult one ticket’s own log, so they shard without limit. Writes are either content-addressed events that are a pure function of their intent — two replicas forming the same intent emit byte-identical events, and the union keeps one — or appends whose contention resolves by derivation: two competing claims about a fact reduce to :conflicted, a derived state, rather than a lock to be won.

A design that needs a replica to win an election, hold a lock, or agree with a quorum before it can act breaks this law as surely as caching a derived value breaks the first one.

What the kernel refuses to answer

The kernel answers “what follows from these signed facts?” It never answers “what should happen next?” There are no workflow transitions, no scheduler, no policy engine, and no external queries in the core. A guard consults one ticket’s log and nothing else — never a service, never another ticket, never a clock of its own.

Notifications, inboxes, webhooks, boards, and agent surfaces are all porcelain over derivations. That boundary is what keeps evaluation offline, reproducible, and true years from now.

A ticket is an append-only set of events. Everything else about it is computed.

Seven event types

The vocabulary is closed and versioned, because the semantics of a verifiable kernel have to be enumerable:

Things that look like they need their own type turn out not to. Comments are artifacts — text blobs attached by hash. Links are facts under a [:link …] path. Work records are :work attestation claims. Witness countersignatures are detached sidecars over a head rather than events, because an event would move the very head it witnesses.

Content addressing

An event’s id is the SHA-256 of its canonical bytes, and the stored file is named for that id. The bytes on disk are exactly the hashed region, so a store audits with nothing but coreutils:

sha256sum tickets/*/events/*.edn   # filename must equal the digest

Signatures never live inside the hashed region. They are detached sidecars alongside the event, which is what lets a second person add their signature to an event without changing its identity.

Every event names its parents, forming a Merkle DAG. Parents carry integrity and causality — they are how a replica knows whether two writes saw each other. They never carry ordering: the fold orders by (at, id) over the event set, which is what makes the reducer total, commutative, and idempotent.

Fact status

One function decides why a fact does or does not satisfy a guard, and guards consult nothing else:

What a dispute means

A dispute rejects the value that stood when it was raised, so the assertion that answers it has to claim something else. Re-asserting the rejected value verbatim leaves the path :disputed — otherwise the party a dispute holds accountable could clear it in one command by retyping the same fact.

A retraction clears disputes too, because the rejected claim is gone. A dispute raised on a path holding nothing rejects no particular value, so the first assertion answers it, which is what keeps a dispute from making a path permanently unusable.

Disputes accumulate: several people may reject the same claim, and each withdraws only their own.

tik dispute 3184 category --reason "this is billing, not technical"
tik dispute 3184 category --withdraw     # takes back your own objection

What a conflict means

When two replicas write the same path without having seen each other, and they disagree, the fact reads :conflicted and every guard that depends on it fails with a reason saying so. Nobody has to win. A later write that observed both supersedes them, and the conflict resolves by derivation.

Concurrent writes that happen to agree are not a conflict — there is no disagreement to surface.

A traditional tracker exposes state. tik exposes justification: what is true, why it is true, and what evidence is missing next. tik explain is where that surfaces, and every other view is a rendering of it.

$ tik explain 3184
To reach :resolved:
  ✓ [:fact [:resolution :ref]]
  ✗ attach an artifact whose path starts with "repro/"
  blocks: :closed
  (see: kb/runbooks/support-request-resolved.md)

Nothing in that block is speculation. The checkmarks are guards that already hold, the crosses are structured reasons produced by guard evaluation, blocks is the downstream closure, and the hint is the runbook the definition declares for that stage.

Reasons are data

The prose lives in this lens only. Underneath, each missing step is a structured reason carrying the path, the schema, the role, the actor whose signature already counted — whatever the guard knows:

tik explain 3184 --edn

That data contract is stable plumbing; the English is not. It renders as CLI text, as web forms built from the schemas in the reasons, and as agent task specifications whose acceptance criteria are the guards.

Reasons are sorted by who can act on them right now: values anyone can supply first, then corrections, artifacts, specific people, attestations, other stages, and finally time, which is nobody’s to act on.

Who can act

--actor filters a block to what one person can do, and counts the rest rather than hiding it:

$ tik explain 3184 --actor alice
To reach :resolved:
  ✗ attach an artifact whose path starts with "repro/"
  … 1 step(s) waiting on others or time

tik next rotates the same derivation into an inbox — for a person, or for a whole role:

tik next --actor alice
tik next --role :triager

The inbox ranks by unlock impact, so the step that frees the most downstream work comes first, and it holds back tickets whose dependency links point at unsettled upstream work.

Waiting versus impossible

Some blocked tickets are waiting for a colleague. Others can never move at all — a role with no members, a negation over a sticky stage already reached, a prerequisite that is itself dead. Those look identical until you say so, and telling somebody to wait for something that will never arrive is the failure that matters most for a tool whose whole claim is answering what is blocking.

$ tik explain 9c21
To reach :approved (unreachable):
  ⊘ fact [:sign-off] must be asserted by a member of role :auditor
      (currently by "seb") — nobody can ever do this

The derivation stays conservative: a step is only called impossible when it is provably undischargeable from the definition and the log. A choice dies only when every one of its branches does. Anything merely waiting keeps its ✗.

Proving it

tik causal answers the auditor’s question — which signed events made each reached stage true, with negations and time saying so honestly:

tik causal 3184

And tik whatif asks the counterfactual without writing anything:

tik whatif 3184 severity=:low +P2D retract:category

Each release publishes two downloads, a SHA256SUMS file covering both, and a cosign keyless signature over those checksums.

Download a release

From the releases page :

• tik-linux-amd64-glibc — the native binary, no runtime needed. It is labelled for exactly what it is: linux/amd64 against glibc.
• tik.jar — the uberjar, for macOS, Windows, and arm. Runs on any JDK 21: java -jar tik.jar --help. The container image is the universal deployment path.

chmod +x tik-linux-amd64-glibc
./tik-linux-amd64-glibc --help

Verify before trusting. The checksums cover the downloads, and the cosign bundle covers the checksums:

sha256sum --check SHA256SUMS
cosign verify-blob SHA256SUMS \
  --bundle SHA256SUMS.bundle \
  --certificate-identity-regexp '^https://github.com/metio/tik/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

From source with babashka

The CLI runs on babashka , so a checkout is enough:

git clone https://github.com/metio/tik.git
cd tik
bb tik --help

Every command in this documentation is written as tik; substitute bb tik when running this way.

The nix devshell

Contributors get the whole toolchain — JVM, Clojure, babashka, clj-kondo, TLC, GraalVM, ssh-keygen — from the flake:

nix develop --command bb test

Contributing describes the gate a change is expected to pass.

Signing your writes

A store works unsigned, and signing turns authorship into evidence anyone can check offline. Register yourself as an actor and point TIK_KEY at an ed25519 private key:

ssh-keygen -t ed25519 -f ~/.config/tik/id_ed25519
tik actor add alice ~/.config/tik/id_ed25519.pub
export TIK_KEY=~/.config/tik/id_ed25519
export TIK_ACTOR=alice

Signatures are detached sidecars produced by ssh-keygen -Y, so tik verify checks them with stock OpenSSH and nothing else. The public registry (actors) belongs in version control; the private key stays outside the store.

Where a store lives

Commands find a store the way git does: TIK_ROOT wins, otherwise the nearest ancestor directory holding tickets/, tik.db, or .tik/, otherwise the current directory. tik init marks one explicitly — --sqlite for the single-file backend, --hidden to keep everything inside .tik/ when the store sits above several repositories.

Three checks, in the order you reach for them.

Lint

tik lint processes/support-request.edn

The linter enforces what the kernel cannot:

• The closed guard basis — only operators the declared :process/guard-vocab admits.
• Graph sanity — every :after names a stage that exists, and no cycles.
• Stratified negation — [:not [:stage-reached …]] may only name a stage in a strictly earlier stratum, which is what makes the fixpoint provably deterministic.
• Facts over flags — a warning where a bare boolean stands in for information worth recording.
• Prefix boundaries — an :artifact prefix that does not end at a path boundary matches more than its author expects.

With no argument it lints the store instead: open tickets missing descriptions, titles, or signatures.

Simulate

tik sim processes/support-request.edn

A scratch ticket against a definition that reloads on every save. Assert facts, watch stages derive, and edit the definition in another window — the fastest loop for finding out that a guard means something other than what you read into it.

Test

tik test processes/support-request.tests.edn

Scripted cases: evidence in, expected stages out. Deterministic — a fixed epoch, pure derivation, no store — and a failing case prints explain, so the process itself says why a stage did not derive.

{:test/process "support-request.edn"
 :test/cases
 [{:case/name "facts alone do not triage — the triager role must sign"
   :case/steps [[:actor "rando"]
                [:set [:category] :technical]
                [:set [:severity] :high]]
   :case/expect {:excludes #{:triaged}}}

  {:case/name "uncategorized tickets escalate after 48h"
   :case/steps [[:now "+PT49H"]]
   :case/expect {:includes #{:escalated}}}]}

[:now "+PT49H"] moves the evaluation clock, so time-gated stages are testable without waiting and without a mock. [:actor "rando"] switches who is signing, which is how a :signed-by guard gets tested from both sides.

Write the negative cases. “A triager categorizing reaches :triaged” is the easy half; “facts alone do not triage” is the half that catches a :signed-by you dropped.

Publish

tik process sign support-request

Signing archives the definition by content hash and signs those canonical bytes. The hash stays the identity; the signature is the authority behind it.

TIK_ACTOR=bot TIK_KEY=~/.config/tik/bot_ed25519 tik mcp

tik mcp speaks the Model Context Protocol over stdio and exposes one store as a tool surface. The tools an agent is offered are exactly the steps the frontier admits for its role at that moment, so the tool list is the authorization boundary.

Why the boundary holds

An agent’s permission to act is derived from the same guards a person’s is. A step whose :signed-by names a role the agent is not in never appears as an available tool, and calling it anyway is refused with the derived reason rather than a generic denial.

That matters because the alternative — telling a model in its prompt what it may not do — is enforcement by cooperation. Here the check happens where the answer is computed, and it produces the same reason string a person would see.

Accountability

Every write the agent makes is an ordinary signed event with the agent’s own actor identity. The log therefore distinguishes what a person claimed from what an agent claimed, permanently and without a separate audit trail. tik causal names the events behind each reached stage, so a conclusion an agent contributed to can be traced to the evidence it supplied and the key that signed it.

Task specifications from guards

An agent asking “what should I do?” gets the same structured answer every other lens renders:

tik explain 3184 --actor bot --edn

Each missing step carries its path, its schema, and who may satisfy it — which makes an acceptance criterion out of a guard, rather than out of a sentence somebody wrote in a ticket description.

Every view here is computed when you ask, so none of them can be stale.

What should I do?

tik next --actor alice
tik next --role :triager
tik explain 3184 --actor alice

next ranks by how much downstream work each step unlocks, with quiet tickets rising. explain is the per-ticket answer: what is missing, whose signature it needs, and which stages it blocks. See Explain for the model behind them.

The board

tik ls
tik ls --all --long
tik ls --where 'stage=:blocked and fact:severity=:high and not disputed'
tik search firefox login

A selector is space-separated terms, all ANDed, each optionally negated: stage=:blocked, fact:severity, fact:severity=:high, actor=seb, disputed, conflicted, unsigned, derived-from=<hash>, ~text. The same grammar drives search, and tik dupes reports near-title lookalikes.

One ticket

tik status 3184
tik status 3184 --at 2026-03-01T00:00:00Z
tik log 3184
tik diff 3184 5

status reports the derived stage, the facts behind it, links, and what is next. --at answers the same question about any past moment by evaluating that moment. diff shows the evidence gained over the last few events.

Why, and what if

tik causal 3184
tik whatif 3184 severity=:low +P2D retract:category
tik debug 3184

causal names the signed events that made each reached stage true — including negations and time saying so honestly. whatif shows the stage diff a change would produce and writes nothing. debug shows the fixpoint with its working: every sweep, every guard verdict.

The roadmap and the wider picture

tik plan
tik plan roadmap.html
tik roles
tik work week --actor alice

plan derives the dependency-link roadmap — ready, blocked, done, cyclic, the critical path, and each item’s unlock impact. roles shows who gates what: every role on the open board, its effective members, and the stages waiting on its signature.

Sharing what you see

tik board board.html
tik serve --port 8080
tik bundle 3184 --out ticket-3184.tgz

board renders the whole store into one dependency-free HTML file you can mail or archive. serve publishes it live, read-only, with /tickets.edn and /explain/<id>.edn for tools. bundle packs one ticket — events, signatures, witness marks, the pinned ruleset, and a verify.sh — into a tarball a third party checks with coreutils and ssh-keygen, no tik required.

You record evidence. Stages follow.

Create a ticket

tik new support-request --title "login fails on Firefox"

The ticket pins the process definition’s content hash at creation, so it is judged by the rules it was minted under until somebody deliberately moves it with tik reprocess.

Created beneath a store, a ticket inherits its context as signed facts: repo=<name> from the enclosing git repository, plus any .tik-facts.edn maps on the way down, nearest winning, with anything explicit beating both.

Assert facts

tik set 3184 severity=:high resolution.ref=abc123def456

Dotted keys nest, so parked.reason="waiting on legal" writes the path [:parked :reason]. Values parse as EDN, and a bare word becomes a keyword — severity=high and severity=:high mean the same thing, which keeps facts out of the swamp of free-form strings.

Links are facts too:

tik set 3184 link.depends-on=9c21f0a4

tik next then holds 3184 back while 9c21 is unsettled, and tik status names the blocker.

Attach evidence

tik attach 3184 ./crash-repro.sh
tik comment 3184 reproduced on a clean profile, video attached

Artifacts are stored by hash. A comment is an artifact too — a text blob attached by its digest — which is why comments need no event type of their own.

Correct the record

Nothing is edited or deleted. Corrections are new events:

tik set 3184 severity=:critical              # supersedes; history retained
tik retract 3184 resolution.ref --reason "wrong commit"
tik dispute 3184 category --reason "this is billing"
tik dispute 3184 category --withdraw         # take back your own objection

A later assertion supersedes an earlier one. A retraction says the claim should not exist and offers no replacement. A dispute rejects the value that stood when it was raised, so only a different value answers it. In every case the stage regresses by derivation — there is no rollback step.

Signed claims and attestations

tik attest 3184 {:ci :green}

An attestation is a signed claim whose meaning the kernel does not interpret. Lenses read it, and the :attested-within guard checks that a fresh-enough one exists — a replayed “CI green” from last month is cryptographically valid and fails that guard honestly.

Derive facts from the world

tik probe 3184

A probe is any executable that prints key=value lines. It runs with its working directory in the ticket’s [:repo] repository, and changed values land as ordinary signed facts, so a ticket regresses on its own when reality does. The environment carries TIK_TICKET, TIK_REPO, and every present fact as TIK_FACT_<PATH>, which is what lets one repository hold many subjects — a package, tenant, or workload per ticket.

Recurring and bulk work

tik recur weekly-review --period 2026-W32
tik rollout dependency-audit --parent-title "Q3 audit"

recur mints this period’s ticket exactly once: it creates only when no ticket already carries that period label. The schedule lives outside the log — run it from cron or a timer — and tik derives whether the period exists yet. rollout creates one ticket per git repository under the store, wired to a parent by link facts, so the parent is a checklist whose checkmarks derive from each child’s evidence.

A tik store replicates by copying files. Two clones append independently, merge by set union, and derive the same answer — because derivation is a pure function of the event set and events are addressed by their content.

git pull && git push     # this is the replication protocol

Why the merge is trivial

Every event lives in its own file whose name is the SHA-256 of its bytes. Two people adding evidence to the same ticket create different files, so the merge is a union of directories and git never sees a conflicting hunk. Two people making the identical claim produce byte-identical files with the same name, and the union keeps one — deduplication for free.

That is why merging never requires a human to resolve a text conflict inside a ticket. What it can produce is a derived disagreement, and that is the point.

Disagreement resolves by derivation

When two replicas wrote the same fact path without having seen each other, and their claims differ, the fact reads :conflicted. Every guard reading it fails with a reason naming the competing claims, and tik explain asks for a value that supersedes them:

$ tik explain 3184
To reach :triaged:
  ✗ fact [:category] has conflicting concurrent assertions — one must
    supersede (ADR 0003)

Nobody wins an election. A later write that observed both competitors settles it, and the conflict disappears from the derivation. Parents are what make “observed” a checkable claim rather than a guess.

No leader, no lock, no consensus

No operation needs a leader, a distributed lock, or a quorum to be correct:

• Reads shard without limit. A derivation reads one ticket’s own log and nothing else. Guards never query across tickets, so N stateless replicas across M shards scale reads with zero coordination.
• Writes never resolve by lock. A write is either a content-addressed event that is a pure function of its intent, or an append whose contention resolves by derivation.
• Self-minted events are deterministic. Anything a replica mints on its own — a recurring ticket, a scheduled probe — derives its id and every byte, :at included, from its inputs. Two replicas firing the same schedule concurrently mint the same event, and the union keeps one.

A tik replica is stateless by construction, so horizontal scaling is the preferred deployment.

Partial logs say so

Between syncs, a replica’s copy of a ticket is incomplete by definition, and a derivation over a partial log is not merely incomplete — it is confidently wrong in a specific way. Ancestry the replica cannot see reads as concurrency, so writes that supersede each other in a linear history surface as :conflicted, and explain asks somebody to resolve a conflict that does not exist.

Every lens therefore checks whether referenced ancestors are missing and says so, rather than presenting a mid-sync view with the confidence of a complete one.

Backends

The file store is the signed interchange format: a tickets/ tree that sha256sum audits and git replicates. The SQLite backend keeps the same events in a single file when that suits operations better. Convert in place with tik store migrate --to sqlite|file — events and their detached signatures both travel.

A role is a name a definition uses in its guards. Membership is store state that decides who is in that role today.

Declaring a role

:process/roles
{:triager {:members ["seb"]}
 :approver {:members ["alice" "bob"]}}

Guards refer to the name:

:guards [[:signed-by :triager [:category]]]

That guard holds when the fact at [:category] was asserted by a member of :triager. It is a statement about evidence — who put this claim on the record — rather than a permission check performed somewhere else.

Membership lives in the register

A definition declares which roles exist and who starts in them. The store’s register decides who is in one now:

tik roles                          # who gates what, with effective members
tik roles add approver carol
tik roles remove approver bob

The register overrides a definition role by role, and takes effect on in-flight tickets immediately — no version bump, no reprocess. That is what makes a departure actually remove authority and a hire actually confer it, rather than leaving a departed member able to sign every ticket minted before they left.

Overriding is whole-role: the register’s entry replaces the definition’s members for that role rather than merging with them, because a departure has to be expressible. The first tik roles add on a role says so.

A store with no register derives exactly as before, so a definition’s declared members are a working default rather than something to restate.

Resolution takes no now. Time-aware validity — “was this actor a member last March” — is a separate concern that wants signed bindings rather than a mutable file, so a re-derivation at a past instant reads today’s membership.

Separation of duties

Two guards express the common controls without a policy engine.

Four eyes. :different-person holds when two facts are present and were asserted by distinct actors:

[:different-person [:proposal] [:approval]]

Nobody approves their own proposal, and explain says so by name when they try — the reason carries the actor whose signature already counted, so anyone else re-asserting one path breaks the tie.

Fresh evidence. :attested-within holds when an attestation of a claim exists and is recent enough:

[:attested-within {:claim :ci-green} "P7D"]

A replayed attestation from last month is cryptographically valid and fails this guard honestly, which is exactly the distinction a stale-evidence control needs.

An empty role is a dead end

A role with no members can never sign, so every stage behind it is unreachable. explain says that rather than leaving somebody waiting:

To reach :approved (unreachable):
  ⊘ fact [:sign-off] must be asserted by a member of role :auditor
      — nobody can ever do this

The fix is tik roles add, or a definition that does not demand a signature nobody can give.

Signing

Authority only means something once writes are signed. Register a signer once, then let every write carry authorship:

tik actor add alice ~/.config/tik/id_ed25519.pub
export TIK_KEY=~/.config/tik/id_ed25519

Signatures are detached sidecars from ssh-keygen -Y, checked by tik verify with stock OpenSSH. A signature is an authorship claim, which is why tik sign refuses to sign somebody else’s events.

A process defines stages. Each stage names its prerequisites (:after) and the conditions that must hold to reach it (:guards). Reaching a stage is never an action somebody takes; it is a conclusion.

{:stage/id :resolved
 :after [:triaged]
 :guards [[:fact [:resolution :ref]]
          [:or [:not [:fact= [:category] :technical]]
           [:stage-reached :reproducible]]]}

That second guard reads “technical implies reproduced” — material implication written out, because the vocabulary has :or and :not and needs no separate conditional.

The reached set is a fixpoint

Derivation computes the set of reached stages by iterating to closure: every stage whose prerequisites are reached and whose guards hold joins the set, which may in turn enable further stages, until nothing changes.

Each iteration is a synchronous sweep: every stage is evaluated against the snapshot taken at the start of the sweep, and all newly enabled stages are added at once. Firing one stage at a time gives order-dependent answers even on definitions the linter accepts, because a later stratum negating an earlier one can jump the queue. The synchronous sweep is normative — a TLA+ model exhibits the counterexample, and a conformance corpus case pins the correct answer.

Because [:not [:stage-reached …]] is negation inside a fixpoint, the linter enforces stratified negation: a definition may only negate stages in a strictly earlier stratum. That is what makes determinism provable rather than incidental.

Regression is by derivation

Nothing rolls a ticket back. Withdraw the evidence and the conclusion stops following:

$ tik retract 3184 resolution.ref --reason "wrong commit"
$ tik status 3184
stage:   triaged (reached: received, triaged)

The same holds for a dispute, and for a fact that a schema no longer accepts. The board cannot show a stage the evidence does not support, because there is no stored stage to go stale.

Sticky milestones

Some stages are milestones: reaching them once is a historical fact that later evidence does not undo. :stage/sticky? true says so, and the fold carries such a stage forward once any prefix of the log reached it.

{:stage/id :closed :after [:resolved] :stage/sticky? true
 :guards [[:fact [:customer :ack]]]}

A customer who withdraws their acknowledgement does not un-close the ticket. The log shows both truths — it was closed, and the ack was withdrawn — and the derived present misrepresents neither.

Sticky is monotone in fold position, not in the event set. The reached set is a function of the whole trajectory, so an event that arrives by merge carrying an earlier timestamp splices a new prefix into that trajectory and every later prefix is re-derived. A replica can therefore hold a sticky reach, sync, and no longer derive it. Convergence is unaffected — the same event set always derives the same answer — but a reach observed before a sync is not promised to survive it, which is why an effect pipeline records that it fired as its own fact.

Time

Time enters derivation as an explicit now argument. The kernel reads no clock of its own, which is what makes a re-derivation years from now reproducible.

Guards read the claimed clock — the :at an actor asserted — by default, and each fold step evaluates at its event’s :at clamped to the read’s now. No step acts as though more time has passed than actually has, so a postdated event cannot buy the 48 hours an :elapsed-since guard is waiting for. The clamp lifts by itself once that time really passes.

Several stages at once

A process is a graph, not a line, so a ticket can sit at several current stages at the same time — two branch tips, both maximal. tik status reports the reached set and the current tips; tik debug shows every sweep and every guard verdict that produced them.

Identity

tik actor add alice ~/.config/tik/id_ed25519.pub
tik sign 3184
tik witness 3184

actor add registers a signer in the store’s allowed-signers registry. Exporting TIK_KEY signs every write as it happens; sign catches up on your own earlier events, and only your own — signing somebody else’s would assert something false. witness countersigns a ticket’s head, and one signature timestamps the entire ancestry beneath it.

Roles

tik roles
tik roles add triager alice
tik roles remove triager bob

A process definition declares which roles exist and who starts in them; the store’s register decides who is in one today, for every ticket at once. Use it for a hire or a departure — it takes effect on in-flight tickets immediately, with no definition version bump and no per-ticket migration. See Roles and authority .

Verification

tik verify
tik verify --changed
tik root --witness

verify runs the ladder: content addressing, schema, signatures, and re-derivation. --changed skips unchanged heads for a fast drift check rather than the full audit. root prints one hash committing to the entire store, optionally countersigned, optionally anchored to a third-party timestamp.

Moving tickets to newer rules

tik reprocess 3184 processes/support-request.edn
tik reprocess 3184 processes/support-request.edn --apply

A ticket is judged by the rules it was minted under, so a definition that grows leaves existing tickets deriving under the old one until you move them — deliberately, because an implicit upgrade would re-judge a whole store on an edit. The dry run prints the pinned-versus-proposed hashes, which stages would be gained or would regress, and the new blockers. --apply records the re-pin as a signed event, so the log keeps which rules judged the ticket when.

Storage

tik init --sqlite
tik store migrate --to file
tik export ./audit-copy
tik pack
tik gc --apply

The file store is the signed interchange format; SQLite keeps the same events in one file. Migration is lossless in both directions — events and their detached signatures travel together. export materializes any store as the file format. pack consolidates settled tickets into one content-addressed pack each, and gc removes archived definitions no ticket pins any more.

Alerts out, mail in

tik effects run --config effects.edn --dry-run
tik bridge email < message.eml

effects run pushes derived stage transitions to Slack, Discord, Matrix, Teams, ntfy, PagerDuty, plain webhooks, email, or any program through the command sink. Any sink field may be a secret resolved at send time — from an environment variable, a file, a command, or a systemd credential — so no secret sits in the config file.

The email bridge turns messages into tickets and comments, and replies carrying tik> key=value lines become facts, which closes the loop for people who never leave their inbox.

The gated agent surface

tik agent actions 3184 --actor bot
tik agent set 3184 severity=:high --actor bot

An agent sees only what the frontier admits for its role, and anything else is refused with the derived reason. The boundary is the same derivation everyone else reads, so it cannot be talked around.

The design law

A stage is defined by what must be TRUE to reach it, never by who moved what. Ask of every stage: what evidence, on record, would convince a sceptical auditor a year from now? Write that as guards. If the honest answer is “somebody said so”, then make that the fact — a named person’s signature on a named claim — rather than a status somebody sets.

A definition whose stages are really a checklist of activities is a task list wearing a process costume. It derives nothing, because nothing about it follows from evidence.

The shape

{:process/id :support-request
 :process/version 1
 :process/guard-vocab 2

 :process/roles
 {:triager {:members ["seb"]}
  :billing {:members ["billing"]}}

 :process/facts
 {[:category]        [:enum :billing :technical :account :abuse]
  [:severity]        [:enum :low :normal :high :critical]
  [:resolution :ref] [:string {:min 8}]}

 :process/stages
 [{:stage/id :received
   :hint "kb/runbooks/support-request-received.md"
   :guards []}

  {:stage/id :triaged
   :after [:received]
   :hint "kb/runbooks/support-request-triaged.md"
   :guards [[:fact [:category]]
            [:fact [:severity]]
            [:signed-by :triager [:category]]]}

  {:stage/id :closed
   :after [:resolved]
   :stage/sticky? true
   :guards [[:fact [:customer :ack]]]}]}

:process/facts declares the schema for each path, which is what lets explain tell somebody not merely that a fact is missing but what shape it must take — and what lets a web form be generated from the reason.

:hint names a runbook for the stage. Those files are published here under Runbooks , so the hint a person sees in explain resolves to a page.

The guard vocabulary

Twelve operators, closed and versioned. New keywords need a version bump, because the semantics of a verifiable kernel have to be enumerable:

:different-person is the four-eyes principle as a derivable condition. :attested-within closes the stale-evidence gap: a replayed “CI green” from last month is cryptographically valid and fails the guard honestly.

There is no conditional operator, because material implication already spells one — “technical implies reproduced” is:

[:or [:not [:fact= [:category] :technical]]
 [:stage-reached :reproducible]]

Guards never query

A guard reads one ticket’s own log and nothing else. No service call, no database lookup, no other ticket, no clock of its own. Anything from the outside world enters as a signed attestation event first, which is what keeps evaluation offline, reproducible, and true years from now.

Facts over flags

Prefer a fact that carries information to a boolean that carries a decision. [:customer :ack] = true records that somebody clicked; a richer fact records what they actually agreed to. The linter warns about bare booleans for this reason, and the warning is opt-out per definition when a flag genuinely is the whole truth.

Versions and pinning

A ticket pins the definition’s content hash at creation. Editing a definition therefore changes its identity and leaves existing tickets deriving under the version that judged them, until somebody moves each one with tik reprocess. The version number is a human label; the hash is the identity.