How the data fits together
What are the core things in the system, and how do they relate?
Eleven entities, the exact words that connect them, and one rule repeated everywhere: records hold references, never contents.
Drag to pan, scroll to zoom, click an element to trace it.
Open full screenWhat to look for
- Workspace in the middle, and how many arrows terminate on it.
- The chain Post → DeviceJob → JobEvent, and the phrase "one job per occurrence".
- The sublabels on SocialAccount and MediaAsset — both say what is *not* stored.
Read the full explanation
Every record in Cradle belongs to exactly one workspace. That is the tenant boundary, it is on every key, and it is checked on every request — which is why the workspace sits at the centre of this diagram rather than off to one side.
The most consequential decision here is what has *not* been merged. A Post is an intent to publish. A DeviceJob is one instruction to one device — a post that runs on three accounts becomes three jobs. A JobEvent is an ordered record of what actually happened. Collapsing any two of these would make the survivor wrong: you would lose either the ability to retry one account without touching the others, or the history of what a device really did.
The other rule the diagram repeats is references, never contents. A Post holds media identifiers, not video. A MediaAsset holds an S3 key, not bytes. A SocialAccount holds a vault identifier, not a password. Read the sublabels around the edges and you will see the same discipline applied at every hop.
Devices are worth a second look. A device carries three separate state axes — where it came from (owned or rented), whether it can be reached right now, and what it is currently doing. Keeping them apart is what lets a rented, offline, reserved device be described accurately instead of squeezed into one confusing status.
Engineers, and anyone who needs to reason about what a workspace contains.