CLA AI Hub

Intelligence Architecture

Decision Operating System · v233 · April 2026

0. System Definition

1. Architecture Overview

The system operates across six core intelligence layers, extended by four operational layers, each designed to operate independently, degrade gracefully, and contribute to a unified decision flow.

End-to-end flow

2. Layer 1 — Live Data Aggregation

3. Layer 2 — Predictive Patterns

4. Layer 3 — Cross-Practice Detection

5. Layer 4 — AI Intelligence

6. Layer 5 — Decision Operating System

7. Layer 6 — Trust Architecture

7b. Layer 7 — Counterfactual Simulation

7c. Layer 8 — Economic Impact Engine

7d. Layer 9 — Autonomous Escalation

7e. Layer 10 — Confidence Calibration

8. Decision Flow

The system operates as a closed loop:

Data → Signal → Case → Action → Outcome → Learning → Better Signal

This creates compounding intelligence, improving recommendations, and institutional memory.

Extended loop (Wave 2-4)

Case → Scenario Simulation → Economic Pricing → Decision
                                                    ↓
                                              Action → Outcome
                                                    ↓
                                              Learning → Calibration → Better Signal
                                                    ↓
                                              (No action?) → Auto-Escalation

The system does not reset. It learns continuously.

9. Priority Score Engine

Every decision is ranked using a multi-factor scoring model. This defines urgency and drives triage.

The score converts complexity into clarity.

10. Data Pipeline

Practice data ingested
    ↓
Signals generated
    ↓
Decision cases created
    ↓
Intelligence assembled
    ↓
User acts
    ↓
Outcomes recorded
    ↓
Learning updated

This ensures: no black boxes, no orphan insights, no lost decisions.

11. System Doctrine

Pending Work & Trust Layer

12. Strategic Positioning

This architecture establishes CLA AI Hub as:

Not a dashboard. Not an analytics tool. Not a workflow manager.

A firm-wide decision infrastructure layer.

It sits above systems of record and systems of execution, and governs: risk detection, decision structuring, action orchestration, and institutional learning.

13. Final Definition

14. System Surfaces

15. Roadmap

16. Shared Module Ecosystem

Eighteen client-side modules in /shared/. Each is a drop-in capability any tool can import via a single <script> tag. This is the layer that lets us add features across the fleet with one commit instead of thirty.

17. Cross-Tool Handoff Mesh

The Hub is not a menu. It is a mesh. Every tool knows how to pass a client, a draft, an action, a decision into the next tool without a copy-paste. Two conventions carry the traffic:

17.1 The ?client=<name> URL protocol

Any link that navigates to a tool and carries a ?client= parameter lands with that client pre-filled. Receiving pages hydrate from URLSearchParams on load and trigger whatever downstream behaviour needs the name (Client 360 refresh, prior-brief lookup, placeholder update, etc.).

Currently hydrated: /briefing/, /command/, /drafter/. The pattern is one four-line block per page — any tool can adopt it.

17.2 The cla_output_handoff localStorage payload

When a tool wants to pass generated content (not just a name), it writes a structured payload to localStorage.cla_output_handoff and redirects. The destination reads and clears the payload on load.

17.3 Kind → destination routing

Encoded in ClaOutput.ROUTES:

18. Anticipatory Layer

Behaviours that surface content the partner will need, before they think to ask. Ten mechanisms currently live — each one either saves a click or saves a memory.

19. Self-Improvement Loop

The Hub observes its own use daily and adapts. One loop, four phases:

 OBSERVE                AGGREGATE              DISTRIBUTE              ADAPT
 ─────────              ─────────              ──────────              ─────
 login-track       →    /api/learnings    →    /shared/learnings.js  →   tools reorder
 tool-data                (7-day window)       (30-min sessionCache)      defaults,
 cla_tool_activity       JSON snapshot                                    surface rank,
 cla_sync_ts_*                                                            mode priority
 feedback-hub

19.1 Contract — /api/learnings

Returns a JSON snapshot that any tool can consume. Shape is append-only — consumers can ignore fields they don't know about.

{
  ok: true,
  generated_at: ISO,
  window_days: 7,
  tools:   { <tool_id>: { visits, unique_users, last_used_at, percentile } },
  firm:    { active_today, active_week, tool_count_used },
  top_tools: [ { id, visits, unique_users, last_used_at } ],
  quick_prompts: { top_picked: [...], least_picked: [...] },    // future
  friction: [],                                                   // future
  regulatory_pending: N
}

19.2 Current consumers

• /manual/ — Section 3 (tool inventory) and Section 6 (firm metrics) both render from ClaLearnings.get().
• Planned — homepage Quick Actions reorder by usage rank, Briefing mode order by pick frequency, Cowork quick-start reorder, emerging-tool callouts.

19.3 Design boundaries

• No schema migration on the hot path. The learnings API aggregates on-demand from the stores that already exist. If a new signal is needed, we add it to an existing store first, then compute it in the aggregator.
• Cached 30 min client-side, 30 min at edge. Two partners in the same hour share one query. The loop prioritises stability over instant reactivity — we want the Hub to adapt to this week's firm pattern, not to the last five minutes.
• Adaptation is additive. The learnings signal is used to sort and surface, never to hide — a tool that scored zero this week still appears in every index, because "nobody used it" is data, not a reason to make it invisible.