Sign in to this tenant
Pick a question, or ask one
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.
| proposal | flag | page |
|---|
Pages
| page | tag | entries | first entry |
|---|
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 channels listed. Anything else is absent, not warned about.
| source | where | offered | why | callers |
|---|
Register a source 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.
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.
Monitoring
By day
| day | runs | failures | p95 | tokens in / out | cost |
|---|
By model and by channel
| model | runs | failures | p95 | cost |
|---|
| channel | runs | failures | p95 |
|---|
Recent runs
| when | kind | caller | exit | took | model | question |
|---|
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 list web:<name> on the sources it may use.
| name | created | by | key |
|---|
Channels on this tenant
What runs here is set by the operator: the chat, the desk, the integrations above. Which of them may use a data source is yours, on Sources.
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/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), callers}
POST /api/v1/admin/sources/{name}/secret {password} PUT /api/v1/admin/sources/{name}/callers {callers}
POST /api/v1/admin/sources/{name}/verify
POST /api/v1/conversations/{uid}/messages {text, actor, client_msg_id}
GET /api/v1/conversations/{uid}/events?after=&epoch=&wait_s=