One core database, a schema per site.
teleon.dev/docs/db holds the shared core tables every service reads: entities, executable payloads, annotations, weighted graph edges and bitemporal facts. Each site keeps its own tables in its own schema beside the core.
Every site reads the shared core and keeps its own tables in its own schema.
What it does
Shared core
Universal tables live in teleon_core and serve every site the same way.
A schema per site
Site-specific tables live in surface schemas, kept apart from the core.
Row-level security
Access rings decide which rows each caller sees.
The contract
Code bytes and their descriptions are stored apart, so a description can change while verified code stays as it is.
teleon_core.*surface_<slug>.*teleon_dual_track_request/v1teleon_boundary_isolation/v1
Endpoints
| Method | Path | Access | What it does | Status |
|---|---|---|---|---|
GET | /v1/health | RING-3 | Read health and replication lag | |
GET | /v1/schemas | RING-1 | List core and site schemas with versions | |
POST | /v1/migrations/plan | RING-1 | Plan a schema change through the gate |
Listed paths appear in the service’s published files today. In the one-host plan every path here is served under api.teleon.dev/v1/db.
How it connects
For agents
Give your agent the read-only guide first. It reports back before any write.
Words on this page
- Access ring
- One of four access levels. RING-0 is internal operations, RING-1 operators, RING-2 keyed agents and sites, RING-3 public reads.
- Partition
- One slice of a large table, chosen by a key such as site or queue, so reads and writes stay fast.
- Bitemporal
- A record that keeps two times: when a fact was true in the world and when the system learned it.
- Sister track
- The improvement track that runs beside each database: it tunes priorities, synonyms and steps behind holdout checks.