How it fits together
The pages before this one describe the hub one feature at a time. These pages follow a single piece of work all the way through instead: what happens between your click and the page, between a request and its answer, between an agent's call and its result, and between a saved note and the tags that appear on it. You do not need them to use the hub. They are for when you want to know what is going on underneath.
Topics
- A page in the hub: the site, the shell and the feature that each render a part.
- A request in the backend: what a request passes through before it is answered.
- Where the routes come from: how the API, its reference and its SDKs all come from the database.
- Signing in from a sister site: how one sign-in reaches every site.
- An agent's call: the tool, the permission check, and the answer sent back.
- A background job: what happens to a note after you save it.
- Live updates: how a change in one place reaches a page in another.
- Environments: where the backend and the sites run, and the ladder to production.
One path for every caller. A browser, an SDK, the adh command line and an agent's gateway call all enter the backend through the same door, so usage, tenancy, feature gates and the audit record are written once.
Check hand-kept lists at start-up. Every list a person keys by hand, such as the exposure tiers, the sync registry and the feature areas, is checked against the schema when the backend starts, so drift is a failed start rather than a silent hole.
The database does the fan-out. The database announces a change, and every process listening hears it, so a write in one process reaches a stream in another with no broker in between.
The host supplies what only a host knows. The toolkit never reaches into a site. The site hands it the chrome, the workspace and the origin through named seams.