# CorPole > CorPole is a requirements authority for teams that build software with AI coding agents. Every objective, requirement, constraint and decision carries a state (Draft, Approved, Authority, Retired); coding agents such as Claude Code connect over MCP and receive only what binds today, with acceptance criteria, constraints and decisions for the task in hand. People decide what binds; agents propose. Work items, tests and code trace back to the records they serve. Operated by Projera Partners. Data is stored in the EU (Frankfurt). The remote MCP server is https://corpole.com/api/mcp (Streamable HTTP, OAuth or a personal token). Contact: info@projera.com. ## Product - [CorPole](https://corpole.com/): An agent reads exactly what you hand it, on every run. CorPole keeps your requirements, decisions and constraints with a state on each and hands the agent only what is in force today. - [Pricing](https://corpole.com/pricing): Per-developer pricing for CorPole. Plan fees cover platform access and the listed capabilities; model consumption terms are disclosed before purchase. Enterprise starts with a bounded pilot. - [Product](https://corpole.com/product): CorPole governs requirements, plans the work, hands the coding agent only what binds, and traces every criterion to its tests and code. - [What governs now](https://corpole.com/product/specification-workspace): Draft, Approved, Authority, Retired. CorPole keeps a state on every record, so the agent reads only what binds and a retired decision cannot come back. - [Governed context](https://corpole.com/product/ai-context): CorPole hands your coding agent the requirements, criteria, decisions, constraints and standards that bind its task, through MCP, and records what it read and proposed. - [Traceability and quality](https://corpole.com/product/traceability): CorPole ties every acceptance criterion to its tests, work and code, updates criteria from CI results, keeps failing work open and records defects and risks against the requirements they affect. - [Request access](https://corpole.com/request-access): Ask for a CorPole workspace. ## Learn: the concepts - [Why building software is hard](https://corpole.com/learn/why-software-is-hard): Most software does not fail because the code is bad. It fails because what was built is not what was needed, and nobody noticed in time. - [What AI coding agents change](https://corpole.com/learn/ai-agents-change-the-game): Agents make building fast. They also turn every weakness in how a team agrees what to build into a faster, larger problem. - [The requirements chain](https://corpole.com/learn/the-requirements-chain): From why a solution exists to how it is built: how objectives, requirements and constraints connect, and why each link matters to an agent. - [Clinic Booking, from idea to proof](https://corpole.com/learn/clinic-booking): One small solution followed from the first request to a change after launch, so you can see where every concept fits and what the agent receives at each step. - [Objective](https://corpole.com/learn/objective): A measurable outcome the solution exists to achieve. Every other record should trace back to one. - [Business requirement](https://corpole.com/learn/business-requirement): What the organisation must be able to do to reach an objective, stated without saying how the system does it. - [Stakeholder requirement](https://corpole.com/learn/stakeholder-requirement): What a specific group of people needs, in their own terms, usually written as a user story. - [Functional requirement](https://corpole.com/learn/functional-requirement): A behaviour the system must have: what it does in response to a user or an event. - [Non-functional requirement](https://corpole.com/learn/non-functional-requirement): How well the system must work: speed, security, reliability, accessibility, scale. - [Technical requirement](https://corpole.com/learn/technical-requirement): A binding technical or architectural decision about how the system is built. - [Project requirement](https://corpole.com/learn/project-requirement): Something the solution must deliver besides the product itself: training, documents, a test suite, a migration. - [Product constraint](https://corpole.com/learn/product-constraint): A limit on what the product may be or do. - [Business constraint](https://corpole.com/learn/business-constraint): A limit that comes from the organisation, the market or the law. - [Project constraint](https://corpole.com/learn/project-constraint): A limit on how a change is delivered: time, budget, team, tools. - [Demand](https://corpole.com/learn/demand): A request for change, recorded as it arrived: who asked, how, when and what. - [Initiative](https://corpole.com/learn/initiative): The change that answers one or more demands: its requirements, its work and its plan. It ends when the change is delivered. - [Design record](https://corpole.com/learn/design-record): A description of what the solution does and how it is built today. It changes only when work that changes it is Done. - [Component](https://corpole.com/learn/component): A part of the solution that is built and delivered on its own: a web app, a mobile app, a service. Its code lives in one or more repositories. - [Acceptance criterion](https://corpole.com/learn/acceptance-criterion): A condition that must hold for a requirement to count as met. It turns "done" from a feeling into a check. - [Test case](https://corpole.com/learn/test-case): A repeatable check that proves one or more acceptance criteria, automated or run by a person. - [Theme](https://corpole.com/learn/theme): A strategic focus area that groups epics for quarters or years. - [Epic](https://corpole.com/learn/epic): A large piece of value or a capability, delivered over weeks or months and broken into stories and tasks. - [Work package](https://corpole.com/learn/work-package): A delivery container with an owner, dates and a budget. It says when and by whom, not what for. - [Story](https://corpole.com/learn/story): A small piece of work that involves code, delivered in days. The unit a coding agent works on. - [Task](https://corpole.com/learn/task): Work without code: configuration, access, records, operational or documentation steps. - [Defect](https://corpole.com/learn/defect): Something that does not behave as a requirement, a design record or an acceptance criterion says. - [Decision](https://corpole.com/learn/decision): A choice with its context, the options considered and its consequences, kept so nobody has to guess later. - [Question](https://corpole.com/learn/question): An open point that needs a person's answer, with the working assumption used until it is answered. - [Glossary term](https://corpole.com/learn/glossary-term): A word of the shared business language, with its definition and the words to avoid. - [Standard](https://corpole.com/learn/standard): A rule for how work is done: coding, security, testing, compliance, definition of ready or done. - [Lesson](https://corpole.com/learn/lesson): Something learned the hard way in this solution, and what to do instead next time. - [Risk](https://corpole.com/learn/risk): Something that might happen and would hurt objectives, requirements or delivery. - [Technical requirement vs project requirement](https://corpole.com/learn/technical-vs-project-requirement): Both sound like "things the team must do". One is about how the product is built; the other is about what a change delivers besides the product. - [Business requirement vs stakeholder requirement](https://corpole.com/learn/business-vs-stakeholder-requirement): One says what the organisation needs; the other says what a specific group of people needs to get there. - [Functional vs non-functional requirement](https://corpole.com/learn/functional-vs-non-functional): What the system does, and how well it does it. - [Requirement vs constraint](https://corpole.com/learn/requirement-vs-constraint): A requirement says what must be achieved. A constraint limits how it may be achieved. - [Theme, epic, story, task and work package](https://corpole.com/learn/theme-epic-story-task): Five words for work at different sizes, and one for when and by whom it is delivered. - [Stakeholder requirement vs story](https://corpole.com/learn/stakeholder-requirement-vs-story): Both are often written "As a …, I want …". One is a need the change must meet; the other is a piece of work that delivers part of it. - [Decision vs standard](https://corpole.com/learn/decision-vs-standard): A decision settles one question with its reasons. A standard is a rule for all work of a kind. - [Defect vs risk](https://corpole.com/learn/defect-vs-risk): A defect has happened. A risk might. - [Question vs assumption](https://corpole.com/learn/question-vs-assumption): A question is what you do not know yet. An assumption is what you act on until you do. ## Help center ### Getting started First steps, the main screens and how a solution begins. - [Overview](https://corpole.com/support/getting-started/overview-screen): The home page of the active solution: how many records it has in each state, which AI proposals are waiting for review, and shortcuts to the record catalogue. - [Solutions](https://corpole.com/support/getting-started/projects-screen): All solutions of your tenant. The active solution decides which records you see everywhere in the app and which records AI agents receive. - [New solution](https://corpole.com/support/getting-started/create-a-project): The first step of the guided setup: name the solution and describe its context. The context is what AI suggestions later build on. - [Start](https://corpole.com/support/getting-started/start): One question — what are you starting? — and three paths. Each step asks only what belongs where it is kept: why a change is wanted (Demand), what the system is (Solution), and the change itself (Initiative). - [Guided setup](https://corpole.com/support/getting-started/guided-setup): Builds the solution's first requirement set, one record type at a time, from the solution brief to objectives, requirements and constraints. - [Maturity](https://corpole.com/support/getting-started/maturity): How sound the solution is today on five dimensions, levels 0 to 4, against the target of its profile — and what the next level needs. - [What CorPole is, and what it is not](https://corpole.com/support/getting-started/what-corpole-is): CorPole keeps your requirements, decisions and constraints with a state on each, and hands coding agents only what binds today. - [Why only Authority binds your agent](https://corpole.com/support/getting-started/why-only-authority-binds): An agent reads exactly what it is handed, every run. If everything in the repository looks current, stale decisions steer it. States fix that. - [Your first 15 minutes as a solo builder](https://corpole.com/support/getting-started/your-first-15-minutes): Connect Claude Code, run the kickoff interview, approve what binds and let the agent plan the first story. - [Your first day in a team solution](https://corpole.com/support/getting-started/your-first-day-in-a-team-project): Connect your agent under your own name, set up your clone, and pick up a Ready story. - [Evaluating CorPole: a 30-minute trial plan](https://corpole.com/support/getting-started/evaluating-corpole): Try the loop that matters: a requirement agreed, a conflict stopped, a change proven. - [Start a solution without opening the web app](https://corpole.com/support/getting-started/start-a-project-from-the-chat): Tell your agent you want to start a solution; it creates it for you and runs the kickoff interview. - [How people and agents share the work](https://corpole.com/support/getting-started/people-and-agents-share-the-work): Agents draft, propose, build and report. People decide what binds, what is ready and what is done. ### Connect your agent Claude Code, Cursor and other MCP clients; identity and permissions. - [Agent activity](https://corpole.com/support/connect-your-agent/agent-activity): Every call a coding agent made to CorPole in this solution: what came in, what CorPole did inside, what it gave back and how long it took. - [Agents](https://corpole.com/support/connect-your-agent/ai-context-screen): How coding agents work on this solution: how they connect, what they receive, and how they are doing. What they may do (policy, authority tier, language, repositories) is set under ⚙ › Solution settings. - [Connect Claude Code](https://corpole.com/support/connect-your-agent/connect-claude-code): Add the MCP server and sign in, or install the plugin for commands, session context and notices. - [Connect Cursor, VS Code and other MCP clients](https://corpole.com/support/connect-your-agent/connect-cursor-and-other-clients): Add a remote MCP server; clients with OAuth need only the URL, others send a personal token. - [Connect claude.ai, Claude Desktop or ChatGPT](https://corpole.com/support/connect-your-agent/connect-claude-ai-and-desktop): Add CorPole as a custom connector and sign in; no token needed. - [Personal tokens, service tokens and sign-in](https://corpole.com/support/connect-your-agent/tokens-and-identity): Every agent connection acts for one person and never has more permissions than that person. - [Set up your repository with /corpole:init](https://corpole.com/support/connect-your-agent/set-up-your-repository): The repository kit tells Claude Code that CorPole comes first, and adds the team settings and — for GitHub or GitLab — the change-request template and CI check. - [How the change-request check works](https://corpole.com/support/connect-your-agent/github-check): A pull request (GitHub) or merge request (GitLab) has to cite existing, non-retired records, so a retired decision cannot come back through a merge. - [No MCP? Use the REST endpoint or a CLAUDE.md snippet](https://corpole.com/support/connect-your-agent/rest-and-claude-md-fallback): Tools without MCP can still read what binds: fetch it over REST, or paste the snippet into the repository. - [Read-only or propose: what a connection may do](https://corpole.com/support/connect-your-agent/read-only-or-propose): Read is always on. Propose lets the agent add Drafts, changes, work items, tests and results — never anything binding. ### Records & authority Record types, the four states, writing and approving. - [Objectives](https://corpole.com/support/records-and-authority/objective): A measurable outcome the solution exists to achieve. Objectives explain why everything else matters. - [Business Requirements](https://corpole.com/support/records-and-authority/business-requirement): What the organisation needs from the solution, stated without describing how it is built. - [Stakeholder Requirements](https://corpole.com/support/records-and-authority/stakeholder-requirement): A need of a specific group of people, usually written as a user story. - [Functional Requirements](https://corpole.com/support/records-and-authority/solution-functional-requirement): A 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. - [Non-functional Requirements](https://corpole.com/support/records-and-authority/solution-non-functional-requirement): A quality the system must meet: performance, security, accessibility, reliability. - [Technical Requirements](https://corpole.com/support/records-and-authority/technical-requirement): A 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. - [Project Requirements](https://corpole.com/support/records-and-authority/project-requirement): Something the solution must deliver besides the product itself: deadlines, documents, test suites. - [Product Constraints](https://corpole.com/support/records-and-authority/product-constraint): A limit on what the product may be or do. - [Business Constraints](https://corpole.com/support/records-and-authority/business-constraint): A commercial, legal or organisational limit. - [Project Constraints](https://corpole.com/support/records-and-authority/project-constraint): A limit on how the solution is run: team, budget, tooling, time. - [Explorer](https://corpole.com/support/records-and-authority/explorer): A 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. - [New record](https://corpole.com/support/records-and-authority/create-a-record): Creates one objective, requirement or constraint in the active solution. - [Record detail](https://corpole.com/support/records-and-authority/record-page): Everything about one record: statement, rationale, acceptance criteria, state, priority, owner and source. - [Edit record](https://corpole.com/support/records-and-authority/edit-a-record): Changes a record's content or state. The change is visible to AI agents immediately. - [Solution design](https://corpole.com/support/records-and-authority/solution-design): The 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. - [Portfolio board](https://corpole.com/support/records-and-authority/portfolio-board): The 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. - [Initiatives](https://corpole.com/support/records-and-authority/initiatives): An 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. - [Demands](https://corpole.com/support/records-and-authority/demands): Every 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. - [Assess a request](https://corpole.com/support/records-and-authority/assess-a-request): Paste 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. - [Changes](https://corpole.com/support/records-and-authority/change-history): The 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. - [Write a requirement an agent can follow](https://corpole.com/support/records-and-authority/write-a-requirement-an-agent-can-follow): One testable statement, the reason in plain words, and criteria that a test can check. - [Review an AI proposal](https://corpole.com/support/records-and-authority/review-an-ai-proposal): Agent proposals are Drafts with an AI proposal badge. Nothing binds until a person makes it Authority; Approve marks it reviewed. - [Accept or reject a change proposal](https://corpole.com/support/records-and-authority/accept-or-reject-a-change-proposal): Agents cannot edit records. A change arrives as a difference you accept or reject on the record page. - [Retire or replace a record](https://corpole.com/support/records-and-authority/retire-or-replace-a-record): Retiring takes a record out of every agent's context at once. Replace it when something new takes its place. ### Relations & conflicts Typed links between records, conflicts and replacements. - [Relations: when to use which](https://corpole.com/support/relations-and-conflicts/relations-when-to-use-which): Typed links tell an agent why a requirement exists, how it is achieved and what limits it. - [Why a record cannot become Authority](https://corpole.com/support/relations-and-conflicts/why-a-record-cannot-become-authority): Two rules block it: a requirement without acceptance criteria, and an open conflict. - [Two binding records disagree](https://corpole.com/support/relations-and-conflicts/two-records-disagree): The agent stops and shows both codes. It does not pick a winner; a person does. ### Work & boards Themes to subtasks, Kanban boards and who may move a card. - [Forecast](https://corpole.com/support/work-and-boards/forecast): When the remaining work is likely done, from the solution's own pace, how likely a target date is, what slows it down, what happens if one item goes first, and how finished work compared with its due dates. - [Flow](https://corpole.com/support/work-and-boards/flow-metrics): How changes flow through the portfolio: how long they take from the request to done, how much of that time they wait, where they wait, and what is finished each week. Counted from the steps demands and initiatives go through. - [Planning check](https://corpole.com/support/work-and-boards/planning-check): Before a planning session: which candidate items would pass the Ready gate and what each still lacks, and how much work each person and agent already carries. - [Work](https://corpole.com/support/work-and-boards/work-items): Work items are the execution side of an initiative: they bring its requirements to life and carry the changes to the solution's design. Requirements stay the authority; work links to them and never replaces them. - [Boards](https://corpole.com/support/work-and-boards/kanban-boards): Kanban boards for the work of the solution's initiatives — stories, tasks, defects and epics — and a review board for requirements. Every move is checked against the same rules as the forms. Initiatives themselves move on the Portfolio board. - [Themes, epics, stories, tasks and work packages](https://corpole.com/support/work-and-boards/value-tree-and-work-packages): Every item belongs to an initiative. Within it, a value tree says what you build and work packages say when and by whom. - [Story or task?](https://corpole.com/support/work-and-boards/story-or-task): A story involves development. A task does not. - [Who may move a card](https://corpole.com/support/work-and-boards/who-may-move-a-card): Agents move work into progress and review. Ready, verification and Done belong to people. - [Break a requirement into stories with your agent](https://corpole.com/support/work-and-boards/break-a-requirement-into-stories): The agent proposes epics, stories and tasks with their links; you pick what to release. - [Implement a story with your agent, end to end](https://corpole.com/support/work-and-boards/implement-a-story-end-to-end): From a Ready story to Code review, with context, tests and evidence. ### Knowledge Decisions, questions, glossary, standards, lessons and ideas. - [Knowledge](https://corpole.com/support/knowledge/knowledge-screen): Knowledge guides how the work is done: the decisions already taken, the questions still open, the shared language, the standards and the contracts or designs. Coding agents receive it with every piece of work. - [Decisions: propose, accept, supersede](https://corpole.com/support/knowledge/decisions): Accepted decisions bind the records and work they govern. Proposed ones do not. - [Questions: how agents ask instead of guessing](https://corpole.com/support/knowledge/questions): When something is missing or ambiguous, the agent records a question with its working assumption. - [Standards, and waiving one with a decision](https://corpole.com/support/knowledge/standards-and-waivers): Standards say how work is done. A solution records an exception with an accepted decision that waives it. - [Lessons and improvement ideas](https://corpole.com/support/knowledge/lessons-and-ideas): What agents learn becomes shared, and ideas can become work. ### Agent policy & rules What an agent may do alone, the rules it follows, notices. - [Governance preview](https://corpole.com/support/agent-policy-and-rules/governance-preview): Before a work gate, an agent permission in CorPole or a code rule changes, see what it would do — which solutions it reaches, what the last 30 days would have looked like, what it would stop or free today. Nothing is changed. - [Solution settings](https://corpole.com/support/agent-policy-and-rules/project-settings-screen): How this solution is built and how agents work in it: its components and repositories, record language and kickoff, authority handover and agent policy. Open it from ⚙ › Solution in the top bar. People who manage the solution's integrations can change it. - [Agent rules](https://corpole.com/support/agent-policy-and-rules/agent-rules): The behavioural rules every AI agent connected to CorPole follows, and how each level adds to them. - [Waiting for you](https://corpole.com/support/agent-policy-and-rules/decisions): Every card that waits for you in the solution — agent drafts, change proposals, proposed decisions, open questions, proposed solution rules — gone through in one pass, with your agent's preparation. - [Notices](https://corpole.com/support/agent-policy-and-rules/notices): Messages from CorPole to you: drafts waiting for your approval, a solution your agent created, changes proposed to records you own, drift signals and emergencies. - [My sessions](https://corpole.com/support/agent-policy-and-rules/my-sessions): Your coding-agent sessions: when each started, when the agent worked, waited for you or sat idle, and what it touched in CorPole. Only you see it in full. - [The agent policy: allowed, ask first, forbidden](https://corpole.com/support/agent-policy-and-rules/agent-policy): Per action, decide what an agent may do alone. CorPole enforces it before the action. - [Write your own agent rule](https://corpole.com/support/agent-policy-and-rules/write-your-own-rule): Rules shape how an agent behaves. Yours apply to the agent that acts for you, on top of the solution's. - [What your agent reads at the start of a session](https://corpole.com/support/agent-policy-and-rules/what-the-agent-reads-first): Before it writes code, the agent reads its policy and rules, the standards and what changed. - [What an agent can never do in CorPole](https://corpole.com/support/agent-policy-and-rules/what-an-agent-can-never-do): Some decisions always belong to a person, whatever the policy or the prompt. ### Traceability & quality Acceptance criteria, tests, CI results, defects and risks. - [Compliance matrix](https://corpole.com/support/traceability-and-quality/compliance-matrix): From every active standard and every binding Authority constraint, quality and technical requirement down to the records that carry it, their acceptance criteria, the tests that prove them, the latest result and any exemption. It answers "do we comply with KVKK, BDDK or our security standards" with evidence. - [Baselines](https://corpole.com/support/traceability-and-quality/baselines): Name a moment — an accepted offer, a phase delivered, a quarter closed — and freeze the solution as it is: records and their text, acceptance criteria and their status, work, tests and their results, decisions and key numbers. Later compare it with today or with another baseline. - [Audit trail](https://corpole.com/support/traceability-and-quality/audit-trail): Every change and every agent call in the solution for a closed period, in one timeline, with a summary and a note on what the answer rests on. It answers audit questions: what changed and who approved it, what a token did, whether something ever happened. - [Intent Map](https://corpole.com/support/traceability-and-quality/intent-map): Why each piece of work exists: objectives on the left, then the requirements that refine them, the stories and tasks that build them, and the tests that check them. - [Impact Map](https://corpole.com/support/traceability-and-quality/impact-map): What a change to one item reaches. The item sits in the middle; what it reaches directly is on the inner ring, what it reaches through something else on the outer rings. - [Test cases and traceability](https://corpole.com/support/traceability-and-quality/test-cases-and-traceability): Test cases prove acceptance criteria. Their results, reported by CI, coding agents or people, decide whether the criteria are met; Traceability follows every requirement to its criteria, tests, work and code. - [Defects](https://corpole.com/support/traceability-and-quality/defects): A defect is behaviour that does not match a requirement or acceptance criterion. It is a work item of its own, triaged by severity, fixed like a story and proven by a test. - [Risk register](https://corpole.com/support/traceability-and-quality/risk-register): Risks are things that may go wrong and would hurt an objective, a requirement or delivery. Each is scored by probability × impact and has a response; accepting a risk needs a recorded decision. - [Acceptance criteria: Met, Not met, verified](https://corpole.com/support/traceability-and-quality/acceptance-criteria): Criteria are separate items with their own codes and status. Proof comes from a test or a person. - [Link tests to criteria and let CI report](https://corpole.com/support/traceability-and-quality/link-tests-and-ci): Register each test against the criteria it proves; results then update the criteria. - [The change-request check and the no-requirement label](https://corpole.com/support/traceability-and-quality/the-github-check): Every pull or merge request cites existing, non-retired record codes; trivial changes carry a label instead. ### Existing codebases Onboarding code you already have, and handing authority over. - [Onboarding an existing codebase](https://corpole.com/support/existing-codebases/onboard-an-existing-codebase): For solutions that started without CorPole: the coding agent reverse-engineers the code, tests and documents into design drafts; people confirm what the solution is; governance grows module by module. The work runs as the solution's "Onboard …" initiative. - [Authority handover: Shadow, Shared, Full](https://corpole.com/support/existing-codebases/authority-handover-tiers): For solutions with existing sources, CorPole takes over authority step by step. - [Move CLAUDE.md, ADRs and docs into CorPole](https://corpole.com/support/existing-codebases/move-claude-md-into-corpole): /corpole:handover inventories what governs the solution and proposes it as records. ### When things go wrong Situations and what to do: drift, conflicts, emergencies. - [My agent forgot what we decided yesterday](https://corpole.com/support/when-things-go-wrong/agent-forgot-what-we-decided): A decision made in one chat session is gone in the next. Decisions belong in records, not in chat history. - [My agent followed a decision we had dropped](https://corpole.com/support/when-things-go-wrong/agent-followed-a-dropped-decision): An old document in the repository still describes the approach you abandoned, and the agent read it as current. - [My agent changed a requirement to fit its code](https://corpole.com/support/when-things-go-wrong/agent-changed-a-requirement-to-fit-its-code): The code did not meet the requirement, so the agent tried to change the requirement instead. In CorPole it can only propose. - [The requirement changed while the agent was working](https://corpole.com/support/when-things-go-wrong/requirement-changed-while-the-agent-was-working): Someone updated a requirement mid-story, and the agent kept building against the old version. - [The agent says "done" but a criterion is not met](https://corpole.com/support/when-things-go-wrong/agent-says-done-but-criterion-not-met): The agent reported the work finished, but a criterion has no proof, or its test is failing. - [The same test keeps failing](https://corpole.com/support/when-things-go-wrong/same-test-keeps-failing): The agent is going round in circles, trying variations of the same fix. - [The agent wants to run a migration or add a dependency](https://corpole.com/support/when-things-go-wrong/agent-wants-to-run-a-migration): Some actions should never happen without a person. The agent policy decides which. - [Production is down: declaring an emergency](https://corpole.com/support/when-things-go-wrong/production-is-down): The fix cannot wait for a requirement. A time-boxed emergency lets the agent fix it now, on the record. - [Agent health shows a warning](https://corpole.com/support/when-things-go-wrong/agent-health-shows-a-warning): A drift signal means an agent is going off course. Resolve it with a root cause, and it can become a lesson. - [An agent is flooding the review queue](https://corpole.com/support/when-things-go-wrong/agent-is-flooding-the-review-queue): Too many proposals, or too many that get rejected. CorPole limits the volume and flags the pattern. - [A secret ended up in something the agent wrote](https://corpole.com/support/when-things-go-wrong/a-secret-ended-up-in-agent-output): CorPole masks what it recognises as a secret before storing it. Rotate the secret anyway. - [A file or web page tells the agent to do something](https://corpole.com/support/when-things-go-wrong/a-file-tells-the-agent-what-to-do): Text the agent reads is data, not an instruction. CorPole makes that a rule agents cannot drop. - [Two agents picked the same story](https://corpole.com/support/when-things-go-wrong/two-agents-picked-the-same-story): CorPole shows who is on a story and warns a second agent. It does not block; people decide. - [I just need to fix a typo](https://corpole.com/support/when-things-go-wrong/i-just-need-to-fix-a-typo): A trivial change needs no requirement and no interview. Label the pull request and move on. - [We keep making the same mistake](https://corpole.com/support/when-things-go-wrong/we-keep-making-the-same-mistake): What an agent learns the hard way stays in its memory unless it is written down. Lessons make it shared. - [The client asks why we built it this way](https://corpole.com/support/when-things-go-wrong/client-asks-why-we-built-it-this-way): Decisions are records with their reasons, and every change keeps who made it and why. - [A new developer joins mid-project](https://corpole.com/support/when-things-go-wrong/new-developer-joins-mid-project): They connect their own agent under their own name and read the same records as everyone else. - [I inherited a half-built vibe-coded app](https://corpole.com/support/when-things-go-wrong/inherited-a-half-built-app): Onboarding reads the code and drafts the solution's design from it, for people to confirm before anything binds. - [Our CLAUDE.md is 800 lines and contradicts itself](https://corpole.com/support/when-things-go-wrong/claude-md-is-huge-and-contradicts-itself): Move the rules into CorPole as proposals, resolve the contradictions, and hand authority over step by step. - [My agent insists on something Authority forbids](https://corpole.com/support/when-things-go-wrong/agent-insists-on-something-authority-forbids): Even when you ask, the agent will not act against an Authority record. It proposes the change and shows who can make it. ### Team & accounts Members, roles, tenants and solution settings. - [Access review](https://corpole.com/support/team-and-accounts/access-review): Who can reach what in the tenant: members with their roles and solution access, and every agent credential with its scopes, last use and end date. Unused, never-used, open-ended and orphaned credentials are flagged; for one person it shows what breaks when they leave. The review itself is recorded. - [Time report](https://corpole.com/support/team-and-accounts/time-report): Your coding-agent time by day and solution, for an invoice or a weekly report, and the solution's day totals without names. - [Maturity settings](https://corpole.com/support/team-and-accounts/maturity-settings): How strictly the solutions under this platform, account or tenant are measured on the Maturity screen: thresholds, dimensions, conditions, method, target profiles and where maturity shows. - [Members](https://corpole.com/support/team-and-accounts/members-and-roles): The people in this tenant, their access level, the team of the active solution with its roles, and an access review. - [Account](https://corpole.com/support/team-and-accounts/account-and-tenants): The account is the organisation above the tenants, e.g. a bank with its business units or subsidiaries as tenants. What is set at account level applies to every tenant. - [Governance across the account](https://corpole.com/support/team-and-accounts/governance-across-the-account): For account owners and admins: one view of how the tenants and solutions of the account keep to its line. - [Option lists](https://corpole.com/support/team-and-accounts/option-lists): The categories offered in forms and to agents — for risks, standards, lessons, ideas, agent rules and tasks — changed for the account or a tenant without changing the code. - [My ideas](https://corpole.com/support/team-and-accounts/my-ideas): A private place for ideas you are not sure about yet. Only you see them; nothing is counted, shared or turned into a demand unless you decide. - [Roadmap indicators](https://corpole.com/support/team-and-accounts/roadmap-indicators): For platform admins: whether each roadmap wave's leading indicator holds and whether a stop threshold is crossed, read in one tenant — the gate for the next wave. - [Agent benchmark](https://corpole.com/support/team-and-accounts/agent-benchmark): For platform admins: how CorPole changes coding agents' cost and correctness, compared with requirements kept as markdown in the repository — suite by suite. - [Security](https://corpole.com/support/team-and-accounts/security-suite): For platform admins: how robust CorPole's security is — each security suite's latest run, what is new or fixed, and the trend. - [AI usage](https://corpole.com/support/team-and-accounts/ai-usage): For platform admins: the calls CorPole's own AI features made to the model, per tenant and per feature, with their tokens. - [Features](https://corpole.com/support/team-and-accounts/feature-flags): For platform admins: the flags that bring big changes to people step by step — first chosen people and sandboxes, then everyone. - [Theme](https://corpole.com/support/team-and-accounts/platform-theme): For platform admins: the one theme every tenant sees, set at runtime without a deploy. - [Tenant settings](https://corpole.com/support/team-and-accounts/project-settings): Tenant-wide rules for all solutions. Owners and admins can change them. Open it from ⚙ in the top bar. - [You](https://corpole.com/support/team-and-accounts/your-page): Your own page: profile, the tenants you belong to, your agents, and how CorPole reaches you. Open it from your initials at the right of the top bar. - [Accounts, tenants and solutions](https://corpole.com/support/team-and-accounts/accounts-tenants-projects): Account → Tenant → Solution → Component. What is set higher up applies below; initiatives carry the work. - [Access levels and solution roles](https://corpole.com/support/team-and-accounts/access-levels-and-project-roles): A tenant access level says how far someone reaches; solution roles say what they may do in a solution. - [Maker-checker: a second person approves](https://corpole.com/support/team-and-accounts/maker-checker): The person who asks cannot approve, and the person who did it cannot check it. Agents never approve or check. ### Security & data Where data lives, agent identity, masking and logs. - [Where your data lives, and what leaves your repository](https://corpole.com/support/security-and-data/where-your-data-lives): Records live in CorPole in the EU. Your code stays with you. - [Revoke an agent's access](https://corpole.com/support/security-and-data/revoke-agent-access): Revoke a token or disconnect a sign-in; the next call is refused. - [What is logged](https://corpole.com/support/security-and-data/what-is-logged): Every agent read and write, and every change to records and work, with who, when and why. ### Troubleshooting Error messages and connection problems, with the fix. - [401 invalid_token](https://corpole.com/support/troubleshooting/401-invalid-token): CorPole refused the agent's credentials. The token is revoked or expired, the solution is not active, or its owner can no longer read the solution. - [Claude Code shows corpole as failed](https://corpole.com/support/troubleshooting/claude-code-shows-corpole-as-failed): The MCP server is listed but not connected. Usually Claude Code has neither a token nor an OAuth sign-in for it. - [The agent's proposal was refused](https://corpole.com/support/troubleshooting/propose-refused): propose_record and the other write tools need the propose permission. A read-only connection can read everything its owner can, but cannot propose. - [My agent ignores the requirements](https://corpole.com/support/troubleshooting/agent-ignores-requirements): The agent writes code without reading CorPole, or follows a file in the repository instead. Most often the repository does not tell it that CorPole comes first. - [My agent sees the wrong solution, or none](https://corpole.com/support/troubleshooting/agent-sees-the-wrong-project): Every connection belongs to exactly one solution. The agent sees the solution its token was created in, or the one chosen on the OAuth consent screen. - ["You don't have permission"](https://corpole.com/support/troubleshooting/you-dont-have-permission): CorPole refused an action because you, or the person your agent acts for, lack the permission. The message names the permission, who holds it and where it is done. - [The change-request check fails (GitHub, GitLab)](https://corpole.com/support/troubleshooting/github-check-fails): The CorPole check wants every pull request (GitHub) or merge request (GitLab) to cite at least one existing, non-retired record code. - [Test results don't show up on the criteria](https://corpole.com/support/troubleshooting/test-results-missing-on-criteria): A criterion follows the test cases linked to it. If results do not arrive, the test is not linked, or its automation reference does not match what CI reports. ### Reference Tools, commands, states, relations and terms in one place. - [Architecture](https://corpole.com/support/reference/architecture-model): The solution's architecture model in ArchiMate-compatible language: what it is made of, from capabilities down to repositories and running software, and how the parts relate. - [Visual language](https://corpole.com/support/reference/visual-language): The reference for colours, light levels and icons used across CorPole. - [MCP tools](https://corpole.com/support/reference/mcp-tools): Every tool the CorPole MCP server offers, the permission it needs and what it does. The server is at https://corpole.com/api/mcp. - [Claude Code plugin commands](https://corpole.com/support/reference/plugin-commands): The slash commands the CorPole plugin adds to Claude Code. - [States and statuses](https://corpole.com/support/reference/states-and-statuses): The four record states and the columns each work type moves through. - [Relation types](https://corpole.com/support/reference/relation-types): The typed links between records, what each means and what agents do with it. - [Glossary](https://corpole.com/support/reference/glossary): The words CorPole uses, in one place. - [OAuth details](https://corpole.com/support/reference/oauth-details): Endpoints, flow, tokens and scopes for MCP clients that sign in to https://corpole.com/api/mcp on their own. ## Optional - [Full text of Learn and the help center](https://corpole.com/llms-full.txt): every article above as Markdown in one file. - [Privacy policy](https://corpole.com/privacy) - [Terms of service](https://corpole.com/terms)