aida desk

Research

A deeper run: the engine explores the question in several passes, each building on the last, and synthesises at the end. It opens a thread like any question; the findings arrive as it works. Costs more, takes longer.

Send a message

What an integration sends: who it is from, a subject, text, files. Attributed to web:desk; it lands under inbox/ in your workspace and in its ledger. A file put in inbox/drop/ on the tenant arrives the same way without the API.

pick a record

Proposals awaiting review

What the engine learned about the shape of your data — never a value. A content? flag is a hint from a reader; read the line and decide. Apply files it on a page as unverified; drop discards it.

Pages

Tools

Data sources

A source is offered to the engine only when its verification passes here, for the policy file as it is, and only to the principals granted it in Settings › Access. Anything else is absent, not warned about.

Register a database from an aida-scope hand-over

The zip your IT downloaded from aida-scope after signing and verifying. The password of the engine's user is entered separately, below, and never travels with the bundle. A mailbox is registered on the tenant itself with aida-mailbox register; it then appears above like any source.

The engine user's password

Stored in your workspace's environment file on the tenant, never in git, never shown again. The engine reads it on every run; then verify.

By day

By model and by channel

Recent runs

Incidents and in flight

Memory, sources, workspace, and who looked

"who looked" is the operator's trail on your tenant: every time simtree read your rows, with the reason given.

Your integrations

A system of yours that asks this tenant: it sends its key as Authorization: Bearer and names the person behind each request. The key is shown once, when created; revoke and create again to rotate. It works on the next request, no restart. Then give a principal below the identity web:<name> and grant it the sources it may use.

Access

Who may reach which data source: one table, access.yaml in your workspace, ratified by each change's commit under your name. A principal is a person, a workflow or a system; its identities are how a run announces itself — telegram:<id>, web:<integration> (every actor of it) or web:<integration>:<actor> (one), task:<name>, env:<token>, cli, test, <channel>:*. The most specific identity wins; * under sources is every source.

Channels on this tenant

What runs here is set by the operator: the chat, the desk, the integrations above. An identity in the table above names one of these, or one sender or actor on it.

Admin access

One admin key per tenant, issued by the operator; rotating it is theirs. Your name on sign-in is recorded on every action and is the attesting identity when you ratify.

Status

…

The API this page uses

Everything here is a call to /api/v1/… on this origin with two headers, Authorization: Bearer <admin key> and X-Actor: <name>. The spec is at /api/v1/openapi.json, the interactive docs at /api/v1/docs. Integrating into your own admin means making the same calls this page makes.

GET  /api/v1/admin/memory                      proposals with flag and page, and the pages
POST /api/v1/admin/memory/apply  {ids, page?}    POST /api/v1/admin/memory/drop {ids}
POST /api/v1/admin/memory/add    {text, page?}
GET  /api/v1/admin/memory/pages/{page}/review    POST /api/v1/admin/memory/pages/{page}/ratify
GET  /api/v1/admin/memory/audit                  POST /api/v1/admin/memory/contradictions
GET  /api/v1/admin/memory/history                GET  /api/v1/admin/status
GET  /api/v1/admin/tasks   POST /api/v1/admin/tasks {id, goal}   GET /api/v1/admin/tasks/{id} | /outcomes | /file | /actions
PUT  /api/v1/admin/tasks/{id}/file {human, message}   PUT /api/v1/admin/tasks/{id}/enabled {enabled}   POST /api/v1/admin/tasks/{id}/run | /record
GET  /api/v1/admin/digests   GET /api/v1/admin/digests/{stamp}
GET  /api/v1/admin/monitor?days=                 GET  /api/v1/admin/monitor/rows?days=&limit=&what=
GET  /api/v1/admin/integrations   POST /api/v1/admin/integrations {name} → the key, once   DELETE /api/v1/admin/integrations/{name}
GET  /api/v1/admin/channels                      GET  /api/v1/admin/sources
POST /api/v1/admin/sources {name, host, port, zip (base64)}
POST /api/v1/admin/sources/{name}/secret {password}    POST /api/v1/admin/sources/{name}/verify
GET  /api/v1/admin/access                        the table: principals, identities, sources
POST /api/v1/admin/access/principals {name, kind, identities, sources}   DELETE /api/v1/admin/access/principals/{name}
POST | DELETE /api/v1/admin/access/principals/{name}/identities {identity}
POST | DELETE /api/v1/admin/access/grants {principal, source}   every write is a commit under your name
POST /api/v1/conversations/{uid}/messages {text, actor, client_msg_id, thread_ref?, mode? (ask|dig), loop?}
GET  /api/v1/conversations/{uid}/inflight        what is running, and the limits (one per thread, a cap per conversation)
GET  /api/v1/admin/captures/{path}               one of your captures, for history
GET  /api/v1/conversations/{uid}/events?after=&epoch=&wait_s=
GET  /api/v1/search?q=&limit=&since=&source=   the text sources you may read, by their index, before any model: per-source counts, hits with snippets; mode "or" when no message had every word
GET  /api/v1/search?related=&source=&limit=   instead of q: the thread and the messages sharing a reference with that message, each hit with why
POST /api/v1/inbox  multipart/form-data: sender, subject, text, files (any number)   → the item, duplicate:true when stored already
GET  /api/v1/inbox?limit=&before=   GET /api/v1/inbox/{id}   GET /api/v1/inbox/{id}/files/{name}   the bytes, as stored
GET  /api/v1/queue?status=&kind=&assigned=&limit=&before=   the decision queue, newest first, every record whole; GET /api/v1/queue/{id} adds its ledger; GET /api/v1/queue/counts
POST /api/v1/queue/{id}/decide {outcome, note?}   take an outcome as the person behind X-Actor; 409 already decided, 403 when it requires a kind your principal is not