Records & authority
Record types, the four states, writing and approving.
Records are the heart of CorPole: objectives, requirements and constraints, each of a specific type and each with a state. They answer the question your agent asks before every change — “what must this change achieve, and within which limits?” This section explains the ten record types, the four states and how records move between them.
Requirements say what should change, and each belongs to an initiative, which answers a demand (who asked, how, when and what) on the Portfolio board. What the solution is today lives in its design: BDR, FDR, NFDR, TDR and ADR records. Design is never edited directly; the work that implements a requirement carries a design change, applied when the work is Done.
Writing a good record is a skill. An agent follows a requirement literally, so vague words like "fast" or "easy" produce vague code. The articles here show how to write one testable statement with a reason and acceptance criteria, how to review what an agent proposes, and how to accept or reject a change proposal when an agent thinks a record should read differently.
State changes are how you steer the agent. Making a record Authority makes it binding; retiring it takes it out of every agent's context at once. Records are retired rather than deleted, so the history of what held when, and why, is never lost.
You will also find the screen guides for creating, reading and editing records, the design, demands, initiatives and the Portfolio board, the Explorer that shows every type side by side, and the change history that records who changed what and why.
Articles in Records & authority
- GuideObjectivesA measurable outcome the solution exists to achieve. Objectives explain why everything else matters.
- GuideBusiness RequirementsWhat the organisation needs from the solution, stated without describing how it is built.
- GuideStakeholder RequirementsA need of a specific group of people, usually written as a user story.
- GuideFunctional RequirementsA behaviour the system must gain or change: what it does in response to a user or event. Behaviour it already has is described in FDR design records.
- GuideNon-functional RequirementsA quality the system must meet: performance, security, accessibility, reliability.
- GuideTechnical RequirementsA technical need the change must meet — technology, architecture or interface — for one component. How the component is built today is kept in its TDR and ADR design records.
- GuideProject RequirementsSomething the solution must deliver besides the product itself: deadlines, documents, test suites.
- GuideProduct ConstraintsA limit on what the product may be or do.
- GuideBusiness ConstraintsA commercial, legal or organisational limit.
- GuideProject ConstraintsA limit on how the solution is run: team, budget, tooling, time.
- GuideExplorerA wide, multi-column view of the active solution: every record type gets its own column so you can read objectives, requirements and constraints side by side.
- GuideNew recordCreates one objective, requirement or constraint in the active solution.
- GuideRecord detailEverything about one record: statement, rationale, acceptance criteria, state, priority, owner and source.
- GuideEdit recordChanges a record's content or state. The change is visible to AI agents immediately.
- GuideSolution designThe design records describe the solution as it is today: business design (BDR), functional (FDR), non-functional (NFDR), technical per component (TDR) and architecture decisions (ADR). Requirements belong to initiatives and say what should change; the design belongs to the solution and changes only when the work that carries a change is Done.
- GuidePortfolio boardThe workspace's Lean Portfolio Kanban: demands come in on the left, are linked to initiatives in Reviewing, and initiatives move through their mode's steps to Done. WIP limits keep each step from filling up.
- GuideInitiativesAn initiative is the temporary work that answers one or more demands and changes one or more solutions. It is managed as a project, as small work or as urgent work; the mode decides its steps.
- GuideDemandsEvery request that comes in — from a person, a business unit or a customer — is a demand. It starts in the Funnel with its assessment against the solution, is linked to an initiative in Reviewing, and closes when all its initiatives have closed. No work is done without a demand.
- GuideAssess a requestPaste an e-mail, a ticket or a note from a meeting; each ask in it is compared with the solution: new, already there, partly there, retired before, or in conflict with a number or limit that is written down.
- GuideChangesThe solution's change history: every change to records, acceptance criteria, relations, work, knowledge, tests and code links, with who made it, what changed and why. It cannot be edited.
- How-toWrite a requirement an agent can followOne testable statement, the reason in plain words, and criteria that a test can check.
- How-toReview an AI proposalAgent proposals are Drafts with an AI proposal badge. Nothing binds until a person makes it Authority; Approve marks it reviewed.
- How-toAccept or reject a change proposalAgents cannot edit records. A change arrives as a difference you accept or reject on the record page.
- How-toRetire or replace a recordRetiring takes a record out of every agent's context at once. Replace it when something new takes its place.