One system from the requirement to the code, and back.
A requirement is governed, planned as work, handed to the agent with everything that constrains it, and verified by tests the agent and your CI report back. The pull request, the test run and the change are on the record. There is no second tool to re-enter them into.
One requirement, and everything currently holding it in place.
The record on the left is a requirement. Everything on the right is what currently constrains and proves it: the criteria it must meet, the records it refines and is constrained by, the tests that verify it and the story that implements it. This is the view the agent is given a scoped copy of.
What it saysThe requirement in its Authority state, with its acceptance criteria as separate items.
What holds itRelations, constraints, decisions, tests and code, each connected explicitly rather than inferred.
What the agent getsThe same picture through get_work_context, with retired records left out.
Activate a subscription only after payment is confirmed
AUTHORITY
AC1 Paid capability is unavailable until the provider confirms the payment. AC2 A failed confirmation leaves the account on its current plan. AC3 Every activation is recorded with its provider reference.
Criteria3 of 3 met
Tests4 passed
ChangedToday
RELATIONS AND TRACE6 links
OBJ-5B03D8refinesReduce failed activations
PC-0A7E61constrained byCard data never stored
TC-0B72E5verifies AC1Integration test · passed
ST-118D4CimplementsPR #214 merged
The loop
Six steps, and no second system.
No single step here is novel. What is different is that they are one system, so nothing is lost between them and nothing has to be re-entered somewhere else to be tracked.
01
Capture
A setup wizard walks from the project brief to objectives, requirements and constraints — typed by hand, suggested by AI, or reconstructed from an existing codebase.
02
Govern
Records move from Draft to Approved to Authority on a review board, with acceptance criteria and relations checked on the way. A second approver can be required.
03
Plan
Epics serve objectives, stories implement requirements and cover their criteria. Boards enforce the flow, WIP limits and blocking reasons.
04
Build with the agent
The agent asks for its story's work context: the requirements, criteria, constraints, decisions and tests that apply, and what changed recently. Policy says what it may do alone.
05
Verify
Test cases verify criteria. CI and the agent report results; criteria turn Met or Not met, and a failing test keeps the story open.
06
Trace
Pull requests and commits link themselves by code, the story moves when the PR opens and merges, and every change lands in history.
Go deeper
Three parts of the loop worth a closer look.
The loop above is the shape. These are the three places where the detail matters most.
01
What governs now
How a record moves between Draft, Approved, Authority and Retired, and why the retired state does the real work.
Onboarding reads what the repository already says and proposes records for a person to confirm. Nothing it finds binds the agent until someone approves it.
01
Evidence first, guesses last
Deterministic extraction runs before any model. Sources are weighed in order: tests, then documents, then code, then commits.
02
Governance where the agent is working
Each code module gets a maturity level. Govern the area the agent is about to touch, not the whole estate on day one.
03
Advisory or enforced
Start with advice on ungoverned areas. Switch a project to an enforced gate when the records are ready to carry it.
When there is a team
The same records, shared with the right people.
One developer and one project need none of this. It appears when there are people and projects to manage.
01
Roles you define
Access from owner to viewer and auditor, plus roles such as product owner, analyst, architect, developer, tester and risk owner — redefine them from 18 permissions per account, several per person.
02
Projects for the people on them
A project is visible to the people added to it. Tenants can open a project to everyone in the tenant when that is the point.
03
Maker-checker when you need it
Switch on a second approval for records per tenant: the person who proposes cannot be the one who approves.
04
Several tenants, one account
Keep business units or clients apart in tenants under one account, and publish standards or glossary terms to all of them.
Connect your coding agent
One MCP server, three ways in.
Claude Code, claude.ai, Claude Desktop, Cursor and any MCP client read the same Authority records. Sign in with OAuth, pick a project, done.
01
Remote MCP server
Streamable HTTP at corpole.com/api/mcp, with OAuth or a project token. Listed in the official MCP Registry as com.corpole/requirements.
Connect one project. Onboarding returns the requirements, decisions and constraints that appear to govern it today, and asks you to confirm or retire each one.