Integration Architecture
One System Behind Every Product
Scribe and Planner are not separate systems that happen to talk to each other. They share one body of knowledge, so what one learns, the other can use. InTrade-AI is planned to join. This page describes how the parts are designed to fit together; where a part is still being integrated, we say so.
The Integration Problem
When you build several specialized systems, you face a choice:
Option A: Fragment Separate systems, each with its own database, its own logic, its own knowledge. They call each other's interfaces. Fast to build, but:
- Knowledge in system A does not inform decisions in system B
- Each system re-learns the same patterns
- There is no shared memory or shared learning
Option B: Centralize One large system that does everything. The knowledge is shared, but:
- One failure can stop everything
- Specialized abilities are hard to improve
- It is hard to understand, because too many concerns sit in one place
Option C: One Shared Base (Our Design) Several specialized systems, each with its own boundary, all coordinated through one shared body of knowledge.
- Each system stays lean and specialized
- The systems learn from each other
- A failure in one should not bring down the others
- The shared base is the source of truth
The Two-Layer Integration Model
Layer 1: Knowledge (hub and spoke)
Each specialized capability connects to the one shared body of knowledge. When Planner needs to reason about something, it asks the shared base. Scribe works on its own and is also integrated inside Planner. InTrade-AI is planned to join. Future capabilities follow the same pattern.
Planner (with Scribe inside) → Shared knowledge
InTrade-AI → Shared knowledge (planned)
(Future capabilities) → Shared knowledge
Result: knowledge flows through one place, so decisions can draw on everything the system knows.
Layer 2: Abilities (point to point)
Specialized systems call each other for specific abilities. A registry records what each part may ask of the others.
Planner asks Scribe to open an intake session
A future scheduling app asks Planner to add an item to a plan
A future notification app asks Scribe to start a voice intake
Result: abilities can be combined. A new app can find and use an existing ability through a registered connection.
Exposed Achievements, Not Steps
This is the key principle that keeps the architecture from fragmenting.
Each component tells the others what it achieves, not how it does it.
Scribe achieves: structured intake from voice, text or images. It takes what was said or written and produces knowledge in a form the shared base can use.
The shared base achieves: intelligence. It takes an intent and produces a result. The steps inside (transcription, analysis, extraction, iteration, synthesis) are invisible to callers.
Planner achieves: a visual interface. It takes the shared knowledge and produces a map that people can navigate. How it draws that map is invisible to callers.
InTrade-AI, when it joins, will achieve: financial analysis. It will take market data and produce investment recommendations. How its agents work together will be invisible to callers.
When components expose what they achieve instead of how:
- Callers do not depend on internal details
- Each component can improve internally without breaking the others
- The connection surface stays small and stable
How Parts Refer to Shared Knowledge
When Planner asks the shared base to create something, the base gives back a handle: a stable reference to what was created.
Planner keeps the handle. The base records who holds it.
If Planner is deleted or asks for a cleanup, it gives the handle back. The base then applies its own rules to decide whether to keep, archive or clean up what was created.
Why this matters:
- Planner does not manage the base's records directly, so the two stay separate
- The base is never surprised by a deletion, so it stays consistent
- The registry records exactly what was created, by whom and when, so nothing happens silently
This is the same rule as everywhere else in the system: every action between parts has a trigger, an action and a recorded result.
Component Autonomy With Shared Learning
Each component keeps its own boundary:
- The shared base owns all the knowledge and how it connects
- Planner owns its workspace and project maps
- Scribe owns its intake records and audio
- InTrade-AI will own its analysis models and recommendations
They are not isolated, though. The design lets knowledge flow between them through the shared base. What Scribe captures can inform Planner, and what Planner structures informs the base's reasoning. When InTrade-AI joins, its recommendations and the reasoning behind them will become part of the same knowledge.
Result: each part stays focused on its own domain, while what one part learns is available to the others.
Adding New Parts Later
When a new need becomes visible, a new part can be added. It:
- Declares its role
- Declares what it achieves, not how
- Connects through the two layers: knowledge through the shared base, abilities through the registry
- Keeps its own data boundary
- Joins the shared learning
No redesign is needed. The architecture is designed so that new parts can join.
How It Works
These pages explain how each claim is designed to work. We are adding evidence you can look at yourself, one proof at a time.