Documentation

Documents

How Altimist works,
written down.

Concepts first, then the surfaces, then the API. If something here is wrong or missing, tell us — documentation defects are treated as product defects.

Nothing matches that. Try a concept — op-log, mandate, handle, passkey.

Start here

Three things to read first

In this order. The rest of the documentation assumes them.

  1. 01

    The object graph. Why nothing in Altimist is a file inside an application, and what that changes about the way you organise work.

  2. 02

    Grants and mandates. How authority is scoped to named objects, given an expiry, and revoked in one action.

  3. 03

    The op-log. What is recorded, what can be reverted, and how to read a signature back to the party that made it.

For developers

Drive it from your own systems

Everything the interface can do is an operation, and every operation is available over the API. Authenticate as yourself or as an agent — the op-log records which.

# Apply an operation as an agent, under its mandate curl -X POST https://api.altimist.com/v1/operations \ -H "Authorization: Bearer $ALTIMIST_AGENT_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "object": "obj_9f2c…/sheet/Q3", "action": "cell.set", "range": "B14", "value": 418200 }' # → 201 Created # op_7b31… signed · reversible · attributed to # research.arthur.altimist.com

REST API

Objects, operations, grants and the op-log. Idempotent writes, cursor pagination, and an OpenAPI description you can generate a client from.

Webhooks

Subscribe to operations rather than polling. Signed payloads, replay on demand, and a delivery log that lives in the same op-log as everything else.

MCP server

Point any Model Context Protocol client at your tenant and it inherits the same grants — an agent outside Altimist gets exactly as much as you gave it, and no more.

Something here wrong, or missing?

Documentation defects are logged like product defects and fixed in the same queue.