§06Using Archis

Privacy and licensing

Everything semantic happens on your machine. This page says exactly where the boundary is, what crosses it, and how to check.

§01

The boundary

Indexing, retrieval, compression and the dashboard are local. Only the commercial side talks to us. That split is not a preference — it is the product's central claim, and it holds because there is no endpoint that could receive source code.

One request goes somewhere else: on the Free plan, Archis asks your Git host whether a repository's owner is a person or an organization, and sends only the owner name. Every request the CLI makes, with what it sends and how to turn it off, is listed on Check it yourself.

Stays on your machineTalks to us
Reading your repository, and every parse of itSigning in, and authorising this device
The index, and every answer served from itBilling and subscription state
Sessions, and their accountingLicence issuance and periodic revalidation
Tool-output compression and the store of originalsUpdate checks and downloads
The dashboard, on loopbackSupport tickets you open, and telemetry if you switch it on

One path is neither: your coding agent sends your prompts, and the context Archis serves it, to its own model provider. That traffic is between you and the provider, under their terms, and Archis never receives it.

The interactive boundary trace shows the same thing as a diagram, and the privacy disclosure is the formal statement.

§02

What that costs

Local-first has consequences, and they are ours to state rather than yours to discover:

  • The first index runs on your hardware. We cannot pre-warm your repository on a fleet of servers, because we never have your repository.
  • An index is per machine. Two laptops build two indexes; there is no shared index for a team, because sharing one through us would mean us holding it.
  • We cannot debug your index for you. When something is wrong, support asks you to run chi doctor and paste the output, because that is the only way we can see anything at all.

That is the trade. We think it is the right one, and it is not reversible later.

§03

Index encryption

An index is a semantic map of your source, so it is treated as sensitive as the source. It is sealed with a key this machine generated and never sent anywhere, itself wrapped by an epoch key your licence delivers. The consequence: an index copied off this machine is unreadable.

This is the default. An index is sealed whenever the machine writing it has a key to seal it to — a licence, or a passphrase — and nothing needs to be turned on. A machine with neither indexes in the clear and says so on the first run, because believing an index is sealed when it is not is worse than knowing it is not.

Encryption is decided when an index is created, and a forgotten flag can never downgrade one: the key material beside the store decides, not the command line. An index written before you had a key is converted with chi index --encrypt, which rebuilds it and sets the old one aside rather than overwriting it.

$ chi keys status
this device's identity, and what can open this repository's index
$ chi doctor crypto
everything about index encryption, in one place
CommandWhat it does
chi keys enrollCreates this machine's encryption identity and registers it.
chi keys devicesEvery device on the account: whether it is activated, and whether it can open an encrypted index.
chi keys rotateRe-wraps this repository's key under the newest epoch your licence carries.
chi keys passphraseAdds or removes a passphrase that opens this repository's index without a licence — bring-your-own-key, for air-gapped and long-lived cases.
chi keys forgetDeletes this machine's encryption identity.

What sealing does not cover

Two things, stated plainly, because a security page that only lists what is protected is not one you can evaluate.

Not coveredWhat that means
Graph metadataThe chunks are sealed; the metadata beside them — object keys, manifests, branch names and commit messages — is not. Object keys are positional (<repo>/<kind>/<index>), so no symbol or file name is in them. What they do reveal is the shape of the graph and how large it is.
A machine you do not controlWhile a licence is valid, the data key is in the memory of the process that is decrypting — it has to be. Sealing protects a copy of the directory: a stolen laptop, a leaked backup, an index that ends up in a tarball. It is not a barrier against somebody who already administers the machine.

What your licence delivers

One part of Archis is not in the binary you download: the ranking model that decides what chi_context puts in front of an agent first. It is fitted over 1.5 million pairs mined from pull requests that closed issues, and it arrives sealed to this machine inside your signed licence.

Without it Archis falls back to a hand-tuned ordering. That is not a broken install and nothing refuses to run — it is measurably worse at the one thing the product is for. On 63 repositories the model was never fitted on:

OrderingRecall@10MRR
Hand-tuned0.3260.281
Learned0.3780.345

chi doctor says which one this machine is using, and why, so you are never guessing. An air-gapped installation gets the model the same way it gets everything else — inside its offline licence file.

§04

Licensing

Archis is licensed per machine, and the licence is a signed document the CLI verifies locally. That is why it works offline: no request has to succeed for you to keep working.

$ chi auth status
the current entitlement, its windows, and what it grants
$ chi auth refresh
forces an online validation now instead of waiting

Some commands require an active entitlement and say so when it lapses. They keep working for up to four days without a connection: a lease is valid for 24 hours, then has a 72-hour grace, so a flight or a train is not an outage. The grace can never outlive the subscription that granted it, and an organization's policy can shorten it.

chi auth status --json is the scriptable form, which is the one to use in a provisioning check. Your account portal shows the same state from our side, along with the devices currently activated.

§05

Telemetry

Off until you turn it on. Never collected in CI. And when it is on, the design goal is not "we promise not to look" — it is that the sensitive things cannot be attached to an event in the first place.

  • No source code, no file paths, no symbol names, no queries, no error text. Not redacted — unrepresentable.
  • Numbers travel as coarse buckets, not exact values.
  • The server validates every event against its own allowlist regardless of what a client sends.
$ chi telemetry status
$ chi telemetry preview
prints the exact payload that would be sent. Sends nothing
$ chi telemetry off
queued events are discarded

chi telemetry preview is the point of the whole design: you can read the payload before deciding, and chi telemetry purge deletes the local queue without sending it. The privacy disclosure lists the event fields in full.

§06

The dashboard

chi dashboard opens a local view of your repositories, activity, history and integrations. It binds to loopback only — 127.0.0.1 — is strictly read-only, and redacts history before displaying it. Nothing leaves the machine.

$ chi dashboard
$ chi dashboard --tui
stay in the terminal instead of opening a browser
$ chi dashboard --plain
print the numbers as text and exit

chi dashboard clean deletes local history — this repository's sessions, dead registry entries, or both. It is the one command in the group that changes anything, and it asks first.

§07

Sign-in and offboarding

An Enterprise workspace signs its members in through your identity provider, over SAML or OIDC, and can require it: a session signed in any other way is refused by our server, not just hidden in the portal. Proving your domain with a DNS record makes anyone who signs in under it join your workspace.

SCIM 2.0 provisioning is tested with Okta and Microsoft Entra ID. Deactivating a person there releases their seat and revokes their devices and sign-in tokens. Two things outlive that, and both are stated here so a reviewer does not have to find them:

  • A laptop that stays offline keeps its current lease until it runs out: at most four days, less if your workspace shortens the offline grace.
  • A sign-in to your own CAVS DB Server lasts seven days, and Archis cannot revoke it. A removed member can keep reading what the server holds for their role until it expires, unless you run cavsdb-server user block <email>, which refuses them at once. What a machine already fetched stays in its local cache, like a clone.
§08

The CAVS DB Server licence

The server checks its licence without a network connection. When that licence expires or is revoked the server becomes read-only: reads, compositions and locks keep working, publishing stops, and nothing is deleted.

An air-gapped machine runs on an offline licence file the portal issues: signed for that machine and valid for a set period. It cannot be revoked, so it runs until it expires.

When a subscription ends, local indexes stay on every machine and the account drops to Free. The commands that clean up federation — chi repo remove, chi workspace gc, evict and lift, chi registry tenant --clear — still run without a licence.