Glossary
The words CorPole uses, in one place.
For: Founder, Solo builder, Team developer, Product owner, Project lead, Tester, Admin, Evaluator, Security & compliance
Terms
| Term | Meaning |
|---|---|
| Authority | The state that makes a record binding for people and coding agents. When its initiative closes, a requirement becomes history: kept in the trail, no longer sent to agents as binding; what is built is described by the design records. |
| Solution | The product or system CorPole governs (formerly "project"). A tenant has several; each has components, such as a web app or a service, with their repositories. |
| Demand | A request: who asked, how, when and what. It lands in the Funnel of the Portfolio board and closes when all its initiatives close. |
| Initiative | The unit of change that answers demands: managed as a project, small work or urgent work. Requirements and work belong to an initiative; it is Done only when all its work is Done or Cancelled. |
| Maintenance initiative | Each solution's quarterly initiative for defects and upkeep. It rolls over each quarter, carrying open work. |
| Design record | Describes what the solution is today: BDR (business), FDR (functional), NFDR (quality), TDR (technical, per component) and ADR (architecture decisions). |
| Design change | A delta to a design record carried by an epic, story, task or defect, applied when that work is Done. |
| Draft / Approved | Informative states. Agents ask before relying on an Approved record and never treat a Draft as binding. |
| Retired | Kept for history; never drives new work. Retiring a record takes it out of every agent's context at once. |
| AI proposal | A record, change, relation, decision or work item an agent suggested. Nothing binds until a person makes it Authority; Approved means a person reviewed it. |
| Change proposal | A suggested edit to an existing record, shown as a difference that a person accepts or rejects. |
| Acceptance criterion | A separately tracked condition of a requirement (e.g. FR-001/AC2), Met or Not met. |
| Work context | What an agent reads before working on one item: why-chain, criteria, constraints, conflicts, decisions. |
| Kickoff interview | The agent-led interview that turns a new idea into Draft requirements before any code is written. |
| Onboarding | Bringing an existing codebase under governance through the "Onboard <solution>" initiative: findings become design drafts of the repository's component, for people to confirm, turn into defects or reject. |
| Handover tier | How far an existing solution has moved its authority into CorPole: Shadow, Shared or Full. |
| Agent policy | Per solution: which actions an agent may take on its own, only after asking, or never. |
| Agent rules | Behaviour rules for agents at platform, account, tenant, solution and personal level. |
| Notice | A message CorPole delivers to a person directly, not only through the agent. |
| Drift signal | A sign that an agent is going off course, such as retrying the same failing test or working without reading the rules. Agent health shows them. |
| Emergency | A time-boxed production emergency declared by a person allowed to: code gates advise instead of refusing, forbidden actions stay forbidden, and a defect tracks it. |
| Maker-checker | A second person approves what the first one prepared. |
| Personal agent token | A token that lets an agent act for one person, with at most that person's permissions. |
| Service token | A token for CI, such as the change-request check and test results. |
| Lesson / Improvement idea | What was learned, and what could be better. An accepted lesson can become a solution rule. |