On this page
Architecture, storage and the conversation path
Question: where does a message go, where does state live, and which evidence establishes an effect?
Text equivalent: the browser sends a request to the host dashboard. The host composes selected context and sends it to a model endpoint. Model responses return to the host; tool requests, if any, are handled separately. The host owns recording, configuration and capability decisions. Records supply selected context for later requests. The arrows represent possible data/request paths, not proof that an action succeeded. This is a conceptual diagram, not a deployment map or screenshot.
Components and responsibilities
| Component | Responsibility | What its presence does not prove |
|---|---|---|
| Desktop launcher | Locate/init a slot, start or locate its service, open a dashboard URL | A new identity exists or all startup phases succeeded |
| Browser dashboard | Display status, accept human inputs, issue host requests | Visible text is durably recorded; closing a tab stops the service |
| Host application | Load configuration, compose context, call model, record interactions and broker tools | Every requested external effect completed |
| Model endpoint | Return model output and possible tool requests | Output is correct, authoritative or itself an execution receipt |
| Local records | Retain identity events and interaction history through distinct paths | All retained content enters every future prompt |
| Plugin/machine facilities | Supply installed operations and shared runtime resources where available | A listed operation has an unrestricted grant or an effect is verified |
The same interaction at technical depth
- A composer submission enters the dashboard delivery path. Pending, accepted and recorded are distinct checkpoints; the conversation trace explains their visible implications.
- The host records ordinary interactions through its engine/store path.
recordConversationForReceiptroutes recording outcome to dashboard receipts for operator input. Resident replies have their own recording path; a failure can return visible text with an error. turnprompt.goassembles identity/working context and selected history under a prompt budget. It does not serialize the entire database into every call.- Provider resolution chooses an entry, model, authorization and token limits. The request goes to that resolved model endpoint. Tool results can join subsequent requests during the same turn.
- Requested actions require host handling. A provider reply saying an operation succeeded is not a host receipt. See tool/plugin boundaries.
- Later context selection can use retained records. Retention, selection and correct use remain separate questions.
This sequence is reconciled to the earlier explanation, not evidence of a replayed exchange. Safe-mode handling, asynchronous work and failures can change what is retained or displayed.
Separate the storage roles
The conventional installation root is .aii under the operator's home, with numbered identity-N slots. A slot is a location; a display name is not a stable substitute for verifying the intended identity. Never infer a live path by copying another operator's example.
- Signed identity ledger: the ordered record of identity events. Ordinary Chat messages must not all be described as ledger entries.
- Interaction/database state: stores conversation interactions and indexed/queryable material through host-managed paths. The application can expose database-format and recovery state; that does not make direct database edits a supported repair.
- Identity key: signing authority, not a harmless preference file. Preserve custody and do not put key material into issues or model prompts.
- Configuration and provider registry: host/operator settings, including sensitive authorization data or references. They are not model-authored identity claims.
- Backups and logs: different artifacts with different purposes. A log is not a backup; a snapshot is not proof of reproducible model behaviour.
See backup and restore before moving state. Do not manually patch a ledger or database to make an error disappear. A filesystem copy made while state is changing is not established here as a consistent backup.
Deployment and network boundary
Desktop launchers aim at loopback dashboard URLs. That local URL describes the browser-to-host hop, not the endpoint used for inference or every enabled service. Remote dashboard access changes the threat boundary: authentication, encrypted transport and origin configuration matter. This draft intentionally supplies no public-binding or reverse-proxy recipe; those operations require their own verified deployment procedure.
Architecture is descriptive, not a promise that the software prevents every possible attack. Privacy and permissions and configuration explain the operator's decisions and the limits of this review.
Implementation evidence
- cmd/aii-app/main.go
- internal/install/install.go
- internal/app/interaction_record.go
- internal/app/turnprompt.go
- internal/app/turnprompt.go — bounded conversation selection
- internal/app/provider_resolve.go — prompt budget
- internal/app/database.go
- internal/app/provider_resolve.go