Before you start
How to read this
Datum Cloud described from the outside — what it is for, what it is made of, how a change and a request travel through it, where it runs, and what it guarantees. Nineteen projections in six groups. Every page reads general to specific: plain language first, mechanisms next, and the evidence for each claim beside it in the margin.
Every projection opens in plain language — no jargon, no resource names, just what the thing is and the few points worth remembering. Then it keeps going. There is no control to press and no depth to choose: read down a page and it gets more specific by itself, and you stop where you have what you came for.
- Plain language — ordinary words. No Kubernetes knowledge assumed.
- Worked examples — real commands and manifests we ran, with what to notice.
- How it works — mechanisms, the names of things, the figures we measured.
- How we know — the mark on each claim, and the source in the margin beside it.
A ruled line names each change of register, so you always know which one you are reading.
You never have to leave the page to look a word up. Any term or abbreviation with a dotted underline explains itself — point at it, or reach it with the keyboard and it opens on focus. Try the one in this sentence.
Datum is under active development, and is a few months old. Behaviour changes between releases, releases are not announced, and the deployed version is not readable from a customer seat. Treat every claim as true on the date in the header and verifiable by the method its mark names — not as a permanent property.
Each claim carries one of four marks, used identically on every page:
| ● Ran it | Executed against the production API and the result observed. The strongest mark here. |
| ◐ Read the source | Read in a public repository — the path is a link, so you can open it yourself. Establishes intent and design, not that production runs it. |
| ○ Documented | Stated by Datum. Not independently verified. |
| △ Inferred | Our reading of the above. A hypothesis, and labelled as one. |
Three registers, kept apart on purpose. A sentence describes the system as it is designed. A line marked what Datum says it is building comes from their public enhancements catalogue — the direction, not a promise of a date. A line marked what we measured is ours, on one account and one connection, on the date above; those carry a finding identifier you can click, and the show what we found control hides them all if you would rather read the architecture without them.
Standing limits. This is a reconstruction from outside, not Datum's own architecture documentation; where a mechanism could not be established from a customer seat it says so rather than filling the gap. Merged is not deployed: a repository shows intent, and whether production runs that code — and under which flags — is not observable from a customer seat, so a ◐ mark never implies live behaviour.
Canonical detail lives in the working notes:
explore/hands-on/notes/FINDINGS.md for defects, CAPABILITIES.md for what
the product lets you do, BACKLOG.md for coverage, and CONTEXT.md for the
glossary. This page draws them together; it does not replace them.
Scope of evidence: one organisation, one project, one client machine on a CGNAT'd network. Absence of a defect here is not evidence of its absence elsewhere. Where a figure would vary with scale or geography, it is a shape to expect rather than a constant.
Badges give our coverage of an area (deep,
partial, none) and, when the findings
layer is on, the worst severity recorded against a part
(High · Medium ·
Low, with ×n when there is more than one). Colour
never carries meaning alone — every item is also labelled.