gramps/cAIc
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: document data isolation rationale for two-channel split

Browse Source
This commit is contained in:
gramps
2026-07-06 19:06:05 -07:00
parent bb40748d95
commit 46adecfce0
1 changed files with 9 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TASKS.md
+9 -5
View File
@@ -526,12 +526,16 @@ NONE ──register(node_type=coordinator)──▶ CLUSTER_COORDINATOR set
Every `_push_event()` call uses one of these two categories. The `message` field carries the human-readable detail — no need for event type strings. The reporting tool filters by category + severity.
**Channel split:**
**Channel split — security rationale:**
| Exchange | Event scope |
|----------|-------------|
| `jc.admin` | Cluster nervous system — `register`, `deregister`, `admitted`, `rejected`, `hb_query` |
| `jc.system` | Application events — `heartbeat`, `event` (syslog), `coord_query`/`coord_response` |
The two exchanges are not an organizational convenience. They enforce a **data isolation boundary**:
| Exchange | Contains | Exposed to |
|----------|----------|------------|
| `jc.admin` | Node lifecycle, heartbeats, model swaps, coordinator changes | Operations / machine-room staff |
| `jc.system` | Application events — inference queries, RAG context, user-facing data | Application-layer audit only |
`jc.system` events can leak information about what users are doing and asking. The split ensures a sysadmin monitoring cluster health never accidentally consumes user-data-bearing events. The channels can be locked down independently — different AMQP credentials, separate queue permissions, different in-transit encryption policies if needed later.
### 11.4 Implementation