How Gridman is put together
Five entities and the links between them: everything else in the app hangs off that chain.
Gridman rests on a single chain: project → sequence → shot → version → comment. A project is a film, a commercial or a series. A sequence is a scene inside it. A shot is a single plate somebody owns and that has a due date. A version is the actual file brought in for review. A comment is a note pinned to a frame of that version.
- ProjectA film, a spot, a series. Code, dates, team
- SequenceA scene inside the project. Optional
- ShotA plate: due date, artists, status, brief
- VersionAn uploaded file: stage and number
- CommentA note on one frame of the version
- Status
- Due date
- Artists
- Brief
- Stage
- Verdict
- Proxy and thumbnail
- Drawings on frames
- Owner — everything in their own account
- Internal mini-account — projects they are allowed into, permissions set one by one
- Client mini-account — only the versions assigned to them in a review session
- Guest with a link — one shot, no account, for as long as the link lives
Sequences are optional: a small project lives without them and keeps its shots directly in the project. Everything else — statuses, stages, artists, links, watermarks — are not separate modules but properties of those five entities. Which is why it reads best top-down: first Projects and sequences, then Shots, then Versions and stages.
In the code and the API the central entity is called Shotman; in the interface it is only ever a shot. Same thing.









