Reference
Glossary
The words we use across the product and this site, in plain language. If something here is doing work you did not expect it to do, that is our fault rather than yours.
- Board
- A live architecture model of a system, landscape, decision, or planned change. It is the central object in ProvenMap: everything else here either describes part of a board or something that happens to one.
- Dependencies
- What one element on a board depends on, what depends on it, and the route between two elements. The result is drawn from the boards, so the same boards always give the same result.
- Drift
- The gap between the architecture you intended and the one you actually have. Drift is normal and accumulates quietly; ProvenMap shows the gap between model, source, and shipped reality instead of hiding it.
- Editor
- A member who can change your organisation’s content, and so holds a billed seat. Admins are editors too.
- Insight
- Something the analysis noticed across your systems that you did not ask about — an unexpected dependency, a boundary that has eroded, a component nothing calls any more.
- Layer
- A board has real depth. Open any node and you drop into its child layer — the same view, one level further in. A service on the top layer becomes its own map of modules underneath.
- Playbook
- A guided track for one job your team repeats, laid out as named stages and steps. Each step hands you to where the work happens, and the board ticks it only when the thing it asked for exists. It ends on a proof: a published board, a confirmed change, or a named person saying it landed.
- Provenance
- Where a fact came from and how it was established. It is the root of the name: a ProvenMap is one whose claims can be traced back to the source, model, or decision they came from, rather than taken on trust.
- Ready to build
- The check a new app passes before developers start on it: the founding work item has landed, the sequenced work items are written, and at least one coding skill is switched on. It is read from the board each time, not ticked by hand.
- Scheduled run
- A run of the code plugin on a schedule you set, such as a Claude Code scheduled task, with nobody at the keyboard. It refreshes the boards whose code changed, or re-checks production signals and evidence, and is recorded on the board whatever its result, with the reason when it stops.
- Source
- Whatever grounds a board: a repository, document, work item, decision record, or architect-authored model. A board can have a governing source and reference sources it reads to understand the wider estate.
- Verified
- Checked against the code, not asserted. When a work item changes the structure of a board, a later sync looks for that change in the code, and the work item is marked Confirmed only once it is found. A work item written only in prose closes on the developer's word, and never carries the mark.
- Viewer
- A member who can read every board, work item and insight their access allows but change nothing. Viewers are free on every plan and never hold a seat.
- Work item
- A living spec: what you want changed and why, authored against the board and anchored to the nodes it touches. Unlike a written spec it does not freeze at hand-off — developers pull work items into their coding session, implement them, and sync the result back, and the work item carries the evidence of whether the code actually matches. A work item is the unit that travels from decision to code, and the record of that decision afterwards.