CAI has 11 systems. They don't actually talk to each other.
What exists today is a shared inbox that the AI reads manually each session and carries information between systems in conversation. That is not inter-system communication. That is a human-shaped messenger doing what code should do.
The result: information arrives late, gets dropped, or requires David to be in the loop for things that should resolve automatically.
Synchronous inter-service communication means:
This is called REST/RPC (Remote Procedure Call). It is the backbone of how Netflix, Amazon, and every modern distributed system works.
Key rule from the research: Never use synchronous chains deeper than 2 hops. Cascading timeouts create failures worse than a monolith. For CAI: System A calls System B. System B does NOT then call System C to answer.
| Type | Item | Status |
|---|---|---|
| Strength | Each system has its own api.php — a real service endpoint | EXISTS |
| Strength | Community inbox — IS a message bus (async) | EXISTS |
| Strength | Transfers API — inter-system data passing | EXISTS |
| Strength | records.db — shared ledger, correct pattern | EXISTS |
| Weakness | No system can call another system's api.php directly | MISSING |
| Weakness | No system knows where the other systems' endpoints are | MISSING |
| Weakness | No standard request/response format between systems | MISSING |
| Weakness | No circuit breaker — if one system is down, callers hang | MISSING |
| Weakness | The inbox is async and the AI is the only consumer acting on it | MISSING |
Every system registers itself: who it is, where its api.php lives, what actions it accepts, and whether it is up. This already partially exists as jurisdiction.db — we extend it into a live service registry.
Table: service_registry Columns: decade, system_name, api_endpoint, status, last_ping, actions[] Owner: Admin [00] Location: systems/community/registry/api.php
A system that doesn't know where Finance [60] lives asks the registry. The registry answers. No hardcoded URLs between systems.
Every inter-system call uses the same envelope:
{
"action": "inter_system_request",
"from_system": "80",
"to_system": "60",
"request_type": "get_balance",
"payload": { ... },
"token": "[inter-system token]",
"request_id": "uuid"
}
Response:
{
"status": "ok" | "error",
"from_system": "60",
"request_id": "uuid",
"data": { ... },
"timestamp": "..."
}
Owner: Server [40] — add inter_system_request handler to all api.php files.
Today each system has its own token. System-to-system calls need a shared token that is not the owner token (USR369's token).
Owner: Admin [00] — generate and distribute via Server [40].
A single PHP endpoint that any system can POST to with a destination and payload. The router looks up the destination in the registry, forwards the request, and returns the response.
Location: systems/community/router/router.php Owner: Server [40] to build, Admin [00] to own
Why a router and not direct calls?
If Finance [60] is down, Kitchen [80] shouldn't hang waiting. The router tracks failure counts per system. After 3 failures: mark system unavailable, return error immediately, log to Admin [00] inbox.
Simple implementation: router tracks per-decade fail counts in SQLite. Reset on next successful call. No external library needed — approximately 20 lines of PHP.
Every inter-system call gets logged: who called who, what action, response status, response time in ms, and timestamp.
Location: systems/community/router/traffic.db Viewer: backend/sys-com/traffic.html (Admin [00] to build)
This solves a problem that exists today: when something goes wrong between systems, nobody can see what happened. The log makes it visible.
David is not in the loop. The AI is not the messenger. It just works.
These are proposed tasks. Master [10] assigns. Nothing starts until USR369 approves this document.
| Task | Owner | Description |
|---|---|---|
T-NEW-A | Admin [00] | Extend jurisdiction.db into service_registry — add api_endpoint, status, last_ping, supported_actions — seed all 11 systems |
T-NEW-B | Server [40] | Generate inter-system token — store in Server config — distribute to all 11 system configs |
T-NEW-C | Server [40] | Add inter_system_request handler stub to all 11 api.php files — stub returns ok — proves format works end to end |
| Task | Owner | Description |
|---|---|---|
T-NEW-D | Server [40] | Build router.php — accepts from/to/action/payload/token — looks up registry — forwards via curl — returns response — logs to traffic.db |
T-NEW-E | Admin [00] | Build circuit breaker in router.php — per-decade fail counts — short-circuit after 3 — notify Admin inbox |
T-NEW-F | Admin [00] | Build traffic viewer at backend/sys-com/traffic.html — timestamp / from / to / action / status / ms |
| Task | Owner | Description |
|---|---|---|
T-NEW-G | Finance [60] + Kitchen [80] | Kitchen requests budget summary from Finance — action: get_category_budget |
T-NEW-H | Master [10] + records.db | Any system requests its task list via router instead of hitting records-api.php directly |
T-NEW-I | Admin [00] | Health check on session open — Admin pings all 11 via router — replaces manual checks |
| Task | Owner | Description |
|---|---|---|
T-NEW-J | Admin [00] | Audit inbox message types — retire workaround types as sync calls replace them one by one |
Tight coupling: Synchronous calls mean if the router is down, inter-system calls fail. Mitigated by circuit breaker + fallback to current inbox method during outage.
Scope creep: Phase 3 use cases could multiply. Rule: only wire calls that TODAY require the AI to manually carry information. Everything else stays async until proven necessary.
Token security: Inter-system token must never appear in frontend JS. All calls are server-to-server only.