rebrand Scirium docs (Wall-O -> Scirium) + add v1/v2 documentation package

This commit is contained in:
root
2026-08-16 09:24:58 -04:00
parent 0424b2954a
commit 64cf1043e7
11 changed files with 453 additions and 82 deletions
+9 -9
View File
@@ -1,4 +1,4 @@
# Wall-O: Product Model and Data Architecture
# Scirium: Product Model and Data Architecture
Status: PLANNED
First client: Wall Orthodontics
@@ -98,7 +98,7 @@ One row per AI persona. Bound to exactly one channel.
| agent_id | UUID | PK | Canonical identifier. |
| tenant_id | UUID | FK to tenants.tenant_id, NOT NULL | Multi-tenant isolation. |
| channel_id | UUID | FK to channels.channel_id, UNIQUE, NOT NULL | One agent per channel. |
| name | TEXT | NOT NULL | Agent display name, for example "Wallo Billing". |
| name | TEXT | NOT NULL | Agent display name, for example "Scirium Billing". |
| system_prompt | TEXT | NOT NULL | Domain-tuned persona and instructions. |
| kb_scope_id | UUID | FK to kb_scopes.kb_scope_id, NULL | What this agent may retrieve. |
| model_provider | TEXT | NOT NULL DEFAULT 'admin-ai' | LLM gateway. |
@@ -254,15 +254,15 @@ A staff member either @mentions the agent bot in a channel, or DMs the bot direc
Channel mentions are captured by an outgoing webhook integration configured on the channel with trigger word equal to the bot username. Rocket.Chat POSTs to:
```
POST https://orchestrator.wall-o.<domain>/api/v1/webhook/rocketchat/{tenant_slug}
POST https://orchestrator.scirium.<domain>/api/v1/webhook/rocketchat/{tenant_slug}
```
Headers:
| Header | Value |
|---|---|
| X-WallO-Signature | Hex HMAC-SHA256 of the raw request body, keyed by the tenant webhook secret. |
| X-WallO-Timestamp | Unix seconds. Reject if skew is greater than 300 seconds. |
| X-Scirium-Signature | Hex HMAC-SHA256 of the raw request body, keyed by the tenant webhook secret. |
| X-Scirium-Timestamp | Unix seconds. Reject if skew is greater than 300 seconds. |
| Content-Type | application/json |
Payload (Rocket.Chat outgoing webhook shape):
@@ -275,8 +275,8 @@ Payload (Rocket.Chat outgoing webhook shape):
"timestamp": "2026-08-15T12:00:00.000Z",
"user_id": "<rocketchat user id>",
"user_name": "jane.doe",
"text": "@wallo-billing How do I submit a PTO request?",
"trigger_word": "@wallo-billing",
"text": "@scirium-billing How do I submit a PTO request?",
"trigger_word": "@scirium-billing",
"bot": false
}
```
@@ -289,7 +289,7 @@ DM capture does not use this webhook. Rocket.Chat outgoing webhooks do not fire
Resolution order, all in one request context:
1. Authenticate: verify `X-WallO-Signature` against the tenant webhook secret looked up by `tenant_slug`.
1. Authenticate: verify `X-Scirium-Signature` against the tenant webhook secret looked up by `tenant_slug`.
2. Idempotency: derive `rocket_chat_message_id` from a hash of (channel_id, user_id, timestamp, text). If a `messages` row already exists with that id, return HTTP 200 immediately and do nothing. This deduplicates webhook retries.
3. Resolve channel: `SELECT * FROM channels WHERE tenant_id = ? AND rocket_chat_room_id = ?`, with a fallback match on `rocket_chat_room_name`/`slug`.
4. Resolve agent: read `channel.agent_id`, then `SELECT * FROM agents WHERE agent_id = ?`.
@@ -404,7 +404,7 @@ Steps 1 through 3 are idempotent API calls driven by an onboarding form in the o
## 7. Agent Identity and Response Citations
Identity: the bot posts with its own username and avatar (set at provisioning). Every answer is attributed to the bot user, never to a human, so staff can distinguish agent answers from colleague messages. The `system_prompt` instructs the agent to introduce itself as the channel's assistant (for example "I am the Wall-O assistant for Employee Resources") and to stay inside the domain.
Identity: the bot posts with its own username and avatar (set at provisioning). Every answer is attributed to the bot user, never to a human, so staff can distinguish agent answers from colleague messages. The `system_prompt` instructs the agent to introduce itself as the channel's assistant (for example "I am the Scirium assistant for Employee Resources") and to stay inside the domain.
Citations: retrieved chunks carry provenance in `metadata` (document title, section heading, page). During prompt assembly each chunk is labeled `[1]`, `[2]`, and so on. The orchestrator renders the final answer with inline `[n]` markers and appends a "Sources" footer listing each cited document title and a link (Microsoft Graph sharing link, or a Rocket.Chat file link). The full provenance (document_id, chunk_id, title, snippet, url) is stored in `messages.citations` as JSONB for audit and re-render. If the answer cites nothing, no footer is emitted.