# CorPole: Learn and help center > The full text of corpole.com/learn and corpole.com/support. CorPole is a requirements authority for teams that build with AI coding agents: every record carries a state, and agents receive only what binds today. ## Learn ### Why building software is hard Source: 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. #### The gap between intent and result Every piece of software starts as an intention in someone's head: patients should be able to book online; the bank must not lose a transfer; the report must be ready by Monday. Between that intention and the running code sit many translations — from a founder to a product owner, from a product owner to a developer, from a developer to the machine. Each translation loses a little. Code is precise, but it is only precise about what it was told. When the intention was vague, the code is precisely wrong. That is why experienced teams spend so much effort before and around the code: writing down what must be true, why, for whom, within which limits, and how anyone would know it works. #### Where it usually goes wrong | Loss | What it looks like | | --- | --- | | **The goal was never agreed** | The team builds features; nobody can say which outcome they serve, so nobody can say which ones matter. | | **The need was misunderstood** | The feature works as written and still does not solve the user's problem. | | **Limits were invisible** | A legal rule, a budget or a deadline surfaces late and forces a rewrite. | | **Requirements changed silently** | Someone changed their mind in a meeting; half the team kept building the old version. | | **"Done" was a feeling** | Nobody defined how to check it, so it shipped untested and came back as a defect. | | **Reasons were lost** | Six months later, nobody remembers why it was built this way, so nobody dares to change it. | #### What good teams do about it They separate **why** (objectives), **what** (requirements) and **within which limits** (constraints) from **how** (design, code and work). They write each requirement so it can be checked, keep decisions with their reasons, and treat a change to a requirement as a decision in its own right, not as an edit. They also keep two things apart that are easy to mix up: **what should change** and **what the system is today**. A request becomes a planned change with its own requirements; the description of the running system is updated only when that change is actually delivered. None of this is bureaucracy for its own sake. Each of these practices exists because one of the losses above once cost a team weeks, a customer or a launch. #### Where CorPole fits CorPole keeps that structure in one place. Every change starts as a **demand** — who asked, how, when and what — and is carried out by an **initiative** that holds its objectives, requirements, constraints and work. The **solution** (the product being governed) keeps its **design records**: what it does and how it is built today. Each record has a state that says whether it binds. The next article explains why this matters even more now that AI agents write much of the code. ### What AI coding agents change Source: 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. #### Fast, literal and forgetful A coding agent writes in minutes what took a developer a day. It follows instructions literally and it does not get tired. But it also has no memory between sessions beyond what it is given, no judgement about which document is current, and no instinct to stop and ask when something smells wrong. A human developer who reads an outdated spec usually remembers the meeting where it changed. An agent reads the outdated spec as the truth, every time, and builds against it quickly and confidently. #### Old problems, amplified | Old problem | With an agent | | --- | --- | | Vague requirements | The agent fills the gap with plausible guesses, at speed, in code that looks finished. | | Stale documents | The agent follows a decision you abandoned last month, because nothing marks it as abandoned. | | Changing requirements | The agent keeps building against what it read an hour ago. | | "Done" without proof | The agent reports success; it may even adjust a test or a requirement to make it true. | | Lost reasons | Nobody wrote down why; the agent cannot ask the person who knew. | #### What an agent needs An agent works well when it is handed exactly what binds for the task in front of it — the goal behind it, the requirement, the limits around it, the decisions already taken and the criteria it will be checked against — and nothing that has stopped applying. It also needs clear boundaries: what it may do alone, what it must ask about, and what it may never do. In other words, the discipline good teams always practised is now also the interface to your agent. Records are no longer just documentation; they are the agent's instructions. #### How CorPole answers it - Every record has a state; only **Authority** reaches the agent, and retiring a record removes it at once. - The agent works for one solution and one initiative at a time; new work lands in that initiative, and no work is committed unless its initiative answers a demand. - The agent receives a work context per task: why-chain, criteria, constraints, decisions, and the solution's current design it must respect. - Agents propose; people decide what binds, what is ready and what is done. - An agent policy and agent rules set boundaries the agent cannot remove. - Tests and criteria prove "done"; a story's design changes reach the solution's design only when it is Done; the history keeps every reason. ### The requirements chain Source: 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. #### Reading the chain Requirements are not a flat list. They form a chain that runs from **why** to **how**. An **objective** says what the solution must achieve. **Business requirements** say what the organisation needs to reach it. **Stakeholder requirements** say what each group of people needs. **Functional** and **non-functional requirements** say what the system must do and how well. **Technical requirements** say how it is achieved. Each link refines the one above it. When a functional requirement can be traced up to an objective, everyone — and every agent — can see why it exists, and what would be lost if it changed. #### Two things beside the chain **Constraints** do not describe what to build; they limit how it may be built. A product constraint limits the product itself, a business constraint comes from the organisation or the law, a project constraint limits time, budget, team or tools. A constraint can apply to specific requirements or to the whole solution. **Project requirements** describe what the solution must deliver besides the product: training, documentation, a test suite, a go-live date as a deliverable. They are not about the software's behaviour, which is why they sit beside the chain rather than in it. #### Below the chain: proof and work Every requirement carries **acceptance criteria**: the conditions that prove it is met. **Tests** check the criteria. **Work items** — epics, stories, tasks — bring the requirements to life and cover their criteria. None of these replaces a requirement; they point back to it. #### Where the chain lives: the change and the solution A requirement says what should **change**. It belongs to the **initiative** that carries out that change, which in turn answers a **demand**. When the initiative closes, its requirements become history: they stay, with their reasons, as the record of why it was built that way, but they no longer bind agents. What the system does is described by the solution's **design records**. What the system **is** today is described by the solution's **design records**: business rules, functional behaviour, qualities, the technical design of each component, and architecture decisions. Stories and epics carry the **design changes** that update them, and a change is applied only when the work is Done. So the agent always reads two things: the solution's current design, which it must respect, and the initiative's requirements, which say what to change. #### Why the chain matters to an agent - It tells the agent **why**, so it can make sensible choices where the requirement is silent. - It tells the agent **what else is affected**, so a change in one place does not quietly break another. - It tells the agent **which limits apply**, so it does not build something that cannot ship. - It lets people see, before code is written, where the chain is missing a link. #### In CorPole CorPole models the chain with typed relations: a requirement **refines** the one above it, a technical requirement **realizes** a functional or non-functional one, a constraint **constrains** requirements, and a new record **replaces** an old one. An agent reads the chain upwards before it implements anything. Requirements belong to an initiative; what has been delivered lives in the solution's design records. The pages on each record type below explain every link in detail. ### Clinic Booking, from idea to proof Source: 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. #### The idea A group of three clinics loses time on the phone. Patients call to book, to move and to cancel; receptionists spend mornings on it; one appointment in eight is a no-show. The owner, Aylin, wants patients to do this online and asks a coding agent to help build it. A vibe-coding session could start with "build me a booking site" and have something on screen in an hour. What follows is what it takes for that something to be the right thing, and to stay right as the solution changes. #### 0. The request: a demand and an initiative Aylin's request is recorded as a **demand**: who asked, how, when and what. It lands in the Funnel of the Portfolio board. She reviews it and answers it with an **initiative**, "Online booking — first release", managed as a project. Everything below — objectives, requirements, work — belongs to that initiative. **Clinic Booking** itself is the **solution**: the system that will outlive this first release. It starts with one component, the web app, whose code lives in one repository on GitHub (GitLab works the same way). What the solution does will be kept in its **design records**; for now there are none, because nothing is built yet. #### 1. Why: objectives The first question is not what to build but what must be true when it works. Aylin and the agent agree two measurable objectives: | Code | Objective | | --- | --- | | OBJ | Patients can book, move or cancel online in under a minute. | | OBJ | Halve no-shows within six months. | Everything below will trace back to one of these. When someone later asks for a loyalty programme, the first question is which objective it serves. #### 2. What: requirements, from need to behaviour | Level | Record | Refines | | --- | --- | --- | | Business | BR — Patients can book outside opening hours. | the first objective | | Stakeholder | SR — As a patient, I can move my own appointment. | the BR | | Stakeholder | SR — As a receptionist, I see every change made overnight when my shift starts. | the BR | | Functional | FR — A patient can move an appointment up to 2 hours before it starts. | the patient SR | | Functional | FR — Send a reminder 24 hours before each appointment. | the no-show objective, via its BR | | Non-functional | NFR — The booking page loads in under one second on a mid-range phone. | the patient SR | | Technical | TR — Use the clinics' existing calendar; keep no second schedule. | realizes the FRs | Each requirement gets acceptance criteria before it is approved. The "move up to 2 hours" requirement gets three: the allowed move, the refused late move, and a slot that is already taken. #### 3. Limits: constraints | Type | Constraint | Applies to | | --- | --- | --- | | Product | Web only in the first release, no native apps. | the whole solution | | Business | Patient data stays in the EU. | the whole solution | | Project | Live within three months, before the spring rush. | the whole solution | Because these apply to the whole solution, the agent receives them with every piece of work. When it later reaches for a US-hosted SMS service for reminders, the business constraint stops it. #### 4. What else the initiative delivers The software is not the whole job. A project requirement of the initiative says every receptionist is trained on the new schedule view before go-live. A work package, "Release 1 — spring launch", with an owner, dates and a budget, delivers it together with the software. #### 5. Work: from theme to story | Level | Item | | --- | --- | | Theme | Self-service for patients | | Epic | Online rescheduling (implements the patient SR) | | Story | Move an appointment from the confirmation e-mail link (implements the FR, covers its three criteria) | | Story | Show free slots for the next two weeks | | Task | Grant the booking service access to the clinics' calendar (needs IT approval) | A story is ready only when it implements an approved requirement and covers at least one criterion, and it can be committed because its initiative answers Aylin's demand. That is what lets the agent work on it without a meeting. Each story also says what it will change in the solution's design. The e-mail-link story carries a **design change**: add a functional design record, "Move an appointment", with the 2-hour rule. #### 6. Building: what the agent receives When the agent picks up the e-mail-link story, it does not get a pile of documents. It gets a work context for that one story: - the requirement it implements, and the chain above it up to the objective; - the three acceptance criteria it must prove; - the constraints that apply (web only, EU data, three months); - the technical requirement and the decision behind it (use the calendar API directly, not a nightly sync); - the solution's current design it must respect, and the design change this story makes to it; - and, read alongside, the account's standards, such as logging every read of patient data. While building, the agent notices the calendar API may throttle requests on busy Monday mornings. It raises a **risk** instead of mentioning it in passing. It is unsure whether parents may move their children's appointments, so it opens a **question** with a working assumption: only your own, for now. #### 7. Proof: criteria and tests The agent writes an end-to-end test for each criterion and links it. CI runs them; the results, not the agent's summary, turn the criteria Met. The story moves through code review and verification, and a person moves it to Done. Only then is its design change applied: the solution now has a design record "Move an appointment", version 1, which records the story, requirement and initiative that brought it. After launch a tester finds that a move 1 hour 59 minutes before the appointment is accepted. Because the criterion says it must be refused, this is a **defect**, not a debate. Reported on its own, it goes to the solution's quarterly maintenance initiative. It is fixed and closed with a test that proves the fix. When all its work is Done, the first-release initiative closes, and Aylin's demand with it. Its requirements become history — kept with their reasons, no longer binding — and the design records now describe what was built. #### 8. Change: the rule moves from 2 hours to 4 Receptionists say two hours is too short to refill a slot. In a folder of documents this is where solutions go wrong: the old rule survives in a spec, a ticket and a prompt, and the agent keeps following it. Here the request is a new **demand**. Aylin answers it with a small-work initiative, "Four-hour notice". Its functional requirement says moves must be made at least 4 hours before, with its own criteria. The story that implements it carries a design change to "Move an appointment": 2 hours becomes 4. While the work runs, the agent sees both: today's design (2 hours), which is still what the system does, and the change it must make (4 hours). The tests are updated to prove the new criteria. When the story is Done, the change is applied and the design record gets version 2. From then on every agent reads 4 hours as the truth; the 2-hour rule is history, kept with its reasons. The team also records a **lesson** from the defect: calendar times are local clinic time, not UTC, so convert at the boundary. The next agent session starts with it. #### What this story shows - A **demand** and an **initiative** gave every change a requester, a scope and an end. - **Objectives** kept the scope honest. - The **chain** of requirements told the agent why, not just what. - **Constraints** stopped good-looking shortcuts. - **Criteria and tests** made "done" provable, and a defect undeniable. - **Risks, questions and lessons** kept what the agent noticed where people decide. - **Design records** described what the system does today, and changed only when the work that changed them was Done. - An explicit **change** meant the agent stopped following the old rule the moment the new one was delivered. ### Objective Source: https://corpole.com/learn/objective A measurable outcome the solution exists to achieve. Every other record should trace back to one. #### What it is An objective says what must be true when the solution has succeeded, in a way someone can measure. It is not a feature and not a task; it is the reason features and tasks exist. #### Why it matters Objectives are how a team decides what matters. When two requirements compete for time, the one that serves an objective better wins. Without objectives, every request looks equally important, and the solution grows in every direction at once. They also tell you when to stop. An initiative whose objectives are met is done, even if the backlog is not empty. #### What goes wrong without it - Features pile up that no one can connect to a goal. - Priorities are decided by whoever asks loudest or last. - Success is argued about after launch, because it was never defined before it. - Scope creeps, because nothing says a request is out of scope. #### What it gives an AI agent An agent that knows the objective behind a requirement makes better choices where the requirement is silent. Asked to build a booking form, an agent that knows the goal is "book in under a minute" will keep it short; one that does not may add every field it can think of. Objectives also let people see, before code is written, which proposed work serves no goal at all. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Improve the booking experience. | Patients can book, move or cancel an appointment online in under a minute (measured on 95% of sessions). | The strong version names who, what and how you will know. #### How it relates to the rest - **Business requirements** refine an objective: what the organisation needs to reach it. - **Themes and epics** serve an objective: the work that contributes to it. - Objectives are rarely changed; when they are, everything below them deserves a second look. #### In CorPole - Type **Objective** (OBJ), in the Intent group. It belongs to an initiative, and usually states what the demand behind it asked for. - Business requirements are linked to it with **refines**; themes and epics **serve** it. - CorPole flags an objective that no business requirement refines, and requirements that trace to no objective. - Acceptance criteria are optional for objectives, but a measurable statement is the point. ### Business requirement Source: 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. #### What it is A business requirement describes a capability the business needs: take bookings outside opening hours, keep one record per customer, report revenue by clinic. It says nothing about screens, databases or code. #### Why it matters Business requirements keep the solution honest. They let a team propose different solutions to the same need and choose the best one, instead of arguing about features whose purpose nobody wrote down. They are also the level most stakeholders can read and sign off, which makes them the natural place to agree scope. #### What goes wrong without it - The team jumps straight to features and builds one solution without considering others. - Features are built that the business did not need; the ones it did need are missed. - Sign-off happens on screens instead of needs, so changing a screen reopens the whole discussion. #### What it gives an AI agent An agent asked for a feature with no business requirement behind it has no way to tell whether its version solves the real need. With one, it can check its work against the need, not just the words of the feature request. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Add an online booking page. | Patients can book appointments outside the clinics' opening hours. | #### How it relates to the rest - **Refines** an objective (one level up). - Is refined by **stakeholder** and **functional / non-functional** requirements. - Epics usually implement business or stakeholder requirements. #### In CorPole - Type **Business Requirement** (BR), in the Requirements group. Like every requirement, it belongs to an initiative. - Needs at least one acceptance criterion before it can be Approved or Authority. - Linked upwards with **refines** to an objective. - Once delivered, the business rules it introduced are kept in the solution's design as business design records (BDR). ### Stakeholder requirement Source: https://corpole.com/learn/stakeholder-requirement What a specific group of people needs, in their own terms, usually written as a user story. #### What it is A stakeholder requirement names a group — patients, receptionists, clinic managers — and what they need to do or achieve. It is often written as "As a …, I want …, so that …". #### Why it matters Different people need different things from the same system, and some needs conflict. Writing them per group makes the differences visible early, when they are cheap to resolve, and keeps the voice of the people who will actually use the software in the solution. #### What goes wrong without it - The system serves the people who spoke up in meetings and ignores the ones who did not. - Conflicting needs (patients want flexibility, receptionists want predictability) surface only in production. - Usability problems appear late, because nobody wrote down what each group was trying to do. #### What it gives an AI agent An agent that knows who a feature is for writes different code for a receptionist on a desktop all day than for a patient on a phone once a month. Stakeholder requirements give it that context in a form it can quote back. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Appointments can be changed. | As a patient, I can move my own appointment online, so that I do not have to call the clinic. | #### How it relates to the rest - **Refines** a business requirement. - Is refined by **functional** and **non-functional** requirements. - Stories usually implement stakeholder or functional requirements. #### In CorPole - Type **Stakeholder Requirement** (SR), in the Requirements group. It belongs to an initiative. - Needs at least one acceptance criterion before Approved or Authority. - Linked upwards with **refines** to a business requirement. ### Functional requirement Source: https://corpole.com/learn/functional-requirement A behaviour the system must have: what it does in response to a user or an event. #### What it is A functional requirement describes observable behaviour: when this happens, the system does that. It is the level closest to the code, and the one agents implement most often. #### Why it matters Functional requirements are where intent becomes testable. A good one can be checked by a test or a person without interpretation, which is what makes "done" mean the same thing to everyone. #### What goes wrong without it - Developers and agents implement their own interpretation of a vague need. - Testers cannot say whether something works, only whether it looks right. - Edge cases (what if the appointment is in the past? what if two people book the same slot?) are decided by accident. #### What it gives an AI agent This is what an agent builds from. A precise functional requirement with acceptance criteria is the difference between an agent that ships the right behaviour and one that ships a plausible guess. The criteria also give the agent a way to prove its work with tests. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Patients can change appointments. | A patient can move an appointment to another free slot up to 2 hours before it starts; later changes are refused with a message to call the clinic. | Acceptance criteria then spell out each case: moving within the limit, moving too late, choosing a taken slot. #### How it relates to the rest - **Refines** a stakeholder or business requirement. - Is **realized** by technical requirements. - Stories **implement** it and **cover** its criteria; tests verify the criteria. #### In CorPole - Type **Functional Requirement** (FR), in the Requirements group. It belongs to the initiative that changes the behaviour. - Needs at least one acceptance criterion before Approved or Authority; each criterion gets its own code, e.g. FR-5C0A71/AC2. - Criteria turn Met or Not met through linked tests or a person; an agent's own report stays unverified until then. - The behaviour the system has today is described by a functional design record (FDR); the stories that implement the requirement carry the design change to it. ### Non-functional requirement Source: https://corpole.com/learn/non-functional-requirement How well the system must work: speed, security, reliability, accessibility, scale. #### What it is A non-functional requirement describes a quality rather than a behaviour: how fast, how secure, how available, how accessible. It applies across many features at once. #### Why it matters Qualities are what users feel and what breaks at scale. A booking page that works but takes eight seconds on a phone loses patients just as surely as one that does not work. #### What goes wrong without it - Performance, security and accessibility are tested for the first time just before launch. - Each developer or agent chooses their own trade-offs, so quality is uneven. - Problems are found by users, under load, in production. #### What it gives an AI agent Agents optimise for the task in front of them and rarely consider qualities nobody mentioned. A measurable non-functional requirement tells the agent which trade-offs are not acceptable — for example, no extra round trip on the booking page. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | The booking page should be fast. | The booking page loads in under one second for 95% of loads on a mid-range phone over 4G. | #### How it relates to the rest - **Refines** a stakeholder or business requirement. - Is often **realized** by technical requirements (caching, indexes, architecture choices). - Tests verify its criteria, often in CI or monitoring. #### In CorPole - Type **Non-functional Requirement** (NFR), in the Requirements group. It belongs to an initiative. - Needs at least one acceptance criterion before Approved or Authority. - Unlike constraints, it describes a quality to achieve, not a limit on how to build. - Once delivered, the quality is kept in the solution's design as a non-functional design record (NFDR), grouped by the ISO 25010 qualities. ### Technical requirement Source: https://corpole.com/learn/technical-requirement A binding technical or architectural decision about how the system is built. #### What it is A technical requirement fixes a "how": the database, an integration, an API style, a hosting region. It is written when the choice is not up for debate in every story. #### Why it matters Some decisions are expensive to reverse and affect everything built after them. Writing them down as requirements keeps every developer and every agent building on the same foundations. #### What goes wrong without it - Each feature picks its own library, pattern or data store. - Integrations are rebuilt differently each time. - A choice made in one sprint is silently undone in the next. #### What it gives an AI agent Agents happily introduce a new framework or pattern if it helps the task at hand. Technical requirements tell them which foundations are fixed — for example, "use the clinics' existing calendar, do not keep a second schedule" — so they build on them instead of around them. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Use a good calendar integration. | Appointments are read from and written to the clinics' existing calendar; the app keeps no separate schedule. | #### How it relates to the rest - **Realizes** a functional or non-functional requirement: it says how that is achieved. - Often comes with a **decision** that records why this choice was made. - Different from a **project requirement**, which is about what the solution delivers, not how the product is built. #### In CorPole - Type **Technical Requirement** (TR), in the Requirements group. It belongs to an initiative and can name the component it affects. - Needs at least one acceptance criterion before Approved or Authority. - Linked with **realizes** to the functional or non-functional requirement it serves; the agent reads it in the work context of every story that implements those. - How the component is built today — modules, interfaces, data, integrations, infrastructure — is kept as technical design records (TDR) of that component; the reason for a lasting choice is an architecture decision record (ADR). ### Project requirement Source: https://corpole.com/learn/project-requirement Something the solution must deliver besides the product itself: training, documents, a test suite, a migration. #### What it is A project requirement describes a deliverable of the solution rather than a behaviour of the software. Training for receptionists, a user guide, a data migration from the old system, an agreed test report. #### Why it matters A product can work perfectly and still fail to launch because nobody trained the people who use it, or the old data never arrived. Project requirements make those deliverables visible and planned, instead of remembered in the last week. #### What goes wrong without it - Go-live is blocked by a forgotten deliverable. - Training, documentation and migration are squeezed in at the end, badly. - The team and the customer disagree about what "finished" includes. #### What it gives an AI agent Agents can produce many project deliverables — guides, migration scripts, test suites — if they know they are expected. A project requirement tells them, and gives people a way to check the deliverable against criteria. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Receptionists should know how to use it. | Every receptionist completes a one-hour training with the new schedule view before go-live. | #### How it relates to the rest - Sits **beside** the chain: it does not refine a business requirement. - A **work package delivers** a project requirement. - Differs from a **technical requirement** (how the product is built) and from a **project constraint** (a limit on how the solution is run). #### In CorPole - Type **Project Requirement** (PR), in the Requirements group. It belongs to the initiative that must deliver it. - Needs at least one acceptance criterion before Approved or Authority. - Work packages are linked to it with **delivers**. ### Product constraint Source: https://corpole.com/learn/product-constraint A limit on what the product may be or do. #### What it is A product constraint rules something in or out for the product itself: web only in the first release, no AI features, no storing card numbers, must run in the customer's own cloud. #### Why it matters Constraints are decisions about what not to do. They protect the solution from good ideas that would cost too much, take too long or cross a line the business cannot cross. #### What goes wrong without it - Someone builds the native app nobody budgeted for. - A feature is designed that cannot legally or technically ship. - The same "why don't we just…" discussion happens in every planning meeting. #### What it gives an AI agent Agents are generous: asked for a feature, they will add related ones. Product constraints tell them where the boundary is, so the agent says "out of scope for the first release" instead of building it. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Keep it simple for now. | The first release is web only; no native iOS or Android apps. | #### How it relates to the rest - **Constrains** specific requirements, or the whole solution if it is linked to none. - Can come from a **decision** that records the reason. - Different from a non-functional requirement: it limits the product, it does not describe a quality to reach. #### In CorPole - Type **Product Constraint** (PC), in the Constraints group. - Acceptance criteria are optional. - A constraint with no **constrains** link applies to the whole solution; agents receive solution-wide constraints with every piece of work. - A lasting limit on the product, such as where data is kept, is part of the solution's design as a non-functional design record (NFDR, compliance). ### Business constraint Source: https://corpole.com/learn/business-constraint A limit that comes from the organisation, the market or the law. #### What it is In CorPole a business constraint is kept as a corporate rule: a standard of the portfolio (Knowledge, category Corporate rule), set once in Start → Portfolio and followed by every solution and agent. A business constraint is imposed from outside the product: patient data must stay in the EU, prices must include VAT, the bank's regulator requires an audit trail, a partner contract forbids certain integrations. #### Why it matters These limits are not negotiable inside the solution, and breaking them is costly: fines, lost contracts, a launch blocked by the legal team. Writing them down early means designs respect them from the start. #### What goes wrong without it - A compliance rule is discovered in the security review, after the architecture is fixed. - Data ends up in the wrong region or the wrong system. - Different teams interpret the same regulation differently. #### What it gives an AI agent An agent will pick a hosting region, a logging library or an analytics tool without a second thought. A business constraint like "patient data stays in the EU" makes that choice a rule, which the agent checks before it adds anything that moves data. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Be careful with patient data. | Patient data is stored and processed only in the EU. | #### How it relates to the rest - **Constrains** requirements that touch it, or the whole solution. - Often realised through **technical requirements** (hosting region, encryption). - Mandatory account-wide standards can express the same kind of rule for every solution. #### In CorPole - Type **Business Constraint** (BC), in the Constraints group. - Acceptance criteria are optional. - Delivered to agents with every piece of work it constrains, or with every piece of work when it applies to the whole solution. ### Project constraint Source: https://corpole.com/learn/project-constraint A limit on how a change is delivered: time, budget, team, tools. #### What it is A project constraint limits the delivery rather than the product: live within three months, a budget ceiling, a team of two, only approved tools, no production access for contractors. It belongs to the initiative that carries out the change. #### Why it matters Time and money shape every technical choice. A design that is right for a two-year programme is wrong for a three-month launch. Making the limits explicit lets everyone choose solutions that fit them. #### What goes wrong without it - The team designs for an ideal world and runs out of time. - Scope is cut at the last moment instead of planned. - Tools or services are adopted that the organisation cannot pay for or support. #### What it gives an AI agent Agents do not know your deadline or budget. A project constraint lets the agent prefer the simpler option, flag work that will not fit, and avoid paid services the initiative cannot pay for. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | We need this soon. | The system is live in three months, before the spring rush. | #### How it relates to the rest - **Constrains** the whole solution or specific requirements. - Differs from a **project requirement**: a constraint limits how the change is delivered, a project requirement is something it must deliver. - Work packages and their dates are planned within it. #### In CorPole - Type **Project Constraint** (PJC), in the Constraints group. It belongs to an initiative. - Acceptance criteria are optional. - Agents receive solution-wide constraints with every piece of work. ### Demand Source: https://corpole.com/learn/demand A request for change, recorded as it arrived: who asked, how, when and what. #### What it is A demand is the raw request before anyone has decided what to do about it: the receptionists asking for a longer notice period, a regulator's letter, a customer complaint, an idea from a kickoff. It records who asked, through which channel, when, and in their own words. #### Why it matters Every change should start from someone's need. Recording the request as it came keeps the original voice, lets people compare requests before committing to any, and makes it possible to answer the requester later: what happened to what I asked for? #### What goes wrong without it - Work starts because someone mentioned it in a corridor, and nobody can say who asked for it. - Requests get lost between e-mail, chat and meetings, and requesters never hear back. - The team commits to everything, because nothing sits in a queue waiting to be weighed. #### What it gives an AI agent An agent that is asked to "just add it" can instead record the request as a demand and show how it compares with what the solution already does: new, already there, partly there, removed before, or in conflict. People then decide, instead of the agent building every request it hears. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Someone said two hours is too short. | Receptionists (meeting, 3 March): moves made less than two hours before leave slots we cannot refill; we need at least four hours. | #### How it relates to the rest - Answered by one or more **initiatives**. - Can lead to new objectives and requirements in that initiative. - Closes when all its initiatives close. #### In CorPole - Code **DMD-…**, kept at portfolio (tenant) level. It starts in the **Funnel** of the Portfolio board. - People with the portfolio.manage permission review it and link it to a new or open initiative, or mark it Not pursued with a reason. - The "no work without a demand" gate (enforced, advisory or off) lets work be committed only when its initiative answers a demand. - Agents record demands with `assess_request`; `list_demands` and `get_demand` read them. ### Initiative Source: 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. #### What it is An initiative is a piece of change with a beginning and an end: build the first release, add reminders, fix what broke last night. It holds the objectives, requirements and project constraints of that change, and all the work that delivers it. It is managed in one of three modes: **as a project** (Reviewing, Analyzing, Ready, Implementing, Done), **small work** (Reviewing, Ready, Implementing, Done) or **urgent work** (straight to Implementing). #### Why it matters A solution lives for years; the changes to it come and go. Keeping each change in its own initiative shows what is being changed, why and by whom, and lets the portfolio limit how many changes run at once. It also gives every change a clear end: an initiative is done when all its work is done; its requirements then become history, and what it built is described by the solution's design. #### What goes wrong without it - Everything sits in one long backlog, and nobody can say which work belongs to which request. - Too many changes run at once, and none of them finishes. - Requirements of finished work stay mixed with those of work still in progress. #### What it gives an AI agent An agent works for one initiative at a time. New work and requirements it proposes go to that initiative, so they never float free. When several initiatives are open and none is chosen, the agent asks the person once instead of guessing. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Clinic Booking backlog. | Initiative "Online booking — first release", managed as a project, answers the owner's demand for online booking; a later small-work initiative "Four-hour notice" answers the receptionists' demand. | #### How it relates to the rest - Answers one or more **demands**; can change one or more solutions. - Holds **objectives**, **requirements** and **project constraints**; epics, stories and tasks belong to it. - Its work carries the **design changes** that update the solution's **design records**. #### In CorPole - Shown on the **Portfolio** board; each step can have a WIP limit (urgent work may exceed it, and that is recorded). - Closing gate: Done only when all its work is Done or Cancelled. - Each solution has a quarterly **maintenance** initiative for defects; open work rolls over each quarter. An urgent initiative closes with a post-incident review that becomes a proposed lesson. - The initiative picker in the top bar filters boards, work, planning, forecast and requirements. Agents choose one with `select_initiative`. ### Design record Source: 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. #### What it is Where a requirement says what should change, a design record says what is true now. There are five kinds: **BDR** (business: processes and rules), **FDR** (functional: capabilities and screen flows), **NFDR** (qualities, grouped by ISO 25010, and compliance), **TDR** (technical, per component: modules, interfaces, data, integrations, infrastructure) and **ADR** (architecture decisions and their reasons). #### Why it matters Requirements describe changes; after a few years nobody can read the current system out of them. Design records keep one up-to-date description, with every version and the work, requirement and initiative that brought it. Because the description changes only when work is Done, it never claims the system does something it does not do yet. #### What goes wrong without it - The only description of the system is the code, or a pile of old specs that each describe a different moment. - Two changes quietly edit the same rule, and nobody notices until both ship. - Nobody can say when a behaviour arrived or which request brought it. #### What it gives an AI agent An agent needs two things: what the solution is today, which it must respect, and what it has been asked to change. Design records are the first; the initiative's requirements and the story's design change are the second. The agent also sees other open work that changes the same records. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Rescheduling rule: see the old spec. | FDR — Move an appointment: a patient can move an appointment to a free slot up to 4 hours before it starts. Version 2, from the story "Four-hour notice" in the initiative of the same name. | #### How it relates to the rest - Belongs to the **solution**; a TDR also belongs to a **component**. - Changed only by the **design changes** (add, change, retire) that epics, stories, tasks and defects carry, applied when the work is Done. If two pieces of work change the same record, the first Done wins and the other must be looked at again. - Its acceptance lines are criteria (FDR-1A2B3C/AC2) that **tests** prove. #### In CorPole - The **Design** page (/app/design) lists records by kind; each record shows its versions and pending changes. - Onboarding an existing codebase produces design drafts of the repository's component; a person confirms them as the design, turns wrong behaviour into a defect, or rejects them. - Agents read with `list_design_records` and `get_design_record`, and propose changes with `propose_design_delta`. ### Component Source: 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. #### What it is A solution has a main component and can have more. Each component has its own repositories (on GitHub or GitLab; a folder of a monorepo can belong to a component), its own onboarded code modules and its own technical design. #### Why it matters Real systems are rarely one codebase. Knowing which part a change touches tells people who owns it, which repository the code goes to and which technical design applies, and lets an old part and a new part be governed at different levels. #### What goes wrong without it - Two repositories both have a src/ folder and their modules get confused. - A rule written for the mobile app is applied to the booking service. - An old codebase that is still being onboarded holds back the new one. #### What it gives an AI agent An agent working in a repository gets the design and rules of that repository's component. The CorPole plugin tells CorPole which repository the agent is in, so findings, code checks and module rules land on the right component. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | The code. | Clinic Booking has two components: "web" (the patient site, repository clinic/booking-web) and "calendar-sync" (the calendar service, a folder of the same repository). | #### How it relates to the rest - Part of a **solution**; holds **repositories** and code modules. - Its technical design is kept as **TDR** design records. - Can have its own authority tier; the solution's tier is the lowest of its components. #### In CorPole - Managed in Solution settings → **Components**; repositories are connected in Solution settings → **Repositories and CI**, each with its own webhook secret. - Onboard each repository separately; module paths are unique per component. - Work, requirements and design records can name the component they affect. ### Acceptance criterion Source: 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. #### What it is An acceptance criterion states, in terms anyone can check, one situation the requirement must handle and the result expected. A requirement usually has several: the normal case, the limits, the errors. A common form is Given … When … Then …: given a starting situation, when something happens, then this is the result. #### Why it matters Criteria are where people agree what "done" means before work starts, not after it is shipped. They expose the edge cases while they are still cheap: what happens one minute past the limit, with a taken slot, with no connection. They are also what tests are written against, which is how a requirement becomes provable. #### What goes wrong without it - "Done" means different things to the developer, the tester and the product owner. - Edge cases are decided in the code, by whoever writes it, without anyone noticing. - Arguments after release about whether something is a defect or a new request. - Tests check what the code does, not what the requirement needed. #### What it gives an AI agent Criteria are the most useful thing you can give a coding agent. They tell it exactly which cases to handle, and they give it something to prove: an agent that must turn each criterion into a passing test cannot quietly skip the hard case. They also protect you from an agent's optimism. "All done" means little; "AC1 and AC2 Met, verified by these tests" can be checked. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Moving appointments works correctly. | AC2 — Given an appointment that starts in 1 hour, when the patient tries to move it, then the change is refused and the patient is asked to call the clinic. | The requirement "move up to 2 hours before" gets one criterion for the allowed case, one for the refused case, and one for a slot that is already taken. #### How it relates to the rest - Belongs to exactly one requirement (or constraint) and gets a code from it, e.g. FR-5C0A71/AC2. - **Tests verify** criteria; **stories and defects cover** them. - When the requirement changes, its criteria are reviewed with it. #### In CorPole - Requirement types (BR, SR, FR, NFR, TR, PR) need at least one criterion before they can be Approved or Authority. - Each criterion is Not verified, Met or Not met. A linked active test decides it automatically; a person can decide it too. - An agent's own report marks a criterion Met but unverified until a person or a test confirms it. - Changing a criterion's wording resets it to Not verified, because the old proof no longer applies. - Design records have criteria too: each line of a design record's acceptance text is a criterion, e.g. FDR-1A2B3C/AC2, that tests prove about the system as it is. ### Test case Source: https://corpole.com/learn/test-case A repeatable check that proves one or more acceptance criteria, automated or run by a person. #### What it is A test case describes how to check a criterion: the steps or the automated test, the data, and the expected result. It has a level — unit, integration, end-to-end, manual or user acceptance — and a latest result: passed, failed, blocked or not run. #### Why it matters Tests are the evidence. A criterion someone says is met is an opinion; a criterion a passing test verifies is a fact that can be checked again tomorrow, after the next change, by anyone. Linked to criteria, tests also show which requirements a failing build actually puts at risk. #### What goes wrong without it - Nobody knows which requirement a failing test protects, so failures are ignored or deleted. - Requirements are "met" once and silently broken by a later change. - Manual checks before release are improvised and different each time. #### What it gives an AI agent Agents write tests quickly, but they write them against their own code unless told otherwise. A test case linked to a criterion makes the agent test what the requirement needs, and its result — reported from CI, not from the agent's memory — is what moves the criterion to Met. It also makes one kind of shortcut visible: an agent that weakens a test to make it pass changes a record people can see. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Test that rescheduling works. | End-to-end test "late move is refused": book a slot 1 hour ahead, try to move it, expect the refusal message and the original slot kept. Verifies FR-5C0A71/AC2. | #### How it relates to the rest - **Verifies** one or more acceptance criteria. - A **defect** is usually closed with a test that proves the fix. - Results can arrive from CI, from an agent, or from a person running it. #### In CorPole - Levels: unit, integration, end-to-end, manual, UAT. Statuses: Draft, Active, Obsolete. - Only an **Active** test's latest result decides the criteria it verifies; a Draft test's results do not count yet. - A test can verify a requirement's criteria or a design record's criteria (FDR-1A2B3C/AC2). - Agents propose tests (`propose_test_case`) and report results (`report_test_result`); CI can report them too. ### Theme Source: https://corpole.com/learn/theme A strategic focus area that groups epics for quarters or years. #### What it is A theme names a direction the organisation invests in over a long period — "self-service for patients", "clinic operations" — and groups the epics that move it forward. It is the top of the work tree. #### Why it matters Themes let leaders see where effort actually goes. When most epics fall under one theme and a stated priority has none, the plan and the strategy have drifted apart. #### What goes wrong without it - Work is a long flat list; nobody can say how much went into each strategic goal. - Priorities change in presentations but not in the backlog. #### What it gives an AI agent Agents rarely work at theme level, but a theme gives their work a place: when an agent proposes new epics, the theme tells it which direction they should serve and helps people see proposals that serve none. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Phase 2 stuff. | Self-service for patients: patients do online what they used to phone the clinic for. | #### How it relates to the rest - **Serves** an objective. - Epics are **part of** a theme. - Workflow: Planned, Active, Done. #### In CorPole - Type **Theme** (TH), the top of the value tree: Theme → Epic → Story or Task → Subtask. - Themes are not planned in work packages; their epics are. ### Epic Source: https://corpole.com/learn/epic A large piece of value or a capability, delivered over weeks or months and broken into stories and tasks. #### What it is An epic is a capability users or the business will notice as a whole: online rescheduling, reminders, a staff schedule view. It is too big to build in one go, so it is split into stories (with code) and tasks (without). #### Why it matters Epics are the level at which scope is decided and progress is felt. They let a team say "rescheduling is 3 of 5 stories done" instead of counting tickets, and they are where the question "is this still worth it?" is asked. #### What goes wrong without it - Stories float without a shared purpose, and nobody sees the capability until it is almost finished. - Half-finished capabilities ship because nobody tracked what was still missing. #### What it gives an AI agent An agent that knows the epic behind a story sees the neighbouring stories and avoids building the same thing twice, or building one story in a way that blocks the next. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Appointment improvements. | Online rescheduling: patients move or cancel their own appointments without calling the clinic. | #### How it relates to the rest - **Part of** a theme; stories, tasks and defects are part of it. - Belongs to an **initiative**, like all the work under it. - Usually **implements** business or stakeholder requirements. - **Planned in** a work package. #### In CorPole - Type **Epic** (EP). Workflow: Idea, Analysis, Ready, In delivery, Done. - CorPole warns about work that implements no requirement: without one, it is scope creep until a requirement is linked. - A large change, such as a redesigned process, can be carried as a design change on the epic; it is applied to the solution's design when the epic is Done. ### Work package Source: 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. #### What it is A work package groups the work planned for a delivery — a release, a phase, a contract — and carries the management facts: who owns it, when it starts and ends, what it may cost. Work packages can nest, like a work breakdown structure. #### Why it matters Value and delivery are different questions. An epic answers "what capability"; a work package answers "what ships in the spring release, on whose budget". Keeping both lets a team change the plan without rewriting the product structure. #### What goes wrong without it - Releases are defined by whatever happened to be finished. - Budgets and dates live in a separate spreadsheet that never matches the backlog. - Project deliverables such as training are planned nowhere. #### What it gives an AI agent A work package tells an agent what belongs to the current delivery, so it does not start on work planned for later, and which project requirements the delivery must also produce. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Sprint stuff. | Release 1 — spring launch: owner Aylin, 1 Feb – 30 Apr, includes online rescheduling and reminders, delivers receptionist training. | #### How it relates to the rest - Epics, stories and tasks are **planned in** one package; it cuts across the value tree. - **Delivers** project requirements. - Can be **part of** a larger package. - Differs from an **initiative**: the initiative is the change a demand asked for; a work package plans when and by whom part of it ships. #### In CorPole - Type **Work Package** (WP), with owner, dates and budget. - Workflow: Planned, In delivery, Done. ### Story Source: https://corpole.com/learn/story A small piece of work that involves code, delivered in days. The unit a coding agent works on. #### What it is A story is a slice of an epic small enough to build, review and verify in a few days. It says what will change for whom, and points at the requirement it implements and the criteria it will satisfy. #### Why it matters Small, verifiable steps keep feedback fast. A story that is ready — clear requirement, known criteria — can be built without a meeting; a story that is not ready turns into one. #### What goes wrong without it - Work starts on vague tickets and stalls on questions. - Stories are "done" when the code merges, whether or not the requirement is met. - Nobody can say which requirement a change was for. #### What it gives an AI agent The story is the agent's assignment. With its requirement, the why-chain above it, the constraints and decisions that apply, and the criteria to prove, an agent can work unattended and show its work. Without them it guesses. Readiness rules keep agents off stories that are not ready, and done rules keep them from declaring victory early. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Reschedule feature. | Patient moves an appointment from the link in the confirmation e-mail. Implements FR-5C0A71; covers AC1–AC3. | #### How it relates to the rest - **Part of** an epic; **implements** requirements; **covers** their criteria. - Belongs to an **initiative**; carries the **design changes** it makes to the solution's design records. - **Planned in** a work package; subtasks are part of it. - Different from a stakeholder requirement: a story is work, a requirement is a need. See the comparison page. #### In CorPole - Type **Story** (ST). Workflow: Backlog, Ready, In progress, Code review, Verification, Done. - Ready: implements at least one requirement (preferably Authority) and covers at least one criterion. Committing it (to Ready, or straight to In progress) also needs its initiative to answer a demand, when the demand gate is on. - Done: every covered criterion is Met, and not only on an agent's word. Its design changes are then applied to the solution's design. - A story cannot implement a Retired record; it must implement the record that replaced it. ### Task Source: https://corpole.com/learn/task Work without code: configuration, access, records, operational or documentation steps. #### What it is A task is work that has to happen but does not change code: set up the SMS sender, grant the service access to the calendar, import the clinic list, write the receptionist guide. #### Why it matters Much of what blocks a launch is not code. Tracking it next to the stories makes it visible, owned and checked, instead of remembered the night before go-live. #### What goes wrong without it - Access, configuration and data steps are forgotten until something fails in production. - Operational changes happen without a second pair of eyes. #### What it gives an AI agent Agents can do many tasks — or prepare them for a person — but some, like granting production access, should need approval. Keeping tasks separate from stories lets the rules differ: approval before, a second check after. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Calendar stuff. | Grant the booking service read-write access to the clinics' calendar account (needs IT approval). | #### How it relates to the rest - Peer of a story under an epic; subtasks are part of it. - Can **implement** a requirement, often a technical or project requirement. - Planned in a work package. #### In CorPole - Type **Task** (TK). Workflow: Backlog, Awaiting approval, Ready, In progress, Check, Done. - Check means a second person checks the result before it is Done. ### Defect Source: https://corpole.com/learn/defect Something that does not behave as a requirement, a design record or an acceptance criterion says. #### What it is A defect is a gap between what was agreed and what the software does. It names the requirement, design record or criterion it breaks, how to reproduce it and how severe it is. #### Why it matters Tying a defect to a criterion settles the most common argument in software: bug or new request? If a criterion says so, it is a defect; if none does, it is a change and deserves a requirement. #### What goes wrong without it - Every complaint is called a bug, and change requests slip in as fixes. - Fixes are not proven, so the same defect returns. - Severity is decided by who shouts. #### What it gives an AI agent An agent fixing a defect needs the criterion it breaks, not just the symptom; otherwise it fixes the symptom. And a defect is closed with a test, so the agent has to prove the fix. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Rescheduling is broken sometimes. | A move 1 hour 59 minutes before the appointment is accepted; FR-5C0A71/AC2 says it must be refused. Severity: medium. | #### How it relates to the rest - Breaks an acceptance criterion, a requirement or a design record. - Part of an epic, or of the solution's maintenance initiative; fixed like a story; proven by a **test**. - Differs from a **risk**: a defect has happened; a risk might. See the comparison page. #### In CorPole - Type **Defect** (DEF). Workflow: New, Triage, Ready, In progress, Code review, Verification, Fixed. - A defect with no parent goes to the solution's quarterly **maintenance initiative**; one raised under a piece of work follows that work's initiative. - Agents report defects with `report_defect`. ### Decision Source: https://corpole.com/learn/decision A choice with its context, the options considered and its consequences, kept so nobody has to guess later. #### What it is A decision record (often called an ADR, architecture decision record) captures a choice that shapes later work: the situation, what was decided, what else was considered and what follows from it. #### Why it matters Code shows what was done, never why. Six months later the reasons are what everyone needs — to keep a choice, or to change it safely — and they are exactly what gets lost. #### What goes wrong without it - The same discussion is held again every few months. - Someone "fixes" a deliberate choice because nobody knew it was deliberate. - Newcomers cannot tell a principle from an accident. #### What it gives an AI agent Agents are the newcomer who never stops arriving. Without decisions, an agent will reopen settled questions — swap the library, change the pattern — in good faith. Accepted decisions tell it what is settled and why. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | We use the calendar API. | Use the clinics' calendar API directly rather than a nightly sync. Context: double bookings with a copy. Consequence: we must handle API rate limits. | #### How it relates to the rest - Often explains a **technical requirement** or a **constraint**. - An architecture decision that shapes the solution for years is also part of its design, as an **ADR** design record; scope and priority decisions belong to an initiative. - Accepting a risk needs an accepted decision. - A decision can waive a standard for one solution. See decision vs standard. #### In CorPole - Type **Decision** (DEC). Statuses: Proposed, Accepted, Rejected, Superseded; only Accepted binds. - Agents propose decisions (`propose_decision`); people accept them. ### Question Source: https://corpole.com/learn/question An open point that needs a person's answer, with the working assumption used until it is answered. #### What it is A question records something nobody has decided yet, who should answer it, and — importantly — what the team assumes in the meantime so work can continue. #### Why it matters Solutions never wait for every answer. The danger is not open questions but hidden assumptions: someone guessed, built on the guess, and nobody knew it was a guess. #### What goes wrong without it - Guesses become facts because nobody wrote them down as guesses. - The same question is asked in five chats and answered differently in each. - Late answers break work that was built on a different assumption. #### What it gives an AI agent Agents fill gaps silently. Asking them to raise a question instead — and to state the assumption they will use — turns an invisible guess into something a person can confirm or correct in a minute. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | (nothing — someone assumed) | Can a parent move an appointment for their child? Working assumption: patients can only move their own appointments for now. | #### How it relates to the rest - An answer may become a new requirement or change one. - Differs from a decision: a question is still open. See question vs assumption. #### In CorPole - Type **Question** (QST). Statuses: Open, Answered. - Agents open questions with `ask_question`; a person answers. ### Glossary term Source: https://corpole.com/learn/glossary-term A word of the shared business language, with its definition and the words to avoid. #### What it is A glossary term fixes what a word means in this solution: what an "appointment" is, how it differs from a "slot" and a "booking", and which words not to use for it. #### Why it matters Many requirement misunderstandings are really vocabulary misunderstandings. When the business says "booking" and the code says "reservation" and the database says "event", every conversation needs a translator. #### What goes wrong without it - The same thing has three names in code, screens and documents. - Two different things share one name, and requirements are read two ways. #### What it gives an AI agent Agents name things constantly — variables, tables, screen texts. A glossary makes them use the business's words, so code, UI and requirements stay readable to each other. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Booking — the thing patients make. | Appointment: a patient's confirmed time with a clinician. Not "booking" or "reservation". A slot is a free time; an appointment fills it. | #### How it relates to the rest - Used in requirements, design records, criteria and screen texts. - Can be account-wide, shared by every solution. #### In CorPole - Type **Glossary term** (TRM). Statuses: Draft, Active, Retired. - People write terms; agents read them. ### Standard Source: https://corpole.com/learn/standard A rule for how work is done: coding, security, testing, compliance, definition of ready or done. #### What it is A standard is a rule that applies to all work of a kind, not to one feature: every endpoint that returns patient data logs access; every story has an end-to-end test; no secrets in code. #### Why it matters Standards are how an organisation keeps quality without reviewing everything by hand. They are written once and applied everywhere, and exceptions are visible. #### What goes wrong without it - Each team, and each agent session, invents its own rules. - Security and compliance depend on who happened to write the code. - Reviews argue about style instead of substance. #### What it gives an AI agent Agents follow the rules they are given and invent their own otherwise. Standards give every agent session the same rules, and account-wide standards reach every solution without being copied. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Be careful with logs. | Every request that reads patient data writes an access log entry with who, what and when; logs never contain the data itself. | #### How it relates to the rest - Account-wide standards apply to every solution. - A solution documents an exception with an accepted **decision** that waives the standard. #### In CorPole - Type **Standard** (STD). Statuses: Draft, Active, Retired. - People write standards; agents read them with `get_standards`. ### Lesson Source: https://corpole.com/learn/lesson Something learned the hard way in this solution, and what to do instead next time. #### What it is A lesson records a mistake, a wrong assumption or a tooling pitfall, with the evidence and the better way. It usually comes out of a retrospective. #### Why it matters Teams repeat mistakes when lessons live only in someone's memory. Written down and fed back into how work is done, a lesson is paid for once. #### What goes wrong without it - The same pitfall costs a day every few weeks. - Retrospectives produce good insights that nobody acts on. #### What it gives an AI agent Agents have no memory between sessions. A lesson accepted into the solution is the only way the next session knows what the last one learned — and a lesson can be turned into a permanent agent rule. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | Timezones were annoying. | The calendar API returns local clinic time, not UTC; always convert at the boundary. Cost us two failed releases. | #### How it relates to the rest - Comes from retrospectives with people or agents, and from the post-incident review that closes an urgent initiative. - Can be promoted to an agent rule. - Differs from an improvement idea: a lesson avoids a known mistake; an idea makes work better. #### In CorPole - Type **Lesson** (LSN). Statuses: Proposed, Accepted, Rejected, Retired. - Agents propose lessons (`submit_retrospective`); accepted lessons are given to agents. ### Risk Source: https://corpole.com/learn/risk Something that might happen and would hurt objectives, requirements or delivery. #### What it is A risk is an uncertain event with a consequence: it has a probability, an impact and a response. It is written before it happens, so something can be done about it. #### Why it matters Most project failures were visible as risks weeks earlier. Naming them, scoring them and choosing a response — avoid, reduce, transfer or accept — turns worry into planned work. #### What goes wrong without it - Known dangers are discussed in corridors and never acted on. - When one happens, it is a surprise and a crisis instead of a plan. - Accepted risks are nobody's decision. #### What it gives an AI agent Agents often notice risks first — a rate limit in the docs, a library near end of life, a migration that locks a table. Letting them raise risks puts that knowledge where people decide, instead of in a chat that scrolls away. #### Example: Clinic Booking | Weak | Strong | | --- | --- | | The calendar might be slow. | The clinics' calendar API may throttle us during the Monday 8–9 am rush. Probability 3, impact 4 (score 12, High). Response: mitigate — queue writes and retry. | #### How it relates to the rest - Threatens objectives, requirements or delivery. - Mitigation is planned as work; accepting it needs an accepted **decision**. - When it happens it becomes an issue; if it breaks a criterion, a **defect**. #### In CorPole - Type **Risk** (RSK), scored on a 5 × 5 matrix: Low, Medium, High, Critical. - Responses: Avoid, Mitigate, Transfer, Accept. Statuses: Identified, Assessed, Mitigating, Accepted, Occurred, Closed. - Agents raise risks with `raise_risk`. ### Technical requirement vs project requirement Source: 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. #### In short A **technical requirement** fixes how the product works inside: an integration, a database, an architecture. A **project requirement** is a deliverable of the change that is not product behaviour: training, a guide, a migration, a test report. Both belong to the initiative that carries out the change. #### Side by side | | Technical requirement | Project requirement | | --- | --- | --- | | Question it answers | How is the product built? | What else must the initiative deliver? | | What it leaves behind | A technical design record (TDR) of the component | A delivered item: people trained, data migrated | | Linked with | **Realizes** a functional or non-functional requirement | **Delivered** by a work package | | Survives the delivery? | Yes, it becomes part of the system's design | Usually done once, at delivery | #### How to tell them apart - If it would still be true of the running system after the initiative closes, it is technical. - If it is something handed over, done or produced for the launch, it is a project requirement. - If it limits the delivery (a deadline, a budget) rather than being delivered, it is a project constraint. #### Example: Clinic Booking Technical: "Appointments are read from and written to the clinics' existing calendar." Solution: "Every receptionist completes a one-hour training before go-live." #### Why the difference matters to an agent An agent treats a technical requirement as a rule for every story that touches the area. A project requirement is instead a deliverable it may be asked to produce. Mixing them up leads to agents enforcing a one-off deliverable as an architecture rule, or ignoring an architecture rule as a to-do item. ### Business requirement vs stakeholder requirement Source: 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. #### In short A **business requirement** is a capability the organisation needs to reach an objective. A **stakeholder requirement** is what one group — patients, receptionists, managers — needs, in their terms. #### Side by side | | Business requirement | Stakeholder requirement | | --- | --- | --- | | Voice | The organisation | A named group of people | | Typical form | "The clinic can …" | "As a patient, I want … so that …" | | Refines | An objective | A business requirement | | How many | A few per objective | Several per business requirement, one per group | #### How to tell them apart - If it names a group of people and what they want, it is a stakeholder requirement. - If it describes what the organisation must be able to do, without saying for whom, it is a business requirement. - One business requirement often splits into different stakeholder requirements that may conflict. #### Example: Clinic Booking Business: "Patients can book outside the clinics' opening hours." Stakeholder: "As a patient, I can move my own appointment online" and "As a receptionist, I see every change made outside opening hours when I start my shift." #### Why the difference matters to an agent An agent building for a stakeholder requirement knows who it is building for and what they are trying to do, which changes the design. The business requirement above it tells the agent what must stay true for all groups at once. ### Functional vs non-functional requirement Source: https://corpole.com/learn/functional-vs-non-functional What the system does, and how well it does it. #### In short A **functional requirement** is a behaviour: when this happens, the system does that. A **non-functional requirement** is a quality across behaviours: speed, security, availability, accessibility. #### Side by side | | Functional | Non-functional | | --- | --- | --- | | Describes | A behaviour | A quality | | Scope | Usually one feature | Many features at once | | Checked by | A test of the behaviour | Measurement: load tests, audits, monitoring | | Missing it shows up as | A feature that does the wrong thing | A feature that works but is slow, unsafe or unusable | #### How to tell them apart - If you can demonstrate it with one example, it is functional. - If you need a number and a measurement, it is non-functional. - If it forbids an option rather than setting a level to reach, it may be a constraint. #### Example: Clinic Booking Functional: "A patient can move an appointment up to 2 hours before it starts." Non-functional: "The booking page loads in under one second for 95% of loads on a mid-range phone." #### Why the difference matters to an agent Agents implement behaviours well and qualities by accident. A non-functional requirement is often the only thing that stops an agent from adding a slow query or an extra round trip to a page that must be fast. ### Requirement vs constraint Source: https://corpole.com/learn/requirement-vs-constraint A requirement says what must be achieved. A constraint limits how it may be achieved. #### In short A **requirement** is something to deliver or make true. A **constraint** narrows the ways it may be delivered: a platform, a region, a deadline, a budget, a law. #### Side by side | | Requirement | Constraint | | --- | --- | --- | | Says | What must be true | What may not be done, or within which limits | | Satisfied by | Building something | Not crossing a line | | Scope | Specific | Specific requirements, or the whole solution | | Acceptance criteria | Required before approval | Optional | #### How to tell them apart - Ask "is this a goal or a limit?" A goal is a requirement; a limit is a constraint. - If removing it would make the job easier, not smaller, it is a constraint. - Where the limit comes from tells you its kind: the product (product constraint), the organisation or the law (business constraint), the delivery (project constraint). #### Example: Clinic Booking Requirement: "Send a reminder 24 hours before each appointment." Constraints on it: "Patient data stays in the EU" (so the SMS provider must be EU-based) and "Web only in the first release" (so no push notifications from a native app). #### Why the difference matters to an agent Agents optimise for the requirement in front of them. Constraints are what stop them from choosing the convenient US-hosted service or the quick native-app shortcut. That is why solution-wide constraints reach the agent with every piece of work. ### Theme, epic, story, task and work package Source: 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. #### In short Work is split by size into a tree: a **theme** holds epics for quarters or years, an **epic** is a capability over weeks or months, a **story** is a slice with code done in days, and a **task** is a slice without code. A **work package** is not in the tree: it is the delivery container — owner, dates, budget — that the work is planned in. All of it belongs to an **initiative**, the change a demand asked for. #### Side by side | | Size | Contains | Example | | --- | --- | --- | --- | | Theme | Quarters–years | Epics | Self-service for patients | | Epic | Weeks–months | Stories, tasks, defects | Online rescheduling | | Story | Days, with code | Subtasks | Move an appointment from the e-mail link | | Task | Hours–days, no code | Subtasks | Grant calendar access to the booking service | | Work package | A delivery | Planned epics, stories, tasks | Release 1 — spring launch | #### How to tell them apart - Does it change code? Story. Does it not? Task. - Can it be finished in days? If not, it is an epic that needs splitting. - Is it about when, by whom and on what budget rather than what? Work package. - Is it a direction rather than a deliverable? Theme. #### Example: Clinic Booking Theme "Self-service for patients" → Epic "Online rescheduling" → Story "Move from the e-mail link" and Task "Grant calendar access", all planned in Work package "Release 1 — spring launch". #### Why the difference matters to an agent The story is where an agent works; the levels above it give it context. An agent that can see its epic avoids duplicating a neighbouring story, and a work package tells it what belongs to the current delivery. ### Stakeholder requirement vs story Source: 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. #### In short A **stakeholder requirement** is a need: it says what a group of people must get from the change, and it binds the whole initiative. A **story** is work: a slice of change that is built, verified and closed. Many teams use "user story" for both, which is why they get confused. #### Side by side | | Stakeholder requirement | Story | | --- | --- | --- | | Kind | A need (authority side) | Work (execution side) | | Lifetime | Its initiative; then kept as history with its reasons | Days, then Done | | Changes by | A decision about the need | Being built | | Proof | Its acceptance criteria are Met | The criteria it covers are Met, and its design changes are applied | #### How to tell them apart - If it states what a group needs, whichever piece of work delivers it, it is a requirement. - If it will be built, Done and closed, it is a story. - One requirement is often delivered by several stories, and one story can deliver parts of several requirements. #### Example: Clinic Booking Requirement: "As a patient, I can move my own appointment online." Stories implementing it: "Move from the e-mail link", "Move from the patient portal", "Show free slots for the next two weeks". #### Why the difference matters to an agent If the need lives only inside a story, it disappears when the story closes, and the next agent session has nothing to check against. Keeping the need as a requirement means every story in the initiative is measured against it, and the stories' design changes leave the solution's design describing what was actually built. ### Decision vs standard Source: 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. #### In short A **decision** records a specific choice, its context and consequences. A **standard** is a general rule for how work is done, often across every solution. #### Side by side | | Decision | Standard | | --- | --- | --- | | Scope | One question, one solution | All work of a kind, often account-wide | | Written as | Context, choice, consequences | A rule, with rationale and examples | | Who writes | Proposed by anyone, including agents; accepted by people | People | | Exception | — | An accepted decision can waive it for one solution | #### How to tell them apart - If it answers "which option did we pick here, and why?", it is a decision. - If it answers "how do we always do this?", it is a standard. - If a solution needs to break a standard, write a decision that waives it. #### Example: Clinic Booking Decision: "Use the calendar API directly, not a nightly sync." Standard: "Every request that reads patient data writes an access log entry." #### Why the difference matters to an agent Standards reach every agent session in every solution; decisions reach the work they govern. Keeping them apart stops one solution's choice from leaking into every solution, and stops an account-wide rule from being quietly overridden in one. ### Defect vs risk Source: https://corpole.com/learn/defect-vs-risk A defect has happened. A risk might. #### In short A **defect** is a present gap between what was agreed and what the software does. A **risk** is a possible future event that would hurt the solution or its delivery. #### Side by side | | Defect | Risk | | --- | --- | --- | | Time | Now | Maybe, later | | Measured by | Severity | Probability × impact | | Answered by | A fix, proven by a test | A response: avoid, mitigate, transfer, accept | | Tied to | A broken criterion or requirement | Objectives, requirements or delivery it threatens | #### How to tell them apart - Can you reproduce it today? Defect. - Is it something that could go wrong? Risk. - When a risk happens and breaks a criterion, it produces a defect. #### Example: Clinic Booking Defect: "A move 1 hour 59 minutes before the appointment is accepted." Risk: "The calendar API may throttle us during the Monday morning rush." #### Why the difference matters to an agent An agent that finds a failing behaviour should report a defect with the criterion it breaks. An agent that sees a danger in the docs should raise a risk. Both are more useful than a remark in a chat that nobody reads again. ### Question vs assumption Source: 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. #### In short A **question** is an open point that needs someone's answer. An **assumption** is the working answer the team uses meanwhile. In CorPole they live together: every question carries its working assumption. #### Side by side | | Question | Assumption | | --- | --- | --- | | States | What is unknown | What we act on for now | | Owner | Whoever must answer | The team, until the answer comes | | Danger | Staying open forever | Being forgotten and treated as fact | | Ends when | Answered | Confirmed or replaced by the answer | #### How to tell them apart - Every assumption should point to the question it stands in for. - An assumption with no question is a hidden guess. - When a question is answered differently from its assumption, check the work built on the assumption. #### Example: Clinic Booking Question: "Can a parent move an appointment for their child?" Assumption: "For now, patients can only move their own appointments." #### Why the difference matters to an agent Agents always assume something when information is missing. Asking them to open a question and state the assumption turns a silent guess into a visible, correctable one — and when the answer arrives, the affected work is easy to find. ## Help center ### Overview Source: https://corpole.com/support/getting-started/overview-screen · Getting started 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. #### Status brief | Tab | What it answers | | --- | --- | | For me | Since your last change in CorPole: what others changed, where you left off (your open work, with handover notes), what is blocked or failing on your work, and what waits for you — decisions, drafts, change proposals, items in Verification, open questions. | | Solution | Progress this week, decisions waiting, serious risks (score 12 or more), open drift signals, bottlenecks (blocked work, items stuck in review), maturity below target. | | Team | Each person's open, in-progress and blocked work; agent sessions waiting for a person; open alerts. It lists, it does not rank people. | | All my solutions | Every solution you can open, each on its own card: what you have in progress, what waits for your decision (for a solution under guided start: the number of your cards on **Waiting for you**, the same number as its context row below the top bar), dates due in two weeks, maturity below target, serious issues — then the next two weeks across solutions. **Open** switches to a solution to act in it. | Every line links to where the items are. Your coding agent gives the same brief with `get_status` — ask it "where were we?" or "what is the status of the solution?". The sentence under **For me** says how much needs you: "3 things need you first.", or "Nothing urgent." In a solution under guided start this number is the number of **cards** that wait for you on **Waiting for you** — the same number the context row below the top bar shows beside **Waiting**, read from the same list, so the two always agree. The first line under **Waiting for you** in the brief repeats it ("3 cards wait for you on "Waiting for you"") and opens that screen. Drafts your agents wrote are **not** counted: they show as one line that starts with "For your information" and links to the requirements board, because a draft does not need you — what needs you arrives as a card. In every other solution the number is as before: what is blocked or failing on your work, the decisions in your notices and the agent drafts to approve. #### What you can do here - Check how complete the solution is: the counters show all records and how many are **Authority**, **Approved** and **Draft**. - Follow **Acceptance**: the share of acceptance criteria verified as met across all records that are not retired, and how many requirements still have no criteria. Those requirements are listed so you can add criteria. - Check **Traceability**: open conflicts (they block Authority) and gaps in the chain, such as a functional requirement that refines nothing or an objective no business requirement refines. - Review **AI proposals awaiting review**: records coding agents proposed through `propose_record`. Open one to edit, approve or delete it. Findings from code, documents or tests are design drafts and are reviewed on the Onboarding page instead. - Jump to a record type from the **Record catalog**, or open **Explorer** to see every type side by side. - Create a record with **New record**. #### How to review an AI proposal 1. Open the proposal from the review table. 2. Read the statement and rationale. Check it does not duplicate or contradict an existing Authority record. 3. Choose **Edit** to sharpen the wording, set priority and owner. 4. Set the state to **Approved** or **Authority** if you agree, or delete the Draft if you do not. #### Keep in mind A proposal is never binding on its own. Agents keep treating it as a Draft until a person moves it to Authority. **Approved** means a person reviewed it; only **Authority** binds — the note on a proposal's page ("it binds nothing until a person makes it Authority"), the **AI proposal** badge and your agent's answers all use these words. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Solutions Source: https://corpole.com/support/getting-started/projects-screen · Getting started All solutions of your tenant. The active solution decides which records you see everywhere in the app and which records AI agents receive. #### What you can do here | Action | What it does | Who | | --- | --- | --- | | **Open solution** | Makes it the active solution for the whole app. | Everyone | | **Continue setup** | Resumes the guided setup where you left it. | Owner, admin, member | | **New solution** | Starts the guided setup for a new solution. | Owner, admin, member | | **Archive** | Hides the solution from the workspace and from AI agents; records are kept. | Owner, admin | | **Restore** | Brings an archived solution back and makes it active. | Owner, admin | #### Keep in mind - Archiving is reversible. It does not delete records, tokens or history. - While a solution is archived its API token and connected apps stop working. - You can also switch solutions from the **Solution** selector in the context row below the top bar. #### Starting a solution from your agent You do not have to start here. When you connect claude.ai, ChatGPT, Claude Code or Cursor, the sign-in screen offers **+ New solution**; tick **It already has code** for an existing codebase. In a conversation you can also say "let's start a new solution": the agent confirms the name and creates it for you (`create_project`), and an OAuth connection moves to the new solution. - A new idea starts with the **kickoff interview**: the agent asks you, section by section, what the solution must achieve and within which limits, and saves what you confirm as Drafts (`/corpole:start`). They belong to the solution's charter initiative, which CorPole opens with its demand. - In a solution under **guided start** the interview is the preparation stage. `/corpole:start` first completes what the solution starts from — who asked for it and why (the demand), the solution brief, the solution type (one of four, which the agent puts to you as a question with their consequences) and the mode (a new solution runs as a project) — and then goes through the eleven Spec perspectives one at a time, in the order the preparation summary gives. There is no minimum set to stop at and it never asks whether to start building: the specification binds at the preparation exit, and a work plan comes after phasing. If you want to skip preparation, the agent tells you the two ways that exist and their consequences. The agent does not ask for your yes after each section:it stores what it wrote as drafts in its own name, tells you in one line what it stored and goes on. What needs you — a decision that is yours, a change to the solution brief or to who asked and why, or the agent's suggestion that a part of the specification does not apply — arrives as a card on **Waiting for you**; the brief changes only when you apply it there. - An existing codebase starts with the **Onboard …** initiative and the **Shadow** authority tier: what the code shows becomes design drafts for review (see Onboarding and Solution settings). - Every solution also gets a quarterly **maintenance** initiative for defects and small fixes. - Nothing the agent records binds until a person approves it. You can continue in the web wizard exactly where the interview stopped. ### New solution Source: https://corpole.com/support/getting-started/create-a-project · Getting started The first step of the guided setup: name the solution and describe its context. The context is what AI suggestions later build on. #### How to fill it in - **Name**: the product or initiative as people call it. - **Key**: a short code (up to 12 characters) generated from the name. It must be unique in the tenant and is used by AI agents and the API. - **Description**: one or two sentences on what is being built. - **Is there code already?** Choose **No, it is new** for a product built from scratch, or **Yes, it runs today** for an existing system: CorPole then starts onboarding, and your agent discovers what the code does. - **Domain, audience, problem, outcomes**: the business area, who will use it, the problem it solves and the results you expect. > **Tip:** Concrete context gives better suggestions. "Sales reps lose track of corporate customers across Excel files" works better than "CRM". #### What happens next After saving, the setup asks whether to start from a document, tell the story, or go step by step through the requirement types of the initiative's mode (all nine as a project; functional, non-functional and technical as small work). Corporate rules are not asked here: they are the portfolio's standards. You can stop at any point and continue later from **Projects**. > **Tip:** Prefer talking to filling in forms? Let your coding agent run the kickoff interview instead (`/corpole:start` in Claude Code). It asks the same questions, checks vague answers, and saves what you confirm. ### Start Source: https://corpole.com/support/getting-started/start · Getting started 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). #### The three paths - **A new product:** a system built from scratch. You describe the solution, then its first change — the initiative that builds it — and its requirements. - **An existing system:** a codebase that runs today. You describe the solution and its code; your agent then discovers its modules and behaviour, and people confirm them (onboarding). - **A change to an existing solution:** a request for something new or different in a solution CorPole already knows. The request is recorded at once (or you pick one already waiting in the Funnel); people who manage the portfolio then open a new initiative for it — choosing the solutions it changes — or add it to one under way, and write its requirements straight into that initiative. Others stop after the request: it waits on the portfolio board. **The Demand step** asks why: who asked, how it came, the problem and, if you like, the expected outcome and a first intent. Only who asked and the problem are required. When the solution is created, this becomes its charter demand on the portfolio board, and the first intent starts its value case. **The Initiative step** fills the change that builds the solution: its title, what it delivers, how it is managed (as a project, or as small work) and its capacity type. The requirements that follow are the initiative's; small work is asked only what changes (functional, non-functional, technical). The path ends on a **summary** of what was created on each axis and what is still missing. **An existing system** goes from the solution to its code: add each repository (GitHub or GitLab, a folder for a monorepo) and the component it belongs to. The **onboarding plan** then lists what happens next — connect your agent, run /corpole:onboard in each repository, review the findings, raise the authority tier from Shadow as people confirm. The answer to "Is there code already?" decides the path, whichever card you started from. **The Portfolio step** comes first for owners and admins, once per tenant: the regulations and standards every solution follows (KVKK, BDDK, GDPR, ISO 27001, PCI DSS, WCAG), the corporate rules (business constraints, one per line) and work-in-progress limits. Each becomes a tenant-wide standard in Knowledge, which compliance and every agent read. It can be skipped; the portfolio page then keeps a reminder. **Practice first:** "Open my practice workspace" gives you a sandbox of your own filled with a CRM demo — demands, solutions, requirements, work and tests to explore and change. Nothing leaves CorPole from it, and only you are in it. Opening it again takes you back to the same one. Steps marked **coming** are part of the path but not built yet; the path skips them for now. #### Stopping and continuing A path remembers where you are. **Continue where you left off** takes you back; **Discard** drops a path you will not finish (what it already created stays). A path whose solution has been archived is not listed: there is nothing left to continue in it. ### Guided setup Source: https://corpole.com/support/getting-started/guided-setup · Getting started Builds the solution's first requirement set, one record type at a time, from the solution brief to objectives, requirements and constraints. #### The three ways to start | Option | Best when | | --- | --- | | **I have a document** | A brief, BRD, SRS or meeting notes already exist. AI extracts items of every type and you review them before saving. | | **Tell the story** | The solution is mostly in your head. You describe it in your own words and answer open questions. | | **Guide me step by step** | You are starting from scratch or want to think each type through. | #### Telling the story Write about the solution freely, like a prompt. CorPole then asks open questions from a fixed set, moving between topics such as goals, business rules, security, design and delivery. It never asks about the same topic twice in a row and does not press when you answer briefly. No AI is involved in the conversation. - **Skip this question** moves on; a topic you skip twice is not asked about again. - **That's enough, build the solution** shows how mature the story is: a score, coverage per topic and per record type. - From there you can **ask AI for help** (it drafts records of every type from the story for you to review), **keep talking**, or **continue with the wizard**. - The story is kept with the solution as a question-and-answer document. You can view or download it as Markdown, and AI suggestions in the wizard take it into account. #### At every step Each record type step explains why it matters and shows an example. Three sources feed one editable list: - **Write your own**: type items one by one. - **Upload a document**: PDF, Word, TXT or Markdown; AI pulls out matching items. - **Get suggestions**: AI proposes items from the solution brief and everything captured so far. This can take up to a minute. Tick the items you want, edit their title, statement and acceptance criteria (one per line), then save. **Skip this step** moves on without saving; you are asked to confirm if items are still selected. #### Keep in mind - Everything saved in the setup becomes a **Draft** of the solution's first initiative. Agents do not use it until you move records to Authority. - **Finish later** takes you to the summary; progress is kept. - You can return to earlier steps to add more; that does not undo later progress. - If AI is not configured on the server, only **Write your own** is available. ### Maturity Source: https://corpole.com/support/getting-started/maturity · Getting started 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. #### Levels | Level | Meaning | | --- | --- | | 0 None | Nothing on record in this dimension. | | 1 Started | Written down, but scattered. | | 2 Structured | Linked together; the gaps show. | | 3 Governed | Binding and checked; the gaps are small. | | 4 Self-sustaining | Measured, guarded by agents, improving over time. | A level counts only when **all** of its conditions and those of the levels below hold; one strong number cannot hide a weak one. A ratio on fewer than five items shows **?** (too little data) and counts as not met. #### Dimensions - **Design coverage** — is the solution described as it is? Design records confirmed, every component described, no delivered requirement without a design record, no design change left stale. - **Design verification** — is what the solution does proven by tests? The confirmed design records' criteria have tests, none fails, CI reports recently. - **Code governance** — is the code described and governed? Modules described by a design record, findings reviewed, onboarding kept fresh (only for solutions with code). - **Decisions and knowledge** — are the solution's decisions and terms on record? Solution decisions and glossary, answer times, lessons turned into rules. An initiative's own decisions and questions belong to that change. - **Agent governance** — are the agents under control? Connection, policy, repository kit, authority tier, drift. - Why a change is made and how far it has come — objectives, requirements, criteria, work — belongs to the initiative: its Readiness shows what it still needs. Until 26 September 2026 maturity measured those; the trend marks the switch with ↺. #### Targets and next steps The solution's profile — **Prototype**, **Product** or **Regulated** — sets a target level per dimension. Each dimension lists what stands between it and the next level, with a link to the evidence. Your agent can answer the same question with `get_maturity`. The solution's profile is chosen under ⚙ › Solution settings › Maturity profile. #### Settings: platform strict, account softens The thresholds, dimensions, conditions, method, profiles and where maturity shows are set under ⚙ › **Platform**, **Account** and **Tenant** › Maturity settings. The platform's values are strict; an account may soften them down to the platform's floors, and a tenant down to the account's floors — or be stricter. Locked items cannot be changed below. A solution only picks its profile. Softening is never hidden: the Maturity screen has **Our reading** and the **Platform reading**, and lists every threshold that was softened and by whom. Every settings change is kept with its reason. #### Over time and across solutions - Every night CorPole takes a snapshot of each solution. **Last 12 weeks** shows the level per week; ⚙ marks a week the settings changed, so a jump there may come from the settings rather than the work. - **Tenant projects** lists the solutions you can open, each against its own profile, and names the weakest dimension. - **Account** (owners and admins) shows every solution of the account across its tenants. - When a dimension falls below its target, the solution's approvers get one notice (topic: Quality). The maturity settings can turn it off. ### What CorPole is, and what it is not Source: https://corpole.com/support/getting-started/what-corpole-is · Getting started CorPole keeps your requirements, decisions and constraints with a state on each, and hands coding agents only what binds today. #### What it is A requirements authority for teams that build with AI agents. Every record carries a state (Draft, Approved, Authority, Retired), and agents connect over MCP to read exactly what binds for the work in front of them. - People decide what binds; agents propose. - Requests arrive as demands and are handled as initiatives; requirements say what an initiative should change. - The solution's design (business, functional, quality, technical and architecture records) describes what is built today; it changes when work carrying a design change is Done. - Work, tests and code trace back to the records they serve. - An agent policy and agent rules say what an agent may do and how it behaves. #### What it is not - **Not a coding agent.** The agent you already use writes the code; CorPole governs what it is told. - **Not a pipeline tool.** No build orchestration, deployment or infrastructure. - **Not general-purpose work management.** Work items exist to bring requirements to life, not to replace them. ### Why only Authority binds your agent Source: https://corpole.com/support/getting-started/why-only-authority-binds · Getting started An agent reads exactly what it is handed, every run. If everything in the repository looks current, stale decisions steer it. States fix that. #### The problem A person reads a spec once and remembers what matters. An agent reads whatever it finds, every time, and treats it as current. A decision you dropped last month is as convincing to it as one you made today. #### The four states | State | For the agent | | --- | --- | | **Draft** | Work in progress; never binding. | | **Approved** | Informative; the agent asks before relying on it. | | **Authority** | Binding; followed and cited by code. | | **Retired** | Never drives new work; out of every agent's context at once. | #### What follows from it - Retiring a record is how you stop an agent from following it. - An agent can propose, but only a person moves a record to Authority. - Requirements need at least one acceptance criterion before they can be Approved or Authority. ### Your first 15 minutes as a solo builder Source: https://corpole.com/support/getting-started/your-first-15-minutes · Getting started Connect Claude Code, run the kickoff interview, approve what binds and let the agent plan the first story. #### Steps 1. Add the server in Claude Code: `claude mcp add --transport http corpole https://corpole.com/api/mcp`, then `/mcp` → **Authenticate** and pick or create your solution. 2. Run `/corpole:start`. The agent asks what problem you solve, for whom, and within which limits, and records your answers as Drafts. 3. Open CorPole and make the records that are right **Authority**. Only those bind the agent. 4. Ask the agent to break the work into stories. They arrive in the Backlog of the solution's first initiative ("Build …", created with the solution and its charter demand); move the first one to **Ready**. 5. Ask the agent to implement it. It reads the story's work context first and cites the codes it follows. #### Tips > **Tip:** Install the CorPole plugin for Claude Code too: it adds the commands, loads the binding records at session start and shows CorPole's notices in the terminal. ### Your first day in a team solution Source: https://corpole.com/support/getting-started/your-first-day-in-a-team-project · Getting started Connect your agent under your own name, set up your clone, and pick up a Ready story. #### Steps 1. Accept the invitation and check the roles you have on the solution. 2. Connect your agent: sign in with `/mcp`, or create a personal token on the Agents page. It acts as you, with your permissions. 3. Run `/corpole:init` in your clone so Claude Code ranks CorPole above the files in the repository. 4. At session start the agent lists the open initiatives. Tell it which one you work on; it keeps the choice for 12 hours. 5. Ask the agent for the Ready stories and pick one. Check the handover note if another agent worked on it before. 6. In the pull or merge request, cite the record codes the story implements, plus the story code. The check needs at least one record code; the story code alone links the work but does not pass. ### Evaluating CorPole: a 30-minute trial plan Source: https://corpole.com/support/getting-started/evaluating-corpole · Getting started Try the loop that matters: a requirement agreed, a conflict stopped, a change proven. #### Plan 1. **5 min.** Connect Claude Code or claude.ai to a new solution. 2. **10 min.** Run the kickoff interview; approve two or three records as Authority. 3. **5 min.** Ask the agent for something that contradicts an Authority record. It should refuse and propose a change instead. 4. **5 min.** Retire a record and ask the agent about it again: it no longer uses it. 5. **5 min.** Let the agent implement one small story; look at criteria, tests and history. #### What to look for - Does the agent cite record codes? - Is every agent write a proposal that waits for a person? - Can you tell, weeks later, who decided what and why? ### Start a solution without opening the web app Source: https://corpole.com/support/getting-started/start-a-project-from-the-chat · Getting started Tell your agent you want to start a solution; it creates it for you and runs the kickoff interview. #### Steps 1. Connect your agent with a sign-in (OAuth) connection. A token connection cannot switch to a new solution. 2. Say what you want to build. The agent confirms the name and creates the solution in your tenant, with your permissions. 3. The connection moves to the new solution; the kickoff interview starts. 4. The solution comes with a charter demand and a first "Build …" initiative, so work can start at once. 5. Codebase already there? The agent starts onboarding instead, as an "Onboard …" initiative. #### Keep in mind > **Caution:** You need a CorPole account first. Without one, request access on corpole.com. ### How people and agents share the work Source: https://corpole.com/support/getting-started/people-and-agents-share-the-work · Getting started Agents draft, propose, build and report. People decide what binds, what is ready and what is done. #### Who does what | Activity | Agent | Person | | --- | --- | --- | | Demands and initiatives | Records a request as a demand (`assess_request`) | Reviews demands into initiatives, chooses the mode, moves and closes initiatives | | Records | Proposes Drafts and changes | Approves, makes Authority, retires | | Design | Proposes design changes on work; submits onboarding findings as design drafts | Confirms design drafts; design changes apply when the work is Done | | Work | Proposes items into an initiative's Backlog; works on Ready items | Moves items to Ready; verifies; marks Done | | Evidence | Registers tests; reports results | Verifies criteria; overrides reports | | Knowledge | Opens questions; proposes decisions and lessons | Answers; accepts or rejects | | Controls | Never proposes about its own controls | Sets policy, rules, permissions and thresholds | ### Agent activity Source: https://corpole.com/support/connect-your-agent/agent-activity · Connect your agent 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. #### Reading a call - Each line is one call: when, the tool, the result (**OK**, **Refused** or **Error**), the agent, how long it took and the record codes it touched. Open it for the detail. - **Came in** is what the agent sent. **CorPole did** lists what happened inside — records changed, notices sent, drift signals, refusals, masked secrets — each with its time after the call began. A call with nothing there only read. - **Gave back** is the answer the agent received. A REST call's answer is not kept. #### Initiative per agent session At the top, each agent session that chose an initiative with select_initiative in the last 12 hours: the connected app or token, the person behind it, the initiative and when the choice lapses. The person behind a connection — and people who manage the solution's integrations, tenant owners and admins — can **clear** a choice (the agent asks again before its next write) or set another open initiative. The change is written to the solution's history. Viewers and auditors only read it. #### Finding and exporting Filter by tool, agent, result, record code or a start date. The newest 100 matching calls are shown; **Export CSV** gives every matching call. #### What is kept, and who sees it Secrets are masked before anything is stored. The full answer is kept 90 days; after that its beginning and a SHA-256 fingerprint stay, so you can still show what an agent was given. People who manage the solution's integrations, tenant owners, admins and auditors see every call; everyone else sees the calls made for them. Your agent's recent calls also show on **Agents**. ### Agents Source: https://corpole.com/support/connect-your-agent/ai-context-screen · Connect your agent 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. #### What agents receive Agents read the **Authority** records, their acceptance criteria, the constraints and accepted decisions around them and the standards that apply. Approved records are informative; Retired ones never drive new work. Asked about a story, an agent gets its whole context slice (`get_work_context`): the chain up to the objective, criteria to meet, tests, conflicts and recent changes, its initiative and component. It also follows the solution's design records (BDR, FDR, NFDR, TDR, ADR): they say what the solution is today. #### Solution and initiative A connection belongs to one solution; an OAuth connection moves with `switch_solution`. At session start `get_agent_policy` lists the open initiatives. New work and requirements go to the initiative the agent names, else the parent's, else the one chosen for the session (`select_initiative`, 12 hours, kept per session — parallel sessions on one token each have their own), else the only open one besides maintenance; otherwise the agent asks you once. Defects without a parent go to the quarter's maintenance initiative. The Claude Code plugin tells CorPole which repository it works in, so findings and code checks go to that repository's component. #### Ways to connect | Tool | How | | --- | --- | | Claude Code (recommended) | Install the CorPole plugin and sign in with `/mcp` (acts as you, no token). That gives the agent CorPole's tools and the plugin's commands — and no hooks: a sign-in leaves nothing on your computer that a hook could use. The plugin's **hooks** (session context, notices, the code gate, the waiting status) run only with a credential on the computer: create **your personal token** and store it in `~/.config/corpole/token`. | | claude.ai, ChatGPT, Claude Desktop | Add a custom connector with the MCP URL, sign in and pick this solution (or create a new one). No token needed. | | Cursor, VS Code, other MCP clients | Add a remote MCP server with the configuration shown and your personal token. | | Any agent without MCP | Paste the CLAUDE.md / AGENTS.md snippet into the repository. | | Plugin command | Does | | --- | --- | | `/corpole:start` | Creates the solution if needed and starts it with you: it settles what the solution is, then works through its first requirements the way CorPole's setup brief for the solution describes. | | `/corpole:onboard` | Brings an existing codebase in, one repository at a time, as design drafts for people to review. | | `/corpole:handover` | Moves CLAUDE.md rules, documents and ADRs into CorPole as proposals. | | `/corpole:init` | Writes the repository kit (the CorPole block in CLAUDE.md and AGENTS.md, short pointer files for Gemini, Copilot and Cursor, team settings, change-request template and CI check). | | `/corpole:context`, `/corpole:check` | Shows the binding records; checks changes against them. | #### Tokens and connected apps - **Personal tokens:** everyone creates their own, one per machine or tool, with an expiry. An agent using one acts as you: your permissions, and everything it does is recorded under your name. Shown **once**; revoke it any time. - **Service tokens** are for CI (the change-request check, test results). Only people with the Integrations permission create them; they act for their creator. The single solution token of earlier versions is now listed as a service token. - Tick **Allow proposing** to let the agent propose records, changes, work items and tests and report results. - People with the Integrations permission see every token in the solution and can revoke any of them; the owner is notified. Creating and revoking tokens is written to the solution history. - Sign-in connections appear under **Connected apps**; disconnect them there and the next call is refused. - An agent never has more permissions than the person it acts for. - CorPole masks secret-looking values (tokens, keys, passwords, card and national ID numbers) in everything an agent sends, and tells you when it did — rotate the secret if it was real. > **Caution:** Do not share a personal token: whoever holds it acts as you. Never paste it into a chat, a record or a file in the repository; revoke it if it may have leaked. #### Production emergency When production is broken and a fix cannot wait for its requirements, a person allowed to declare an emergency opens a window (default 4 hours) here or through their agent. Everyone in the solution is told. CorPole opens an urgent demand and an urgent initiative for it. The code gates then advise instead of refusing, a critical defect in that initiative tracks it (already Ready, so the agent can start it) and a red **Emergency** label shows in the context row below the top bar. Actions the policy forbids stay forbidden. When it ends, a **Make good** task is opened for the governing requirement and its test, and the requirement owners are asked to complete it. The urgent initiative closes only with a post-incident review: it becomes a proposed lesson, a draft regression test for each missed criterion without a working test, and a runbook. If the fix needs longer, **Extend once** adds hours with a reason, up to 12 hours after the declaration in total. Everyone in the solution is told; the extension is kept in the history. #### Agent health Signs that an agent is going the wrong way, caught before the work piles up. **L1** the agent was told, **L2** you were told, **L3** flagged here for the integration managers, **L4** the server refused. | Signal | When | | --- | --- | | DRF-03 | A change request cites a Retired or Draft record. | | DRF-04 | Repeated refused actions (policy, role, code gate). | | DRF-05 | The same test keeps failing. | | DRF-07 | Work the agent started has no code link for days. | | DRF-08 | The agent is close to the hourly proposal limit. | | DRF-01 | A change request cites no record or work item and has no no-requirement label. | | DRF-10 | The agent wrote before reading the agent policy. | | DRF-11 / DRF-16 | A claim or finding without evidence (refused). | | DRF-13 | The agent keeps trying a status it may not reach. | | DRF-14 | A change request builds on vague wording (fast, easy, user-friendly) nobody asked about. | | DRF-17 | Most onboarding findings of the last 30 days were rejected. | | DRF-18 | The advisory gate warned about ungoverned code 5 times in a week. | | DRF-22 | A lesson or the same kind of drift keeps coming back: make it a rule. | | DRF-23 | Agents were asked, but no lesson or idea came in for 30 days. | | DRF-26 | The agent created work without naming or choosing an initiative, so it fell to the solution's default (flagged from 3 a week). | | DRF-27 | The agent tried to write to an initiative that is already closed. | **Resolve** a signal once it is handled: pick the root cause (agent, requirement, configuration, process or false positive) and note what was done. Tick **Keep it as a lesson** and the note becomes an accepted lesson that agents read in their context. CorPole closes a signal itself when its condition is gone: the test passes, the stalled item moves or gets a code link, the work reaches Done. Stalled work is checked every day, even if nobody opens this page. **Trend** shows the last 30 days by signal, signals per active agent-day and the root causes. Thresholds are set on the Account page and can be overridden per tenant in Settings. #### Agent metrics Ten measures of how agents and people work together over the last 30 days: traceable pull requests, accepted proposals, criteria met the first time, time to answer a question, time agents wait, rework, drift density, the learning loop, agent calls per story and flow time. Each shows its target; it turns green or amber once there is enough data. Label a trivial change request **no-requirement** so it counts as a deliberate exception, not ungoverned code. **Adherence by client and model** shows, whichever client and model your agents use, the share of sessions that read CorPole's context before their first file change, server refusals and drift signals per session, and how many pull requests the CorPole check stopped. The model appears when the client reports it at session start. #### Agent activity **Agents → Activity** keeps every call a coding agent made to CorPole: what it sent, what CorPole did inside — records changed, notices sent, drift signals raised, actions refused, secrets masked — what it gave back and how long it took. Filter by tool, agent, result, record code or date, and export the list as CSV. Secrets are masked before anything is stored. The full answer is kept for 90 days; its beginning and a SHA-256 fingerprint stay, so you can later show what an agent was given. People who manage the solution's integrations, tenant owners, admins and auditors see every call; others see the calls made for them. #### Repositories, repository kit and activity Connect the GitHub or GitLab repositories on **Solution settings → Repositories and CI** so change requests and commits that mention a code link themselves and move stories. The **Repository kit** makes the repository treat CorPole as its requirements authority; its CLAUDE.md block carries a stamp, and the Claude Code plugin tells you at session start when the agent policy or the authority tier changed and the kit should be re-applied (/corpole:init). **Agent activity** lists the last 10 reads and proposals. **Change-request check**: the repository kit's CI job (GitHub Action or GitLab CI include) checks that each pull or merge request cites at least one existing, non-retired **record** code — a story code links the work but does not pass on its own; the **no-requirement** label skips it. It also sends the files the request changes, and CorPole answers: ungoverned code (fails under the enforced gate), a module whose findings are under review, files outside the modules of the cited work, other open change requests changing the same files, and emergency rules. The check's token is a repository secret on GitHub or a masked CI/CD variable on GitLab; CorPole needs no GitHub or GitLab credentials. Re-apply the repository kit to get it. ### Connect Claude Code Source: https://corpole.com/support/connect-your-agent/connect-claude-code · Connect your agent Add the MCP server and sign in, or install the plugin for commands, session context and notices. #### MCP only (quickest) 1. `claude mcp add --transport http corpole https://corpole.com/api/mcp` 2. Run `/mcp`, select **corpole**, choose **Authenticate**. 3. Sign in to CorPole and pick the solution (or create one). #### With the plugin (recommended) The plugin adds `/corpole:start`, `/corpole:onboard`, `/corpole:handover`, `/corpole:init`, `/corpole:context`, `/corpole:check` and `/corpole:retro`, loads the binding records at session start and shows CorPole's notices. Then sign in with `/mcp`, or store a personal token in `~/.config/corpole/token`. 1. `/plugin marketplace add Global-Agent-Factory/corpole-platform` 2. `/plugin install corpole@corpole` > **Tip:** Next, run `/corpole:init` in the repository so Claude Code knows CorPole comes first. ### Connect Cursor, VS Code and other MCP clients Source: https://corpole.com/support/connect-your-agent/connect-cursor-and-other-clients · Connect your agent Add a remote MCP server; clients with OAuth need only the URL, others send a personal token. #### Steps 1. Add a remote (Streamable HTTP) MCP server with the URL `https://corpole.com/api/mcp`. 2. If the client supports OAuth, sign in when it asks and pick the solution. 3. Otherwise create a personal token on the solution's Agents page and send it as `Authorization: Bearer …`. #### Keep in mind Clients without hooks rely on the agent calling the tools. Ask it to read the agent policy and the binding records before it writes code. No MCP at all? Paste the CLAUDE.md / AGENTS.md snippet from the Agents page into the repository. ### Connect claude.ai, Claude Desktop or ChatGPT Source: https://corpole.com/support/connect-your-agent/connect-claude-ai-and-desktop · Connect your agent Add CorPole as a custom connector and sign in; no token needed. #### Steps 1. Open the connector settings of your AI app (e.g. Settings → Connectors → Add custom connector). 2. Enter `https://corpole.com/api/mcp`. 3. Sign in to CorPole, pick the solution (or create one) and the permissions, and approve. #### Good for Planning, the kickoff interview, reviewing what binds, drafting requirements and answering questions. Chat apps without access to your code do not change code or report test results. ### Personal tokens, service tokens and sign-in Source: https://corpole.com/support/connect-your-agent/tokens-and-identity · Connect your agent Every agent connection acts for one person and never has more permissions than that person. #### Three ways an agent is identified | Kind | For | Acts as | | --- | --- | --- | | Sign-in (OAuth) | Claude Code via `/mcp`, claude.ai, other OAuth clients | The person who signed in | | Personal token | One machine or tool, with an expiry | Its owner | | Service token | CI: the change-request check and test results | The person with the Integrations permission who created it | #### Rules - A connection belongs to one solution. - Read is always on; **propose** must be granted. - Tokens are shown once and stored only as a hash. - Lowering someone to viewer removes their connection's propose permission; removing them from the tenant ends it. ### Set up your repository with /corpole:init Source: https://corpole.com/support/connect-your-agent/set-up-your-repository · Connect your agent 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. #### What it writes - A **CLAUDE.md** section that ranks Authority records above documents in the repository. - **.claude/settings.json** that offers the plugin to the team and turns the agent policy into permission rules (ask / deny). - Optionally, on **GitHub**, a PR template and a GitHub Action; on **GitLab**, a merge request template and `.gitlab/corpole.yml` to include from `.gitlab-ci.yml`. Both check cited record codes and the changed files, and report test results. #### Steps 1. Run `/corpole:init` in the repository; it reads the `origin` remote to choose GitHub or GitLab. 2. Review the files it shows; it merges with what is there. 3. Commit them. For the check, add `CORPOLE_TOKEN` with a service token: a repository secret on GitHub, a masked CI/CD variable on GitLab (and the `include:` line in `.gitlab-ci.yml`). 4. Connect the repository in **Solution settings → Repositories and CI**, choose the component it belongs to (a monorepo folder can belong to its own component), and add the webhook it shows with that repository's secret. 5. The check keeps **one CorPole comment** on each pull request up to date (GitHub, with the repository's own token). On GitLab, add the optional masked variable `CORPOLE_GITLAB_TOKEN` (a solution access token with the Reporter role and the `api` scope) for the same note on merge requests. ### How the change-request check works Source: https://corpole.com/support/connect-your-agent/github-check · Connect your agent 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. #### What it checks | The change request… | Result | | --- | --- | | cites no record code | Fails, unless it has the label `no-requirement` | | cites only a story or task code | Fails: the work code links the change, but a record code is needed | | cites a code that does not exist | Fails | | cites a **Retired** record | Fails | | cites a **Draft** or **Approved** record | Passes with a warning | | cites only **Authority** records | Passes | #### Set it up 1. Run `/corpole:init` and accept the CI check (GitHub Action or GitLab CI include), or copy it from **Agents → Repository kit**. 2. Create a service token on the solution's Agents page. 3. Add it as `CORPOLE_TOKEN`: a repository secret on GitHub, a masked CI/CD variable on GitLab. #### Why it matters Agents write most of the change requests. The check makes each one say which requirement it serves, and stops work built on a requirement you already retired. ### No MCP? Use the REST endpoint or a CLAUDE.md snippet Source: https://corpole.com/support/connect-your-agent/rest-and-claude-md-fallback · Connect your agent Tools without MCP can still read what binds: fetch it over REST, or paste the snippet into the repository. #### REST Send a personal or service token as a bearer token: - `GET https://corpole.com/api/context?format=markdown` returns the Authority records as Markdown. - Omit `format` for JSON. - Add `mode=all` to include every state, not only Authority. #### CLAUDE.md / AGENTS.md snippet The solution's **Agents** page has a snippet for tools that read instruction files. It is a copy: refresh it when records change, or prefer MCP, which is always current. ### Read-only or propose: what a connection may do Source: https://corpole.com/support/connect-your-agent/read-only-or-propose · Connect your agent Read is always on. Propose lets the agent add Drafts, changes, work items, tests and results — never anything binding. #### Propose allows - Draft records and change proposals - Demands, recorded from a request - Work items into an initiative's Backlog, with the design changes they carry - Onboarding findings, as design drafts - Questions, decisions, relations, lessons and ideas - Test cases, test results and criterion reports - Defects and risks #### Never allowed to an agent - Making anything Authority, confirming a design draft, accepting a decision, moving work to Done or merging - Reviewing demands or moving and closing initiatives - Editing or deleting records - Changing its own policy, rules, permissions or thresholds ### Objectives Source: https://corpole.com/support/records-and-authority/objective · Records & authority A measurable outcome the solution exists to achieve. Objectives explain why everything else matters. #### About objectives A measurable outcome the solution exists to achieve. Objectives explain why everything else matters. Example: "Reduce order-to-delivery time to under 30 minutes within six months." Records say what should change and belong to an initiative; the initiative chosen in the context row below the top bar filters this list (**Show all of the solution** lifts it). What the solution already is lives in its design records under **Design**. #### What you can do here - Search by title, code or statement, and filter by state. Press **Apply** to run the filter. - Switch between **List** (a table) and **Cards** (statements visible at a glance). - The **Acceptance** column shows how many acceptance criteria are verified as met. **No criteria** marks a requirement that still needs them. - Open a record to read or edit it, or add one with **New record**. > **Tip:** Filter by **Retired** to see records that no longer apply; they are hidden in Explorer. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Business Requirements Source: https://corpole.com/support/records-and-authority/business-requirement · Records & authority What the organisation needs from the solution, stated without describing how it is built. #### About business requirements What the organisation needs from the solution, stated without describing how it is built. Example: "The business must keep a single record of every corporate customer." Records say what should change and belong to an initiative; the initiative chosen in the context row below the top bar filters this list (**Show all of the solution** lifts it). What the solution already is lives in its design records under **Design**. #### What you can do here - Search by title, code or statement, and filter by state. Press **Apply** to run the filter. - Switch between **List** (a table) and **Cards** (statements visible at a glance). - The **Acceptance** column shows how many acceptance criteria are verified as met. **No criteria** marks a requirement that still needs them. - Open a record to read or edit it, or add one with **New record**. > **Tip:** Filter by **Retired** to see records that no longer apply; they are hidden in Explorer. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Stakeholder Requirements Source: https://corpole.com/support/records-and-authority/stakeholder-requirement · Records & authority A need of a specific group of people, usually written as a user story. #### About stakeholder requirements A need of a specific group of people, usually written as a user story. Example: "As a sales manager I want to see every deal's status on one board." Records say what should change and belong to an initiative; the initiative chosen in the context row below the top bar filters this list (**Show all of the solution** lifts it). What the solution already is lives in its design records under **Design**. #### What you can do here - Search by title, code or statement, and filter by state. Press **Apply** to run the filter. - Switch between **List** (a table) and **Cards** (statements visible at a glance). - The **Acceptance** column shows how many acceptance criteria are verified as met. **No criteria** marks a requirement that still needs them. - Open a record to read or edit it, or add one with **New record**. > **Tip:** Filter by **Retired** to see records that no longer apply; they are hidden in Explorer. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Functional Requirements Source: https://corpole.com/support/records-and-authority/solution-functional-requirement · Records & authority 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. #### About functional requirements 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. Example: "Dropping a card on another column changes the customer's status." Records say what should change and belong to an initiative; the initiative chosen in the context row below the top bar filters this list (**Show all of the solution** lifts it). What the solution already is lives in its design records under **Design**. #### What you can do here - Search by title, code or statement, and filter by state. Press **Apply** to run the filter. - Switch between **List** (a table) and **Cards** (statements visible at a glance). - The **Acceptance** column shows how many acceptance criteria are verified as met. **No criteria** marks a requirement that still needs them. - Open a record to read or edit it, or add one with **New record**. > **Tip:** Filter by **Retired** to see records that no longer apply; they are hidden in Explorer. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Non-functional Requirements Source: https://corpole.com/support/records-and-authority/solution-non-functional-requirement · Records & authority A quality the system must meet: performance, security, accessibility, reliability. #### About non-functional requirements A quality the system must meet: performance, security, accessibility, reliability. Example: "Lists load in under one second (p95) with 1,000 records." Records say what should change and belong to an initiative; the initiative chosen in the context row below the top bar filters this list (**Show all of the solution** lifts it). What the solution already is lives in its design records under **Design**. #### What you can do here - Search by title, code or statement, and filter by state. Press **Apply** to run the filter. - Switch between **List** (a table) and **Cards** (statements visible at a glance). - The **Acceptance** column shows how many acceptance criteria are verified as met. **No criteria** marks a requirement that still needs them. - Open a record to read or edit it, or add one with **New record**. > **Tip:** Filter by **Retired** to see records that no longer apply; they are hidden in Explorer. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Technical Requirements Source: https://corpole.com/support/records-and-authority/technical-requirement · Records & authority 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. #### About technical requirements 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. Example: "Data is stored in PostgreSQL and accessed through Drizzle ORM." Records say what should change and belong to an initiative; the initiative chosen in the context row below the top bar filters this list (**Show all of the solution** lifts it). What the solution already is lives in its design records under **Design**. #### What you can do here - Search by title, code or statement, and filter by state. Press **Apply** to run the filter. - Switch between **List** (a table) and **Cards** (statements visible at a glance). - The **Acceptance** column shows how many acceptance criteria are verified as met. **No criteria** marks a requirement that still needs them. - Open a record to read or edit it, or add one with **New record**. > **Tip:** Filter by **Retired** to see records that no longer apply; they are hidden in Explorer. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Project Requirements Source: https://corpole.com/support/records-and-authority/project-requirement · Records & authority Something the solution must deliver besides the product itself: deadlines, documents, test suites. #### About project requirements Something the solution must deliver besides the product itself: deadlines, documents, test suites. Example: "The MVP is in production within four weeks." Records say what should change and belong to an initiative; the initiative chosen in the context row below the top bar filters this list (**Show all of the solution** lifts it). What the solution already is lives in its design records under **Design**. #### What you can do here - Search by title, code or statement, and filter by state. Press **Apply** to run the filter. - Switch between **List** (a table) and **Cards** (statements visible at a glance). - The **Acceptance** column shows how many acceptance criteria are verified as met. **No criteria** marks a requirement that still needs them. - Open a record to read or edit it, or add one with **New record**. > **Tip:** Filter by **Retired** to see records that no longer apply; they are hidden in Explorer. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Product Constraints Source: https://corpole.com/support/records-and-authority/product-constraint · Records & authority A limit on what the product may be or do. #### About product constraints A limit on what the product may be or do. Example: "The product contains no AI features." Records say what should change and belong to an initiative; the initiative chosen in the context row below the top bar filters this list (**Show all of the solution** lifts it). What the solution already is lives in its design records under **Design**. #### What you can do here - Search by title, code or statement, and filter by state. Press **Apply** to run the filter. - Switch between **List** (a table) and **Cards** (statements visible at a glance). - The **Acceptance** column shows how many acceptance criteria are verified as met. **No criteria** marks a requirement that still needs them. - Open a record to read or edit it, or add one with **New record**. > **Tip:** Filter by **Retired** to see records that no longer apply; they are hidden in Explorer. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Business Constraints Source: https://corpole.com/support/records-and-authority/business-constraint · Records & authority A commercial, legal or organisational limit. #### About business constraints A commercial, legal or organisational limit. Example: "Customer data is stored only in the EU or Türkiye." Records say what should change and belong to an initiative; the initiative chosen in the context row below the top bar filters this list (**Show all of the solution** lifts it). What the solution already is lives in its design records under **Design**. #### What you can do here - Search by title, code or statement, and filter by state. Press **Apply** to run the filter. - Switch between **List** (a table) and **Cards** (statements visible at a glance). - The **Acceptance** column shows how many acceptance criteria are verified as met. **No criteria** marks a requirement that still needs them. - Open a record to read or edit it, or add one with **New record**. > **Tip:** Filter by **Retired** to see records that no longer apply; they are hidden in Explorer. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Project Constraints Source: https://corpole.com/support/records-and-authority/project-constraint · Records & authority A limit on how the solution is run: team, budget, tooling, time. #### About project constraints A limit on how the solution is run: team, budget, tooling, time. Example: "Infrastructure costs stay under 50 USD per month." Records say what should change and belong to an initiative; the initiative chosen in the context row below the top bar filters this list (**Show all of the solution** lifts it). What the solution already is lives in its design records under **Design**. #### What you can do here - Search by title, code or statement, and filter by state. Press **Apply** to run the filter. - Switch between **List** (a table) and **Cards** (statements visible at a glance). - The **Acceptance** column shows how many acceptance criteria are verified as met. **No criteria** marks a requirement that still needs them. - Open a record to read or edit it, or add one with **New record**. > **Tip:** Filter by **Retired** to see records that no longer apply; they are hidden in Explorer. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Explorer Source: https://corpole.com/support/records-and-authority/explorer · Records & authority 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. #### When to use it - Before a planning or review session, to see the whole requirement set at once. - To spot gaps: an empty column, or objectives with no requirement that serves them. - To check consistency between types, for example a technical requirement that conflicts with a business constraint. #### How it works Columns follow the order Intent → Requirements → Constraints. Each card shows the code, state and statement; open a card to see the full record. Scroll sideways to move between columns. > **Caution:** **Retired** records are hidden here. Open a record type from the menu and filter by state to see them. ### New record Source: https://corpole.com/support/records-and-authority/create-a-record · Records & authority Creates one objective, requirement or constraint in the active solution. #### Where it belongs A record says what should change, so it belongs to an **initiative**: the solution's default one if it is open, otherwise the newest open one, otherwise the quarter's maintenance initiative. What the solution already is — its processes, functions, qualities and technical design — is kept as design records under **Design**, not here. #### Fields | Field | How to fill it | | --- | --- | | **Type** | Which of the ten types the record is. | | **Code** | Optional. Leave empty to generate one like `FR-3A9C1E`, or use your own scheme (`FR-001`). Must be unique in the solution. | | **Title** | A short name, a few words. | | **Statement** | One clear, testable sentence. Say what, not how. | | **Rationale** | Why the record exists. Helps reviewers and agents weigh it. | | **Acceptance criteria** | A list of separate, verifiable conditions (AC1, AC2…). Each one is tracked and verified on its own. Requirements need at least one before they can be **Approved** or **Authority**; for objectives and constraints they are optional. | | **Authority state** | Draft, Approved, Authority or Retired. Start with Draft if it still needs review. | | **Priority, owner, source** | Importance, the accountable person or role, and where it came from (ticket, meeting, document). | #### Writing good records - One requirement per record. Split statements joined with "and". - Avoid vague words such as "fast" or "user friendly"; give a number or a check. - Write one condition per acceptance criterion, ideally as "given …, when …, then …". Two conditions in one row cannot be verified separately. - Do not repeat an existing record. Search the type first. ### Record detail Source: https://corpole.com/support/records-and-authority/record-page · Records & authority Everything about one record: statement, rationale, acceptance criteria, state, priority, owner and source. #### What you can do here - Read the record as an agent would receive it. - Use the details form to change the text, the acceptance criteria drawer to edit criteria, and **Status** to change the state. - If it was proposed by an AI agent, **Proposed by** shows which one. #### When the record changed while its form was open If a record changes its state while you have its form open — someone approves it, the preparation exit makes it binding, it is retired — your save is refused and nothing is written: "… changed its state after you opened this form (it was approved, made binding or retired meanwhile), so nothing was saved. Open the record again and make your change there." The acceptance criteria panel rechecks the current state and your permissions when you submit it. The fields form does not replace the independently edited criteria list. Field and criteria saves keep their required history and guided changes in the same transaction: a failure saves none of that transaction. If a concurrent operation prevents the save, keep your inputs and review the latest record before trying again. #### Functional Requirement workspace A saved Functional Requirement opens as one workspace. Its heading identifies the record and authority state. Context shows every Refines, Constrained by, Governed by and Realized by neighbour; there is no compulsory single parent. Edit context relations moves to the independent relation commands below the record, for people with Relations edit permission. The left working set filters Functional Requirements by text and state and remembers its scroll and return address for you in this solution; an open record outside the filter is still identified. Field and task drafts are never stored in that working set. The details form edits Title, Code, Priority, Owner, Type, Source reference, Rationale and Statement, plus Spec perspective when guidance offers it. State is read only here; use Status above. Origin and its evidence remain read only. Authority changes need a reason. Your roles must permit editing at the current authority state. A browser without protected workspace navigation shows the fields read only. Save changes compares the version opened with the current saved version, including changes to criteria. A conflict keeps your writing. Review saved values, then either use the saved version and discard the draft or explicitly keep your draft against the reviewed version for another manual save. A missing target, refused permission, mismatched response or unconfirmed save keeps the draft and blocks another attempt until reload; the first operation may already have completed. Acceptance criteria opens the existing right drawer with evidence, tests, covering work and defects. The criterion cards follow the drawer surface so their codes, evidence and links remain readable at every light level. Open Acceptance criteria, History or Link code with Enter; Escape closes a clean drawer and returns focus to its opener. If a task has unsaved changes, Escape opens the shared leave decision. Keep editing preserves the draft; Discard and continue drops only the unsaved changes. In History, Tab to the History changes region and use the arrow keys to read wide columns. Edit criterion text and a change reason with Save criteria; rewording resets verification. Each verification form has its own Verification and Evidence fields and Save verification. Change proposals has an independent Decision and optional Note, followed by Save decision. Code links, relation suggestions and conflict resolutions also save independently. Refresh task details rereads the drawer's original target while keeping dirty inputs. Tasks pause while this requirement's fields are saving. Suggest relations asks for candidates, Ask again refreshes them, Accept suggestion stores one after the relationship checks, and Dismiss drops a candidate without linking it. Reading a task does not grant permission to edit it: record editing, Criteria verify, Relations edit and Work edit remain separate. Adopting reviewed saved field values replaces only the field draft; independent relation and task edits stay in place. Pin task keeps the drawer on that requirement while you read another. A dirty or saving task holds its original target. Closing or following another target asks about its changes; Keep editing preserves them, Discard and continue drops only the selected drafts, and Save and continue proceeds only when all selected saves are confirmed. History shows changes; Impact shows what a change reaches. Resolve asks how a conflict was settled and optionally names its decision, in the drawer. Leaving by a peer, Back, another page or solution switch uses the same decision for all affected fields and tasks. Separate saves can partly succeed: confirmed tasks remain saved while a failed field or task keeps its draft and stops navigation. Type can move the record to another type's existing screen. Save or discard open tasks first; a criterion save can require a fresh field review. Only after a confirmed Type change and settled tasks does the workspace follow the saved record's new address. If another task stops that step, Open saved record makes another guarded attempt after you resolve it. New Functional Requirement keeps its existing create and return flow. If a staged relation fails after creation, the saved record still opens once and Previous action shows what failed. Use Add relation to repair that edge instead of creating the record again. Warnings carried by an older record address remain visible on the saved page. **Kept changes in this tab.** Some browsers, such as Safari on iPhone, cannot ask before their own Back or Forward gesture changes the page. There the requirement says so under its heading and keeps every unsaved field and eligible task change in this browser tab as you type, for this person, tenant, solution and record only. Links, peers, panels, solution switches and Sign out still ask Keep editing, Save and continue or Discard and continue first. After a native Back or Forward, return to the requirement in the same tab: the kept changes come back with **Restored unsaved changes kept in this tab** and remain unsaved. Nothing is stored or sent until you choose Save. Saving checks the changes against the version you first opened; if someone saved a newer version meanwhile, you review both before deciding, exactly as for any conflict. **Discard kept changes** removes them. Kept changes expire eight hours after your last change and are removed the next time the page looks. Signing out removes every change kept in the tab. They are not shared with other tabs or devices, and the browser may remove them earlier, for example in private browsing or when its storage is full. If the tab cannot keep a change, that change is not accepted, earlier kept changes stay, and editing pauses with an explanation. Passwords, sign-in values and one-time results are never kept: **Share outside the team**, which shows a package token once, needs a browser with protected navigation. If a save was sent but its result never arrived, for example because you went Back while it was saving, it may already be stored. Nothing is sent again: on return the page shows your kept changes beside the saved values. Choose **Keep my changes for an explicit save** to save them yourself (a conflict appears if the earlier save went through), or **Discard kept changes**. If your roles no longer allow editing, kept changes are not shown and can only be discarded. #### Change proposals Agents cannot edit records. When you ask an agent to change one, it proposes the change (`propose_change`) and a banner appears here. **Change proposals** shows it as a difference: removed text in red, new text in green, and for acceptance criteria which are new, reworded or removed. - **Accept change** applies it under the same rules as **Edit** (your permission for the record's state; the agent's reason is kept in the history). - A reworded criterion keeps its identity, so the tests linked to it stay linked. - If the record changed after the proposal, it can only be rejected; ask the agent for a new one. - With maker-checker on, the person the agent acted for cannot accept a change to an Authority record. #### Verifying acceptance criteria Each criterion has its own status. **Satisfaction** is the share of criteria verified as met; it shows here, in the record lists, in Explorer and on the Overview. | Status | Meaning | | --- | --- | | **Not verified** | Nobody has checked it yet (also after its wording changed). | | **Met** | Checked and satisfied. | | **Not met** | Checked and not satisfied yet. | 1. Check the criterion, for example by running the test or trying the feature. 2. Optionally write the evidence: a test name, a pull request, a demo. 3. On other record screens press **Mark met** or **Mark not met**; **Reset** returns it to Not verified. In the Functional Requirement workspace choose **Verification**, add **Evidence** if needed, and press **Save verification**. Choosing **Not verified** resets that criterion. > **Tip:** Coding agents with the propose permission can report results too, through `report_acceptance_result`. Their reports show the agent's name, and you can override them here. #### Relations Relations place the record in the traceability chain. Agents use them to receive exactly the context a task needs: the chain above the record, how it is realized, the constraints that apply and any conflicts. | Relation | Use it when | | --- | --- | | **Refines** | This record details a higher one: business → objective, stakeholder → business, functional / non-functional → stakeholder or business. | | **Realizes** | A technical requirement states how a functional or non-functional one is achieved. | | **Constrains** | A constraint limits specific requirements. Constraints without links apply to the whole solution. | | **Replaces** | A newer record takes the place of an older one of the same type (retire the old one). | | **Conflicts with** | The two cannot both hold. Neither can become Authority until the conflict is resolved. | | **Relates to** | Background only. | - Add a relation with the form at the bottom; the lists only offer record types the rules allow. - **Suggest relations with AI** proposes links with a reason; accept or dismiss each one. - Links proposed by coding agents appear as **Proposed**; confirm or reject them. - A confirmed **conflict** is closed with **Resolve**: say how it was resolved and, if a decision settles it, give its code; the decision is linked to both records and the resolution stays in the history. - **Chain** shows acceptance satisfaction of this record together with everything below it. > **Caution:** An Authority record cannot refine or realize a Draft or Retired record, and a record cannot go back to Draft or be Retired while Authority records depend on it. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Edit record Source: https://corpole.com/support/records-and-authority/edit-a-record · Records & authority Changes a record's content or state. The change is visible to AI agents immediately. #### Changing the state - Move a record to **Authority** only when it has been agreed; agents will follow it from the next request. - When a record is replaced or no longer valid, set it to **Retired** instead of deleting it, so the history is kept. #### Acceptance criteria - Add, reorder or remove criteria in the list; they are numbered AC1, AC2… in order. - Changing a criterion's wording resets it to **Not verified**, because the earlier check no longer applies. Reordering keeps the verification. - A requirement cannot be saved as **Approved** or **Authority** without at least one criterion. #### Deleting Only **Draft** records can be deleted, and deletion is permanent. Records that were ever approved should be retired. #### Authority states | State | Meaning | AI agents | | --- | --- | --- | | **Draft** | Work in progress; anyone with edit rights may change it freely. | Shown only on request, never binding | | **Approved** | Reviewed and accepted, but not yet the rule for delivery. | Informative; agents ask before relying on it | | **Authority** | The binding instruction for people and coding agents. | Must be followed and cited | | **Retired** | Kept for history; replaced or no longer valid. | Must not drive new work | ### Solution design Source: https://corpole.com/support/records-and-authority/solution-design · Records & authority 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. #### Kinds - **BDR**: processes and business rules. - **FDR**: capabilities and screen flows. - **NFDR**: quality characteristics in the ISO 25010 set (performance, security, reliability, usability …) and compliance. - **TDR**: per component — modules, interfaces, data, integrations, infrastructure. - **ADR**: architecture decisions and their reasons. #### How a design record changes An epic, story, task or defect carries design changes: add a record, change one or retire one (on the work page, under Design changes; agents use propose_design_delta). When the work is Done each change becomes a new version, with the work, the requirements it implemented and its initiative as the reason. If two open items change the same record, the first to be Done wins and the other's change is marked to be looked at again. Drafts come from delivered requirements and from findings in code, documents or tests; a person with the authorize permission confirms each after checking it describes the solution as it is. A requirement counts as delivered when it is Authority and all the work that implements it is closed with some of it Done; when that work is Done, CorPole draws its draft by itself, and **Draw drafts** catches up the rest. A requirement **realizes** the design records that describe what was built for it: the link is made when the work's design change is applied or a draft is drawn from the requirement, and shows on both pages — **Realized by design records** on the requirement, **Realizes requirements** on the design record. **Design coverage** at the top of the page shows how far the solution is described: the share of confirmed design records, the drafts waiting, delivered requirements without a design record, and code modules without one. In the drafts view, tick drafts and choose **Confirm selected**, or **Confirm all shown**. **Solution document**: the links at the top give the whole description as Word, as a print page (save it as PDF) or as Markdown — components and repositories, every current design record with its acceptance lines and their state, code modules, accepted decisions, standards, the glossary and open solution risks. Drafts are marked as not yet confirmed. The initiative page gives the same for one change: why (demands), requirements with criteria and tests, design changes, work, acceptance testing and what is still open. ### Portfolio board Source: https://corpole.com/support/records-and-authority/portfolio-board · Records & authority 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. #### Columns - **Funnel**: demands not linked to an initiative yet, with how long they have waited. - **Reviewing → Analyzing → Ready → Implementing → Done**: initiatives, coloured by mode (project, small work, urgent), with days in the step, work finished out of total, and the solutions they change. - A column at its WIP limit turns amber; nothing more can move into it except urgent work, whose overrun is written to its history. Tenant owners and admins set the limits under the board. #### Who moves it People with the portfolio permission (Product Owner and Project Lead by default) and tenant owners and admins. Everyone can read it; agents read it with get_portfolio_board and get_initiative but never move it. ### Initiatives Source: https://corpole.com/support/records-and-authority/initiatives · Records & authority 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. #### What belongs to it Its requirements, work, delivery risks (schedule, cost, scope, dependencies, people), decisions about scope and priority, and open questions about the change. Risks about security, availability, compliance or operations, and decisions that bind the solution long term, belong to the solution. Move either way from the risk or decision page. It closes only when all its work is Done or Cancelled and its open risks and questions are closed or moved to the solution. **Delivery** on the initiative page shows the change's own delivery over 90 days, across the solutions it changes: finished work, rework, story cycle time and agent calls per finished story (counting only the calls made in this initiative's sessions). Every step of an initiative or a demand — created, moved, mode changed, closed — also appears in the audit trail of the solutions it changes. **Readiness** on the initiative page lists its closing gates in one place: work closed, every acceptance criterion of its requirements met, no UAT session open, its design changes applied or rejected, no change proposal waiting, risks and questions settled. Each unmet gate names what is missing and who can settle it; open stories that miss the Definition of Ready are shown as advice. The portfolio board shows how many gates an initiative under way meets and the first one missing. #### Modes and steps - **Managed as a project**: Reviewing → Analyzing (lean business case, go/no-go) → Ready → Implementing (MVP, then Persevere) → Done. - **Managed as small work**: Reviewing → Ready → Implementing → Done. - **Managed as urgent work**: straight into Implementing, then Done; it may go over a WIP limit, and the overrun is recorded. - An initiative moves one step at a time, forward or back. **Not pursued** closes it from any open step, with a reason. The mode can change; the change and the reason are written to its history. - While it is open, a portfolio manager can change its **capacity type** and add or take off **solutions** it changes, each with a reason written to its history. A solution it still has work or requirements in cannot be taken off, nor the last one; a maintenance period keeps its solution and stays maintenance. #### Closing and work **Maintenance:** each solution has a maintenance initiative per quarter (small work); defects that are not part of another item go there. When the quarter ends, its open work moves to the next quarter's initiative and the old one closes. **Emergencies:** declaring a production emergency opens an urgent demand and an urgent initiative; the emergency defect and its make-good task belong to it, and it closes only with a **post-incident review** on its page — what happened, why the tests did not catch it, what changes, and a runbook for next time, in the blameless form. The criteria its defects violated are offered as the missed ones. Closing leaves behind, in each solution it touched: a proposed lesson linked to the missed requirements and the defect; a **draft regression test** for every missed criterion that has no working test (make it active once it is written); and the runbook as a **Runbook** reference, which then shows in the context of work on those requirements. An initiative can be Done only when its closing gates are met (see Readiness on its page): every work item Done or Cancelled, its criteria met, its UAT finished, its design changes settled, no change proposal waiting; its demands close when all their initiatives have closed. New top-level work picks its initiative on the New work form; work under a parent follows the parent's initiative. Make default sets the initiative new work of a solution goes to when none is chosen. ### Demands Source: https://corpole.com/support/records-and-authority/demands · Records & authority 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. #### Recording and correcting - When a demand is recorded — on the New demand page or by an agent with assess_request — CorPole names the **open demands that look like it** (the same word-overlap check as for duplicate requirements and defects). If it is the same request, close one as not pursued or link both to one initiative. - A demand recorded later keeps the day it **came in**: on the form, or received_at for an agent. Waiting and flow time count from that day; a date in the future is refused. - The person who recorded a demand, or someone who manages the portfolio, can **edit** its title, request text, requester, channel and received date while it is open. Each change is written to its steps and the change history. - **Assess again** against the solution chosen at the top: the assessment against that solution is replaced, the latest one against each other solution is kept below it, and the reassessment is written to the steps. Viewers and auditors cannot assess again. - A demand linked to the wrong initiative can be taken off it with a reason (portfolio managers, on the demand or the initiative page). A demand left without an initiative goes back to Reviewing. The only demand of an initiative in Ready or Implementing stays while the demand gate is enforced: link the right one first. #### Decision packages - At four decision points — **accepting a demand**, **choosing the mode**, a **re-decision** and **closing an initiative** — CorPole shows a decision package: every option with its expected net value, cost range and risk, the evidence for and against, similar closed initiatives, the recommended option with its confidence, and what would change the recommendation. - The basis is stated: expected net value first, then how bad the pessimistic case is, then delay. Tenant objectives and weights are not configurable yet. - Choosing another option is allowed and never scored; CorPole only asks for a reason in a sentence. The decision, the package it was made on and the reason are kept under **Decisions** on the demand and initiative pages. - For **high-risk** decisions (a solution, or a pessimistic cost of 1,000,000 or more) the package stays folded so you form your own view first; you can note that view with the decision. - Agents read the same package with get_decision_package and talk it through; people decide. #### Value case - A demand carries a **value case**: the hypothesis, and an assessment of benefit, cost and time as **optimistic / expected / pessimistic** ranges, with confidence and evidence. An initiative without a demand can have its own. - Each revision is **added**, never overwritten; the **first intent** (first hypothesis and first assessment) stays visible, so you can tell learning from a drift in intent. A narrowing cost range is shown as the work learns. - Agents propose revisions from evidence (propose_value_assessment); a person who manages the portfolio accepts or rejects them. get_value_case reads the case. - **Re-decision thresholds** are written when the demand is accepted: cost goes above an amount (default: the pessimistic cost), a leading indicator falls below a value (readings entered by hand), a time window closes, work touches a solution the initiative did not commit to, or the hypothesis changes. - A crossed threshold opens a **re-decision**: continue, pivot or stop, with a reason. Stopping is a decision taken in advance, not a confession. - Mode defaults: a **project** needs an accepted assessment and a threshold before Ready, and an open re-decision holds its next step; for **small work** it is a warning; **urgent work** has none (the post-incident review covers it). #### After live: outcome reviews - A value case does not end with Done. When its initiatives are closed and at least one is Done, the case goes **live** and outcome reviews are scheduled — by default on days 30, 90 and 180 (Tenant settings → Outcome reviews changes the days). - When a review is due, the case's owner gets a notice. The review keeps the expected benefit and cost of the moment and the **realized** ones you enter; when the benefit cannot be measured yet, say why in the note. - Each review leads to one of: **close the case** (later reviews are dropped), **start a new demand**, or **propose a rollback** — both open a demand in the Funnel with the numbers and your note. - A case whose initiatives were all not pursued closes without reviews. #### Recording a demand - **New demand**: who asked, the channel (e-mail, meeting, ticket…), when it came in, and the request as it came. Each ask in it is assessed against the open solution — new, already there, partly there, retired before or in conflict — and the result is kept on the demand. - Your agent records one with assess_request (it asks who it came from); list_demands and get_demand read them; track_requests shows everything that came from one person or unit. - Any member may record a demand; viewers and auditors cannot. Agents record demands only in the Funnel. #### The steps Funnel → Reviewing → (Analyzing) → Ready → Implementing → Done, or Not pursued with a reason. The list shows how many days a demand has been in its step; a demand waiting in the Funnel or Ready for more than a week is marked. People with the portfolio permission link a demand to one or more initiatives in Reviewing and choose each initiative's mode (see Portfolio board). ### Assess a request Source: https://corpole.com/support/records-and-authority/assess-a-request · Records & authority 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. #### Reading the result - **New**: nothing like it is written down; if you want it, write a Draft record with acceptance criteria, then the work. - **Already there**: a requirement covers it. If it was built, a complaint is a defect and a wish to have it different is a change to delivered scope. - **Partly there**: close to a requirement but not the same: extend it, or write a new one. - **May conflict**: the same subject with a different number or limit ("4 hours" against "one business hour"). Do not build it as asked; change the requirement through a proposal or record the open point. - **Retired before**: it was written once and dropped; find out why before bringing it back. #### What it does not do It writes nothing and compares by shared words, so a request in other words than the requirement may show as new: check the related list. Your agent does the same with assess_request and proposes records, changes or work only with your yes. ### Changes Source: https://corpole.com/support/records-and-authority/change-history · Records & authority 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. #### What is recorded - Who: a person, an AI agent, an integration (GitHub, GitLab) or CI. - What: the item, the action and each changed field with its old and new value; acceptance criteria show the lines removed and added. - Why: changing an **Authority** record requires a reason, kept with the change. Other edits can carry one too. **Bulk change proposals**: when one decision or one change in a regulation reaches many records, an agent proposes the change to all of them with one reason (propose_bulk_change). The batch page (Changes → the CHB-… code) shows every difference; accept or reject them together, or open a record to decide it alone. Each change is accepted under its record's own rules, so a person may be able to decide only some of them; a record changed since the proposal can only be rejected. **Redact** (workspace owners and admins): if a password or personal data was written into a record, correcting the record leaves the old value in the history. Redact replaces that value with [redacted]; the redaction and its reason are kept in the history. #### Where to see it Each record, work item, knowledge item and test case has a **History** section. This page shows the whole solution, filtered by period, kind, who and code. Coding agents call **get_changes** at the start of a session to see what changed since their last check, and get_work_context lists recent changes to the item and its requirements. Automation can read GET /api/changes with a solution token. ### Write a requirement an agent can follow Source: https://corpole.com/support/records-and-authority/write-a-requirement-an-agent-can-follow · Records & authority One testable statement, the reason in plain words, and criteria that a test can check. #### Checklist - **Who** is it for, and **why** does it matter (the objective it serves)? - **How much**: can it be measured? "Fast" is not a requirement; "under one second for 95% of loads" is. - **How will we know**: at least one acceptance criterion (required before Approved or Authority). - **What it is not**: say what is out of scope. #### Requirement or design? A requirement says what should change and belongs to an initiative. What the solution already does is its design (FDR, NFDR, TDR, BDR, ADR); the work that implements the requirement carries the design change, applied when the work is Done. #### Example | Weak | Strong | | --- | --- | | The app should be fast. | Lists load in under one second (p95) with 1,000 records. | | Users can manage bookings. | A patient can move an appointment up to 2 hours before it starts. | ### Review an AI proposal Source: https://corpole.com/support/records-and-authority/review-an-ai-proposal · Records & authority Agent proposals are Drafts with an AI proposal badge. Nothing binds until a person makes it Authority; Approve marks it reviewed. #### Steps 1. Open the proposal from the Overview's review table. 2. Check it does not duplicate or contradict an Authority record. 3. Sharpen the wording; add criteria, priority and owner. 4. Approve or make it Authority, or delete the Draft. #### Keep in mind > **Tip:** Rejecting is fine. A clear reason helps the agent propose better next time. Findings from existing code, documents or tests are not reviewed here: they are design drafts on the onboarding review page (Confirm as the design, Wrong behaviour → defect, Reject). ### Accept or reject a change proposal Source: https://corpole.com/support/records-and-authority/accept-or-reject-a-change-proposal · Records & authority Agents cannot edit records. A change arrives as a difference you accept or reject on the record page. #### Steps 1. Open the record; the proposal shows the current and proposed text side by side, with the agent's reason. 2. Accept: the change is applied under the normal edit rules (and a second approver where required), with the reason kept in the history. 3. Reject: the record stays as it is; the agent is told. ### Retire or replace a record Source: https://corpole.com/support/records-and-authority/retire-or-replace-a-record · Records & authority Retiring takes a record out of every agent's context at once. Replace it when something new takes its place. #### Steps 1. Open the record and set it to **Retired**. 2. If a new record supersedes it, link the new one with **replaces** (same type). 3. Check the work that implements it: retired requirements cannot be implemented. #### Keep in mind - A Retired record is not reopened. To bring the idea back, propose a new Draft that replaces it. - Only Draft records can be deleted; everything else is retired, so the history stays. - Retiring a requirement does not change the solution's design. To remove built behaviour, plan work whose design change retires the design record. ### Relations: when to use which Source: https://corpole.com/support/relations-and-conflicts/relations-when-to-use-which · Relations & conflicts Typed links tell an agent why a requirement exists, how it is achieved and what limits it. #### The ones you use most | Relation | Use it when | | --- | --- | | **Refines** | A requirement details another one level up the why-chain (objective ← business ← stakeholder ← functional / non-functional). | | **Realizes** | A technical requirement says how a functional or non-functional one is achieved. | | **Constrains** | A constraint limits specific requirements. Without it, the constraint applies solution-wide. | | **Replaces** | A new record supersedes an old one of the same type. | | **Conflicts with** | Two records cannot both hold. An open conflict blocks Authority. | ### Why a record cannot become Authority Source: https://corpole.com/support/relations-and-conflicts/why-a-record-cannot-become-authority · Relations & conflicts Two rules block it: a requirement without acceptance criteria, and an open conflict. #### Check 1. **Criteria.** Business, stakeholder, functional, non-functional, technical and project requirements need at least one acceptance criterion before Approved or Authority. 2. **Conflicts.** An open *conflicts with* relation stops both records. Resolve it: retire one, change one, or remove the relation. ### Two binding records disagree Source: https://corpole.com/support/relations-and-conflicts/two-records-disagree · Relations & conflicts The agent stops and shows both codes. It does not pick a winner; a person does. #### What happens When the agent finds two records that cannot both hold, or a request that contradicts Authority, it names both codes, proposes a *conflicts with* relation and asks. #### What you do 1. Open both records. 2. Decide which holds; retire or change the other. 3. Remove the conflict relation once it is settled. #### Why this matters A pull request that cites a record in a confirmed conflict raises a drift signal, so a conflict cannot slip through the merge. ### Forecast Source: https://corpole.com/support/work-and-boards/forecast · Work & boards 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. #### How the dates are made CorPole counts the stories, tasks, defects and subtasks finished in each of the last eight weeks and plays 2,000 possible futures from that pace. The **50%** date is as likely to be early as late; the **85%** date is the safer promise. Each item counts as one, so splitting large items makes the forecast sharper. #### Using it - **Scope**: the initiative chosen in the context row below the top bar limits the remaining work to that initiative (the pace stays the team's); a theme, epic, work package or story code limits it to that item and everything under it; the target defaults to its due date. - **What if this goes first**: how soon one item (and what is under it) could be done if the team took it next; the overall end date stays the same. - **What slows it down**: blocked items, open questions, items running longer than the usual flow time, items waiting for review or verification, items not refined yet, items past due. - **Plan versus actual**: finished items compared with their due dates. CorPole holds no hour estimates; give work items due dates to compare. - Your agent answers the same with get_forecast, e.g. "when will phase 1 be done?". ### Flow Source: https://corpole.com/support/work-and-boards/flow-metrics · Work & boards 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. #### The measures - **Flow time**: from a demand's arrival to done, and from an initiative's start to done — the median and the time 85% finish within. - **Flow efficiency**: the share of that time in working steps (Reviewing, Analyzing, Implementing); the Funnel and Ready are waiting. - **Flow load**: initiatives in each step now, against the WIP limits. - **Flow distribution**: finished stories, tasks, defects and subtasks by the capacity type of their initiative (feature, enabler, maintenance, compliance). Tenant admins can set a **target share** per type under Portfolio → Capacity targets; a share more than 15 points off target (with at least 10 items finished in 90 days) is marked, and the people who manage the portfolio are told once a week. - **Flow velocity**: work items, initiatives and demands finished per week. - **Where work waits**: the median stay in each step, the longest waiting step, and what waits longest now. The quarterly maintenance initiatives are capacity, not flow: they are left out of the times, but their work counts in distribution and velocity. Each demand and initiative page shows its own timeline. Story cycle time (Ready → Done) is on the Metrics of a solution. ### Planning check Source: https://corpole.com/support/work-and-boards/planning-check · Work & boards 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. #### What is checked - Candidates are stories, tasks, defects and subtasks in Backlog, Idea or Analysis — in the initiative chosen in the context row below the top bar (or the whole solution), under one epic, work package or theme, or exactly the codes you name. - Stories need the Definition of Ready: a binding requirement they implement and at least one criterion they cover. Defects need triage (a severity). Every item needs a description, no open block, its dependencies done and no open question about it. Under the demand gate its initiative must also answer a demand. - **Load** shows, per owner and per agent, the active and Ready items they already carry, so new work goes to someone with room. #### Then Fix what is missing, then move the items to Ready yourself — agents never make work Ready. With an enforced Ready gate an item that fails cannot be moved; with an advisory one it moves with a warning. Your agent prepares the list with check_planning. ### Work Source: https://corpole.com/support/work-and-boards/work-items · Work & boards 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. #### Reading the detail screen Open a work item to read its fields, where it belongs, its workflow and related records. The list beside it opens another item; filtering the list does not change the item already open. On a narrow screen the list moves above the details. A soft edge on scrollable content indicates that more lies beyond that edge. It clears as you reach the boundary; keyboard focus stays readable. Scroll inside a list, table or panel to reach its remaining content. The edge is a reading aid and does not change your permissions or save your edits. #### Saving work fields Editing work requires Work edit permission in the active solution. Save validates the fields and placement before writing them. The field change and its history entry are stored together; if either fails, neither is saved. If the item changes while a save is being processed, the form keeps your submitted values and asks you to review the latest version. Check the message before trying again. Other work types retain this legacy form behavior. A saved Story uses the protected workspace described below and compares the revision loaded when it was opened. #### The Story workspace A saved Story shows its code and title once at the top, followed by the existing view switch and actions. The Stories working set sits beside the details, or behind **Show records** when the available width is narrow. Find a record and Status filter only this working set; they do not change the open Story. Its current marker, a notice when the current Story is outside the results, and Back to list keep that context visible. Filters and scroll are remembered for this person and solution in this browser session when storage is available; field drafts are not stored there. **Placement** shows Initiative, Epic and Work package as separate roles. Editors may change the allowed selections together with the Story fields; a Story under a parent or package inherits its initiative. Open links read those related records through the same protected navigation. A selected target that is no longer available stays visible as unavailable rather than silently clearing it. **Story details** retains title, code, read-only status, priority, owner, dates, external reference and description, plus the existing health summary. Status changes remain separate in Status at the top. Workflow, next gate, Activity, handover, Implementation and related records follow in their existing order. History opens in the shared right panel. **Save changes** saves fields and placement together, without navigating away. Unsaved changes, Saving and Changes saved report the result. The server rechecks permission and compares the opening revision. If another person or agent has changed the Story, the save is refused and your draft stays visible. **Review saved values** shows the current saved fields; **Use saved version and discard draft** explicitly replaces your draft with that version. You may then edit and save again. A field-validation refusal keeps the fields for correction. If a save response is lost or editing permission is refused, the draft stays visible and another save is blocked until you reload. **Reload saved Story and discard draft** loads the saved record and abandons this draft; the browser may also ask before reloading. Story tasks described below have independent save boundaries. Other page commands that submit a separate form ask about dirty Story fields and registered task drafts first. Saving fields does not save a relation, a status change, sharing, a code link or a proposal as part of the same transaction. A viewer may read the Story and use its working set and History but cannot edit its fields. Browsers without protected history navigation show the fields read only. #### Leaving an editable workspace On a saved Story, leaving edited fields, placement or registered task drafts asks one question naming the affected drafts. Keep editing stays on the current item. Save and continue proceeds only after every affected save succeeds. Independent saves can partly succeed: saved fields remain saved while a failed task stays open with its own draft and error. A refusal or conflict keeps the remaining draft open. Discard and continue abandons those local changes and opens the requested destination. If an independent task has updated the saved Story, discarding older field edits keeps that completed task. Reviewing and adopting saved field values does not erase independent relation or task drafts. A save response for another request, target or revision is unconfirmed: your draft stays visible, field editing and another submission are blocked, and Save and continue cannot replay it. Reload the saved Story and review what actually reached storage before deciding on a new edit. While a save is still pending, leaving stays blocked. Screen links, Go to, search destinations, browser Back and Forward, scope changes and sign-out use this decision. A section anchor stays within the current item. A quick look opens its preview beside the item and keeps the current draft without asking to leave. Reloading or closing the page uses the browser's own limited warning. Workspace editing works in two ways. Where the browser can ask before any same-page change (protected navigation), every exit, including Back and Forward, asks first. Where it cannot, for example Safari on iPhone, editing uses kept changes in this tab (see below). Where the browser can do neither, editing is read-only and normal navigation remains available. Saved Story detail screens use this workspace. Creating a Story uses its own panel (see Creating a story); editing other work types retains its existing form. Story relation, code, design proposal and sharing tasks join the same leave decision with their own save actions and permissions. Under protected navigation, task drafts stay in memory for their target lifetime and are not recovered after a reload. **Kept changes in this tab.** Some browsers, such as Safari on iPhone, cannot ask before their own Back or Forward gesture changes the page. There the Story says so under its heading and keeps every unsaved field and eligible task change in this browser tab as you type, for this person, tenant, solution and record only. Links, peers, panels, solution switches and Sign out still ask Keep editing, Save and continue or Discard and continue first. After a native Back or Forward, return to the Story in the same tab: the kept changes come back with **Restored unsaved changes kept in this tab** and remain unsaved. Nothing is stored or sent until you choose Save. Saving checks the changes against the version you first opened; if someone saved a newer version meanwhile, you review both before deciding, exactly as for any conflict. **Discard kept changes** removes them. Kept changes expire eight hours after your last change and are removed the next time the page looks. Signing out removes every change kept in the tab. They are not shared with other tabs or devices, and the browser may remove them earlier, for example in private browsing or when its storage is full. If the tab cannot keep a change, that change is not accepted, earlier kept changes stay, and editing pauses with an explanation. Passwords, sign-in values and one-time results are never kept: **Share outside the team**, which shows a package token once, needs a browser with protected navigation. If a save was sent but its result never arrived, for example because you went Back while it was saving, it may already be stored. Nothing is sent again: on return the page shows your kept changes beside the saved values. Choose **Keep my changes for an explicit save** to save them yourself (a conflict appears if the earlier save went through), or **Discard kept changes**. If your roles no longer allow editing, kept changes are not shown and can only be discarded. #### Creating a story **New story** at the top of the Stories screen, on its Overview, Board and Table and on a saved Story, opens the **New story** panel beside the page; it does not leave the page you are on. It needs Work edit permission in the active solution. The panel holds **Title** (required), **Description**, **Placement** (Initiative, Epic and Work package), **Details** (Priority, Owner, Code, Start date, Due date, External key and External link) and **Related items**. A new story starts in Backlog; change its status on the Story afterwards. A story under an epic or in a work package takes its initiative from there, so Initiative is then not chosen here. Leave Code empty for an automatic one. **Related items** offers the valid relations of layers 1 and 2 with their direction and target. **Add to draft** lists the choice under the fields; **Remove** takes it off. They are linked when the story is created. Decisions, standards, references, risks and questions are linked from their own records. **Create story** checks the fields and placement and creates the story in the solution where you started the draft; the panel then closes and the new Story opens. A field problem keeps your input with the message. If the active solution changed after you started, nothing is created: switch back or discard the draft. If the answer is lost or does not match the request, the story may already exist: the form stays as it was, nothing is sent again, and **Close and check the list** opens the Stories table so you can look before creating it again. The draft lives in the panel while you move between pages and comes back when you open the panel again; it is not stored on this device and a reload or a closed tab loses it. Closing the panel or **Cancel** with unsaved input asks first: **Keep editing** stays, discarding closes it. On a phone the panel opens as a sheet from the bottom. **+ Story** on an epic or a work package, and older links to the create page, open the Stories list with this panel, the epic or work package already chosen. #### Story panels and independent tasks **History**, **Link code**, **Propose change** and **Share outside the team** open in the existing shared panel area. The panel heading and **Task target** identify the Story it will read or change. A clean panel follows the Story subject. **Pin task** keeps that target while you read a neighbour; an edited or pending task also holds its own target. **Follow current Story** returns to the current Story through the same leave decision. Back shows the earlier panel. Closing, changing panel layout or opening beyond panel capacity asks about any affected task drafts, including hidden panels. A pending task blocks those exits until its response arrives. **Link code** accepts a code URL, detected or selected kind and optional title. **Propose a design change** accepts add, change or retire, an existing design record when needed, kind, subtype, title, description, acceptance and note. The proposal applies when the Story is Done. These actions require Work edit permission; proposing also requires an open Story. Each task saves independently of Story fields and reports Unsaved task, Saving task or Task saved. Validation keeps your inputs. A lost or mismatched response, a missing target or refused permission keeps the draft and blocks another attempt until reload, because the first operation may already have completed. **Add related item** lists allowed relation-and-target choices, with direction, relation name and record code; its optional note is saved on the link. Its explanation, named task target, fields and save action sit inside the section body with the shared spacing. The explanation stays below the heading so the heading has room on narrow screens. Related cards show their saved relation note below the record details, together with their evidence and direction. An incoming work relation can also preview its source. History filters stay inside the panel; on narrow screens, focus the History changes region and scroll horizontally to read all three columns. Open History with Enter and close it with Escape to return focus to its opener. If an editable panel has unsaved changes, Escape opens the same Keep editing or Discard and continue decision as its close action. **Preview** opens a quick look of a selected requirement or work item without replacing the Story subject. **Unlink relation** removes only that scoped link, never its target record. Adding a child continues through the normal creation screen and guarded navigation; the workspace does not automatically retry child creation. Relation changes require Work edit permission. **Share outside the team** requires Integrations permission. Choose recipient, masked brief or package token, expiry, extra masked terms and note. No message is sent. If task details cannot be refreshed after saving, the draft and receipt stay in place; **Refresh task details** retries only that read. A successful share shows its code and a brief download; a package token is shown once. Copy and review it before choosing **Done with this receipt**. Until then, leaving treats the receipt as unfinished work; Save and continue cannot create another share to recover that token. Discard explicitly abandons the receipt. Existing shares show recipient, mode and expiry; **End share** revokes that share. If the response is lost, reload and review existing shares before deciding on a new share. #### Sharing a package outside the team On an epic, story or task, **Share outside the team** (Integrations permission) hands the package — the item and everything below it — to a subcontractor or an outside team until an end date. A **masked brief** is a Markdown document: what to do, the requirements and acceptance criteria with their tests, how the work is checked, constraints, standards and the agent policy. The client's name, the solution's name, the people of the workspace, e-mail addresses, phone numbers, secrets and the words you add are replaced. Check it before you send it. A **package token** lets their coding agent connect: it sees only get_package_brief, get_agent_policy, update_work_status, link_code, report_test_result, report_acceptance_result and ask_question, and only for the package's items, criteria and tests; everything it reads is masked, it gets none of your notices, every REST endpoint refuses it, and it cannot move work to Done — a person here accepts the work on its evidence. End the share to stop the token at once. #### Initiative and demand - Every work item belongs to an **initiative**. Top-level work picks it on the New work form (or goes to the solution's default); work under a parent follows the parent's, and moving it under another parent moves it and everything below it. Defects without a parent go to the quarter's **maintenance** initiative. - **No work without a demand**: under the tenant's demand gate, work is committed — to Ready, or straight to In progress — only when its initiative answers a demand. - The initiative chosen in the context row below the top bar filters this list; choose **All open** there to see every open initiative. **Solution → Tests → Known defects** lists the solution's open defects whichever initiative fixes them. #### The two axes | Axis | Items | Rule | | --- | --- | --- | | **Value tree** | Theme → Epic → Story or Task → Subtask | One parent each, one level up; stories and tasks are peers and both can have subtasks | | **Delivery container** | Work Package | Epics, stories and tasks are *planned in* one package; packages carry owner, dates and budget and can nest | #### Story or task? | Type | Use it for | Examples | | --- | --- | --- | | **Story** | Any work that involves development (code changes) | A new screen, an API change, a migration script, an integration | | **Task** | Work without development | Configuring a system, granting access, updating records, a data correction, writing documentation | Both sit under an epic and both can have subtasks. Coding agents work on stories; if a task turns out to need code, create a story for that part. #### Linking work to requirements - **Implements**: the requirement the work brings to life (epic → business / stakeholder; story → stakeholder / functional / non-functional / technical; task → functional / non-functional / technical / solution). - **Covers**: the acceptance criteria a story or task must satisfy. Criteria are not copied into work. - **Serves**: the objective a theme or epic contributes to. **Delivers**: the project requirement a work package delivers. - **Constrained by**, **Depends on**, **Conflicts with**, **Relates to** complete the picture. > **Caution:** Retired requirements cannot be implemented. Epics, stories and tasks without a requirement are flagged as scope creep, and work on Draft requirements is flagged too. #### Design changes An epic, story, task or defect can carry **design changes**: add, change or retire a design record (BDR, FDR, NFDR, TDR, ADR) on the work page. They are applied to the solution's design when the work is Done; if two items change the same record, the first Done wins and the other's change must be looked at again. #### Agents on the work - An item an AI agent is working on shows **which agent** and since when; other agents see it and are told not to work on it in parallel. If one writes to it anyway, Agent health raises a signal (DRF-21). - When an agent stops with the item unfinished it leaves a **handover note** — done, open, next step, anything half-done — shown on the item and to the next agent that opens it. #### Status and measures Each type has its own flow: stories Backlog → Ready → In progress → Code review → Verification → Done; tasks Backlog → Awaiting approval → Ready → In progress → Check → Done; epics Idea → Analysis → Ready → In delivery → Done; subtasks To do → Doing → Done. Coding agents may move stories to In progress and Code review and tasks to In progress and Check; approval, verification, check and Done are people's decisions. Themes, epics, packages, stories and tasks show two measures: **delivery progress** (stories and tasks done, or subtasks inside a single story or task) and **acceptance** (covered criteria verified as met). A large gap means work is reported done faster than it is proven. ### Boards Source: https://corpole.com/support/work-and-boards/kanban-boards · Work & 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. #### Columns | Board | Columns | | --- | --- | | **Stories** (development) | Backlog → Ready → In progress → Code review → Verification → Done | | **Tasks** (no development) | Backlog → Awaiting approval → Ready → In progress → Check → Done | | **Defects** | New → Triage → Ready → In progress → Code review → Verification → Fixed | | **Epics** | Idea → Analysis → Ready → In delivery → Done | | **Requirements** (review) | Draft → Approved → Authority | Subtasks (To do → Doing → Done) are shown inside their story or task card as a checklist; tick them without leaving the board. The initiative chosen in the context row below the top bar filters the boards to its work and requirements; defects belong to the solution and always show. #### The menus above an item On the page of a story, task, defect or epic (and of every other record with the same layout) the buttons on the right of the view tabs are the item's actions. A button with a small arrow, such as **Status**, **Block**, **Add** or **Delete**, opens a small panel under it; only one is open at a time. It closes when you click outside it, press **Escape** (the focus goes back to the button) or move on with **Tab**. **With the keyboard:** open a menu with **Enter** or **Space** on its button, then **Arrow down** and **Arrow up** move through its links and buttons, from the last back to the first; **Home** and **End** jump to the first and the last. Inside a text box, a list or a date of a menu the arrow keys keep their usual meaning. The same holds for your account menu at the right of the top bar; **Escape** closes it and puts the keyboard back on its button. When a page has many views, the row of view tabs scrolls sideways inside itself instead of widening the page. The quieter grey buttons beside the main action are the item's other actions; the main action stays the one filled button. **States and tags.** A state is always written out; its dot and tint repeat it: green for what holds (Authority, Accepted), blue for what is agreed but not yet binding (Approved), amber for what waits for someone (an open proposal), red for what was refused or is locked, grey for a draft. A state that has ended (Retired, Superseded, Rejected knowledge) has a dashed edge. A grey tag without a dot is a fact, not a state: a rule's level or kind. **When there is nothing to show.** A list or screen with nothing in it shows a box with a dashed edge: what belongs here in a sentence and, when you may take it, the first step as a button. **Actions that cannot be taken back ask first.** Removing a member, revoking a token, deleting an item and the like open a small window in the app: it says what is about to happen and what goes with it, and its red button names the outcome ("Revoke", "Delete draft"). The keyboard starts on **Cancel**; **Escape** also leaves, and nothing happens. #### Moving cards - Drag a card to another column, or use **Move to…** on the card (works with the keyboard). - A refused move snaps back with the reason, e.g. a task that needs approval, or a requirement without acceptance criteria. - Owners and admins can **lock** a board: it becomes read only for everyone, without drag and drop. Viewers always see boards read only. #### Signals on the cards - **Blocked** (red) with one of the tenant's block reasons. - **Age**: days in the same column, shown in amber from 5 days. - **WIP limits**: set per column; a column over its limit is highlighted. - **AC met / covered**, subtask progress, the epic and work package, and an **AI** badge when an agent moved the card last. - **AI proposal**: an agent proposed this item (`propose_work_items`). It stays in the Backlog (an epic in Idea) until a person moves it on. #### Agents and Ready An agent starts work only once a person has moved it to **Ready** — including items the agent proposed itself. Moving work to Ready is how you release it to agents. Under the demand gate the move is allowed only when the item's initiative answers a demand. ### Themes, epics, stories, tasks and work packages Source: https://corpole.com/support/work-and-boards/value-tree-and-work-packages · Work & boards Every item belongs to an initiative. Within it, a value tree says what you build and work packages say when and by whom. #### Initiative The initiative is why the work is done: it answers one or more demands. A child item shares its parent's initiative; giving an item a new parent moves its subtree with it. Defects without a parent go to the solution's quarterly maintenance initiative. #### Value tree Theme → Epic → Story or Task → Subtask. One parent each, one level up. Stories and tasks are peers under an epic; both can have subtasks. #### Work packages Delivery containers: epics, stories and tasks are planned in one package; packages carry owner, dates and budget and can nest. #### Linking to requirements - **Implements**: the requirement the work brings to life. - **Covers**: the acceptance criteria a story or task must satisfy. - **Serves**: the objective a theme or epic contributes to. - **Design changes**: the design records the item adds, changes or retires; applied when it is Done. ### Story or task? Source: https://corpole.com/support/work-and-boards/story-or-task · Work & boards A story involves development. A task does not. #### Rule of thumb | Type | Use it for | Examples | | --- | --- | --- | | **Story** | Code changes | A screen, an API change, a migration script, an integration | | **Task** | Work without development | Configuration, access, a data correction, documentation | #### Keep in mind Coding agents work on stories. If a task turns out to need code, create a story for that part. Tasks can require approval and a check by a second person. ### Who may move a card Source: https://corpole.com/support/work-and-boards/who-may-move-a-card · Work & boards Agents move work into progress and review. Ready, verification and Done belong to people. #### Stories | Column | Moved by | | --- | --- | | Backlog → Ready | A person (this releases the work to agents) | | In progress, Code review | An agent or a person | | Verification, Done | A person | #### Gates - **Definition of Ready**: the story implements an Authority requirement and covers at least one criterion. - **No work without a demand**: moving an item to Ready, or straight to In progress, needs its initiative to answer a demand. Enforced (default), advisory or off. - **Done**: every covered criterion is Met, confirmed by a person or a passing test. - Each gate is Advisory (warns) or Enforced (refuses), per tenant. ### Break a requirement into stories with your agent Source: https://corpole.com/support/work-and-boards/break-a-requirement-into-stories · Work & boards The agent proposes epics, stories and tasks with their links; you pick what to release. #### Steps 1. Ask the agent to break a requirement or epic into work. 2. It proposes items with the requirements they implement, the criteria they cover and the design changes they carry; they land in the Backlog with an AI badge. 3. Items go to the initiative you name, else the parent's, else the session's choice, else the only open initiative. With several open and no choice, the agent asks you once. 4. Review them on the board; edit, delete or keep. 5. Move the ones you want done to **Ready**. Under the demand gate, their initiative must answer a demand. #### Keep in mind The agent is told which linked records are not binding yet and which criteria no work covers, so gaps show before work starts. ### Implement a story with your agent, end to end Source: https://corpole.com/support/work-and-boards/implement-a-story-end-to-end · Work & boards From a Ready story to Code review, with context, tests and evidence. #### What the agent does 1. Reads the story's work context: why-chain, criteria, constraints, decisions, any handover note. 2. Moves it to In progress. 3. Checks the code area before editing, then implements with tests. 4. Registers the tests against the criteria and reports results. 5. Proposes the design changes the story makes, if it has none yet. 6. Opens a pull or merge request citing the record codes and the story code, and moves the story to Code review. #### What you do - Review the pull or merge request. - Verify criteria or let CI do it. - Move the story to Done. Its design changes then update the solution's design. ### Knowledge Source: https://corpole.com/support/knowledge/knowledge-screen · Knowledge 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. #### Types | Type | Use it for | States | | --- | --- | --- | | **Decision** | A choice with its context, options and consequences. Accepted decisions bind the records and work they govern. An architecture decision that describes how the solution is built is kept as an ADR under Design. | Proposed → Accepted / Rejected → Superseded | | **Question** | Something missing or ambiguous, with the working assumption until a person answers. | Open → Answered | | **Glossary term** | A term of the shared language, its definition, synonyms and words to avoid. | Draft → Active → Retired | | **Standard** | A rule for how work is done: coding, security, testing, compliance (BDDK, KVKK), Definition of Ready or Done. Must or should. | Draft → Active → Retired | | **Reference** | A link to an API contract, event schema, data dictionary, design or document that specifies records or work. | Active → Retired | | **Lesson** | Something learned the hard way in this solution and what to do instead. Accepted lessons are given to agents; a lesson can be promoted to a solution agent rule. | Proposed → Accepted / Rejected → Retired | | **Improvement idea** | A way to cut development cost, speed up delivery or improve performance or quality. It can become an epic, story or task. | Proposed → Accepted / Rejected → Retired | #### How a decision was confirmed A decision's page shows one line under its title that says on whose word the decision stands. It is read only; nobody types it. | Line | What it means | | --- | --- | | **Confirmed on the screen by** (name) **on** (date) | A person set the decision to Accepted in CorPole: on **Waiting for you** (**Approve**) or with the status menu of this page. Needs the permission to decide on knowledge. This is the only line that proves a signed-in person. | | **Confirmed in the client by** (name) **on** (date) | An agent passed the decision on, and its exact content was confirmed in a question the person's AI client showed. A changed wording is asked again; an earlier yes does not count for it. It proves the connected client answered, not who sat at it. | | **First confirmed** … **· accepted again** … **by** (name) **on** (date) | The decision was confirmed, reopened and accepted again. Each confirmation is shown with its own way, person and date, taken from the decision's history; the second person is never shown with the first one's way of confirming. | | **Not in force: first confirmed** …**, then reopened · it waits for a person again** | The decision was confirmed once and then set back to Proposed (or Rejected: "then rejected"). It binds nobody now, whatever was confirmed before. | | **First confirmed in the client (who and when are not on record)** | The history does not hold the first confirmation; CorPole shows the way it was confirmed and names nobody rather than guess. | | **Relayed by the agent — not confirmed by a person · it binds nobody yet** | An agent passed on what a person decided (a decision or a direction) and no person has confirmed it. It is Proposed and binds nobody. In a solution under guided start it waits on its own card on **Waiting for you** (Confirm, Correct, Not mine); elsewhere it waits in the list of **Waiting for you** (Approve, Turn down). You can also choose **Accepted** or **Rejected** with **Status** at the top of this page. | | **Direction · Scope: This solution** | Shown above the line about confirmation when the decision is a direction: a decision that says which way the work goes from now on. The scope says where it holds; today every direction holds in this solution. A direction can be Accepted only by a person, on the screen or in their client; the database refuses anything else. | | **Held: conflicts with direction** DEC-… **· Open its card** | An agent recorded this item and said that it contradicts a direction in force. It waits for a person's choice on its **Conflict** card on **Waiting for you**. The same line is shown on a requirement and on a work item that is held this way. | | **Reasoned exception to direction** DEC-… **—** (name)**,** (date)**:** (reason) | A person chose on the conflict's card that the direction stays in force and this one item stands, and wrote why. The same line is shown on a requirement and on a work item. | | **Open conflict:** … **/ Reasoned exception:** … | On a direction's own page: what waits for a choice against it, and what was allowed as an exception to it, with who, when and the reason. The first five of each are listed; the history has all of them. | | Health cell **Conflicts declared** | On a direction's own page, when the solution is under guided start: how many conflicts agents declared against it, with one short note — "3 answered · too few for a rate" below 5 answered conflicts, "3 of 7 not a conflict (43%)" from 5 on. What became of each (holds, not a conflict, exception, direction changed, withdrawn, open) is in the side panel's first line. **Not a conflict** is the answer that says the agent saw a contradiction where you see none. The rate is that answer's share among the conflicts a person answered; open and withdrawn conflicts are left out, and below 5 answered conflicts no rate is read. From 5 answered conflicts and a rate of 40% on, the cell turns to the attention tone and a notice strip under the page's action row reads "This direction may be worded too broadly: 3 of 7 declared conflicts were not conflicts. Reword the direction so that it says what it rules out, or leave it as it is.", with the button **Show the conflicts**, which opens the side panel (as the cell does; the notice you get leads to this page with the panel already open). Then **reword the direction** so that it says what it rules out (replace it on this page or with **Change the direction** on a conflict's card), or leave it as it is. The person who confirmed the direction gets one notice when this first happens (if they can no longer open the solution, the people who may decide on knowledge in it are told instead); it comes again only after the rate fell below 40% and rose again, and a direction that replaces this one starts from nothing. A direction that is no longer in force keeps its counts and rate, without the attention tone. Select the cell to open **Declared conflicts** in the side panel. The counts and the rate are the direction's and everyone who can open it reads them. The conflicts one by one — what conflicted, the outcome, who answered, which agent declared it and when, linked to its card — are listed, two lines each, for the conflicts your own agents declared (the newest 50); people who see every agent on the Agents pages see them all. A quiet line says how many conflicts of other people's agents are counted but not listed. | | **Recorded by an agent · not confirmed by a person** | An agent recorded the decision as its own, within what it may decide, and no person has confirmed it. A proposed decision with this line binds nobody; choose **Accepted** with **Status** at the top to make it yours, or **Rejected**. | | No line | The decision was recorded before the way of confirming was kept. Nothing is filled in afterwards. | Under it a second line may read "The agent says this was decided by: "…" (meeting). This is the agent's claim, not a checked fact." What the agent wrote stands inside the quotation marks; nothing in it is CorPole's statement. It appears when an agent passed the decision on and named who took it. It stays after the decision is accepted: accepting says the decision holds here, not that the named person took it. The decision's note carries the same words, and agents that receive the decision are told how it was recorded, not that the claim is true. What an agent says about a person's yes is never enough for a "Confirmed" line. #### Directions: what your agent is told, and what happens when you state one **The directions in force reach every agent session by themselves.** With the plugin's hooks on, the session starts with a block headed "Directions in force": each direction with its code and its sentence, the newest first, and one line of rule — they hold for all work in this solution; a direction that is not confirmed yet, or is Superseded, does not hold. With none in force the block says so. At most ten are written there, fewer when they are long (the block has its own share of the session's context, so the binding requirements keep theirs); the agent's status answer (get_status) lists every one. A direction whose sentence looks like it holds a secret — one written on the screen before sentences were checked — is not shown to any agent — in the block, when an agent reads the direction by its code, when it searches, in the context of the work a decision governs or in the list of changes; the same holds for a title, notes, an answer and the reason of a withdrawal: the line gives its code and says the sentence is withheld. You see it too: the direction's row in the Directions list and its page say "Agents are not shown this sentence: it looks like it contains …"; withdraw it and state it again without the secret. The sentences are quoted as stored, line by line: they are data, and nothing in a sentence can pass for an instruction of CorPole's. An unconfirmed direction, a superseded one and another solution's are never in the block. Without the hooks (the desktop app, say) nothing arrives at the start; the same list is in the agent's status answer. **During a session** the agent hears what you did with its next prompt or tool answer, by code: that a direction is in force now, that it replaced another, or that you withdrew one. It reads the direction itself before it relies on it. - **A direction or a lasting instruction?** A direction says which way the solution's work goes — what is built or not, in which order, what comes first, a standing choice about the product or its priorities — and holds for every agent of the solution. A lasting instruction says how your agent works — format, language, tools, conventions. Words such as "from now on", "never" and "always" can open either. When your sentence could be either, your agent asks one question that names both: "Is this about where the solution goes — a direction for every agent — or about how I work?" - **When you state a direction** ("first the authorization model, then the screens", "do not go for an MVP, go deeper"), your agent records it in your own sentence, word for word, and tells you what happened: where your AI client can ask you, it asks whether the direction is accepted in your name; otherwise it waits on its card on **Waiting for you**. It does not ask "shall I make this permanent?" for a direction. - **Until you confirm it, a direction binds nobody.** Your agent does not change the order or the content of the work because of a direction that still waits; it says that it waits and goes on under the directions in force. - **What waits for you** is said with CorPole's own sentence ("3 cards wait for you: …"), the same one this screen shows; the agent does not add a count of its own. - **Why a sentence can be refused.** A direction is stored word for word and given to every agent session, so a sentence that looks like it holds a secret or personal data is not stored at all: an access token or API key, a private key, "password: …" or "token = …", an address with a user name and password, a card number (13 to 19 digits in a row) or an 11-digit identity number. The refusal says which of these it looks like. Say the direction again without it. The same holds when you correct the wording on the card or edit a waiting direction on its page. These are the rules of the prompt log; they do not look for e-mail addresses, and a run of digits counts only when it is plausibly what the rule names: a card number that passes the card check, an identity number whose check digits hold. Two dates in a row or an order number are not refused. - **Personal preferences live in your AI client; CorPole keeps what binds others.** How your agent works for you alone ("keep your answers short") is kept by the client itself, in its own memory; your agent does not ask about it and does not send it to CorPole. CorPole holds the solution's rules, constraints, standards, terms and directions. For something that should hold for every agent of the solution your agent asks once whether to propose it as a rule for the whole solution; it is a Draft until a person approves it. A personal rule is kept in CorPole only when you ask for that (or your client has no memory of its own): it is then a **Draft** of yours — not in force — until you confirm it in a question your client shows you or switch it on under your initials › **Personal rules**. What the agent reports about your yes in chat is not read. #### Directions: the list, replacing and withdrawing A **direction** is a decision that says which way the work goes from now on. The directions of a solution are a filter of the list of decisions: open **Knowledge → Decisions** and choose **Directions** in the **Kind** filter (the address ends in `?kind=direction`). The solution's home page links to it with a line that says how many directions are in force, or "No directions in force". An ordinary decision is never in this list. | Column | What it shows | | --- | --- | | **Direction** | The title and, under it, the whole sentence, word for word. The sentence is the direction. | | **Status** | **Accepted**: in force. **Proposed**: relayed by an agent or written by a person, not confirmed. **Superseded**: no longer in force — replaced or withdrawn. **Rejected**: a person said it is not theirs. | | **Scope** | Where it holds: "This solution". | | **Confirmed** | Who confirmed it, when and how: "confirmed on the screen" or "confirmed in the client". A direction nobody confirmed reads "relayed by the agent — not confirmed" with **Open its card**: it binds nobody until a person confirms it there. A candidate that was not confirmed reads "Dismissed — not a direction" with who dismissed it and when, or "Lapsed — not confirmed in 30 days". | | **Chain** | "replaces DEC-…": the directions it took the place of. "replaced by DEC-…" with a link to the one that holds now. "withdrawn on (date) by (name) — nothing replaces it: (reason)". | | **Action** | **Withdraw**, on a direction in force, for people who may decide on knowledge. | **Small choices your agent does not ask you.** A choice that is yours but cheap to change — which of two pieces of work comes first, or a matter of taste such as which column leads a list (the decision classes priority and brand and taste) — is not put to you as a question. Your agent chooses, and records the choice as its own assumption, with the options it chose among, the one it took and one sentence saying why. When a direction in force plainly covers the choice, the agent names that direction; when none does, the record is marked as following no direction. Your agent is told to present the choice as its own, never as yours, and that you can read it and take it back. **Where you read them.** Such an assumption is not a card: nothing opens on **Waiting for you**, its number and the number in the context row below the top bar do not change, no notice is sent and your agent does not stop. The foot line there reads "2 choices your agent made without asking — read them" and opens the **Assumptions** view of the Questions table (Knowledge → Questions, Kind: Assumptions). The line counts the choices nobody has read: those derived from a direction of yours and those no direction covered. An agent's working assumption on a decision of its own and an assumption on a preparation question are not among them: they are an open question and a preparation item, as before. The table lists them newest first; you can search it, and filter it by state and by "No direction". | Column | What it says | | --- | --- | | **Choice** | The question the agent settled for itself, with its code. Open it to read all of it. | | **Class** | The decision class the agent declared (priority, brand taste, …). It is the agent's word: CorPole did not check it. | | **What the agent chose** | The option it took. When the assumption has no options, the agent's own sentence stands here. | | **Derived from** | The direction the agent says the choice follows, linked, with its state now — "no longer in force (replaced by DEC-…)" when it was replaced or withdrawn since — or "No direction". **Left to the agent by you** when you answered its question with "I don't know, you decide": the agent took the option it had recommended, and it is yours to check. | | **Agent**, **Noted** | The connection that recorded it, and the day. | | **About** | The record or work item the choice concerns, when the agent linked one. | | **State** | **Not read**, **Read** or **Taken back**, with who did it and when. | **The assumption's page** starts with a form named **The agent's choice**: the choice itself as its first line, then **The agent chose**, **Among** (every option, the chosen one marked "chosen by the agent"), **Why** (the agent's own words), **Derived from** (the direction's code, its sentence and its state now, or that no direction in force covered it), **Class, as the agent declared it** — with the reminder that the class is the agent's word and CorPole did not check it — the agent, the day and what it is about. Under it, **Your answer** has two answers; nothing is chosen for you: - **Fine as chosen** — "It stays the agent's choice; you have read it." Only one thing is recorded: that you read it, with your name and the time. Nothing else changes. It stays the agent's assumption and stays open; it is never shown as answered or decided by you, it closes no preparation question, and your agent is told nothing. Wherever a status is shown it reads **Read — the agent's choice** (before you read it: **The agent's choice — not read**), and the page's Answer cell reads "The agent's choice · read by … on …". Reading is not final: on a read assumption's page **Your answer** shows who read it and when, and still offers **This was mine to decide** — **Fine as chosen** is not offered a second time. - **This was mine to decide** — "It becomes a question for you on Waiting for you, and your agent is told it was not its choice." The assumption becomes a question of yours with its card in **Questions**: the options stay, none is recommended, and the one the agent took is marked "Your agent had chosen this". The class the agent declared and the link to a direction are dropped. An assumption that had no options also gets its card, with the one answer **Your answer**, in your own words. The agent whose connection made the choice is told once, before its next answer, whoever of you took it back: "… says QST-… was theirs to decide, not a choice for you to make (you declared it as …). It waits for their answer on its card: do not build on your choice." While guidance is suspended no card can open, so taking back waits until it is on again. - **Save answer** is the page's one primary button. The question's own details below it are read-only on an assumption's page — they are the agent's text — with no Save, no Status menu, no Answer panel and no Workflow section: an assumption is not answered, and its state moves only by these two answers. Answering needs the right to accept and reject decisions; without it you see the same form with the answers disabled and a line saying who can. A second **Fine as chosen**, or a save on an assumption that was taken back meanwhile, says "This one is already closed." and writes nothing. **Delete** on an assumption is for a person with the same right who may also edit knowledge: it removes the record of a choice made in their name; anyone else is told so and nothing is deleted. - **Which assumptions these are.** Only the choices an agent made in your place: those derived from a direction of yours and those no direction covered. An agent's working assumption on a decision of its own, a question guided start reclassified as an assumption, and an assumption on a preparation question are not among them: they are ordinary open questions and preparation items, answered and counted as before, and the foot line does not count them. - **Mark as read** on the Assumptions table does **Fine as chosen** for the rows you tick — nothing is ticked for you; "Select all n shown" ticks the unread rows in view, and "n selected" counts them. At most 50 in one save; a row that was closed meanwhile is skipped and named in the result. Taking a choice back is never done in bulk: open it. **On a direction's page** the health strip has a cell **Derived choices** ("2 open / 3"): it opens a side panel that lists the choices agents derived from this direction — the choice and what was chosen, the agent, the day and the state — each linked to its page. Under the Directions table one quiet line appears while choices made without a direction are unread: "Chosen without a direction: 3 — read them". **Agents → Health** has the table **Choices made without asking, by agent**: how many each agent made, and how many of them are not read, read (fine as chosen) and taken back; the share taken back is shown from five reviewed choices on, and "too few reviewed" below that. CorPole checks the direction the agent names: it must be a direction of this solution that is in force and whose sentence agents are shown. A direction that still waits for your confirmation, a Superseded or Rejected one, a candidate, a code of another solution and a code that is no direction are refused, and nothing is stored. CorPole does not judge whether the direction really covers the choice, nor whether the choice was really a small one — both are the agent's reading, which is why you can take a choice back. A choice is stored only with at least two options and the one that was taken, and not at all when its text looks like it holds a secret or personal data. What you already decided is not assumed again: when you answered a question with the same title, or closed its card, the agent is told your answer and nothing is stored. At most 20 such assumptions wait unread in a solution; the next one is not stored, and the agent is told to say so — reading one or taking it back frees its place. An assumption is never an open question for your agent to ask you, and it blocks nothing: the work it concerns is not held, and the agent sees it under "Your assumptions (not the person's decisions)" with whether you read it. These records also count against the same hourly limits as the agent's other questions. A choice about scope, money, law, risk or a promise to others is never handled this way — it is always asked. **Candidates — not binding.** Sometimes you say something that sounds like a direction only in passing, inside a request for other work ("…and in reports the risk order always comes first"). Your agent does not interrupt the work for it: it notes the sentence, word for word, as a **direction candidate**, tells you so in one line and goes on with what you asked. A candidate binds nobody. It opens no card, asks you nothing in your AI client, sends no notice, and is in no count of what waits for you. It may shape only the task of the prompt you said it in — never a later session and never another agent. A direction you state on purpose is not a candidate: it is relayed as before and waits on its card. **Stated or said in passing — how your agent tells them apart.** Your agent is told, with the directions at the start of a session, in the tool it records with and by the plugin: "Stated on purpose: record_decision (kind direction) — asked in the person's client where it can be, else it waits on its card. Said in passing inside a request for other work: add candidate: true — no card, no question; say in one line that it is noted as a candidate and do the work. Unconfirmed, neither binds anyone." and "A candidate noted in this prompt may shape only the task of this prompt; it never binds a later session or another agent." In a solution under guided start the block of directions an agent session gets ends with the open candidates — at most the three newest, each with its code and its sentence cut to 120 characters — under the line "Candidates — not binding, do not act on them:". They are shown so that the agent does not note them twice and does not take them for directions; a dismissed or lapsed candidate is never listed, and a connection that is not shown your directions is not shown the candidates either. When the block is too long, the candidates are left out before any direction in force is. **"Write that down as a decision."** If you tell your agent to record a candidate on purpose after all, it sends the same sentence as a stated direction. No second record is made: the candidate itself becomes the relayed direction, with a card on **Waiting for you** where you confirm, correct or reject it, and it leaves the candidates section (its place among the ten is free again). A sentence you dismissed is still refused. **When a candidate contradicts a direction in force**, your agent does not stop and no conflict card opens — a candidate binds nobody. The agent marks it instead: its row and its page read **The agent says it contradicts DEC-…** with a link to that direction. A marked candidate is never confirmed in one click: the row's button reads **Confirm…** and opens its page, where the marked direction stands in the choice — **Confirm and replace** (tick it) or **Confirm, keep both** — with nothing ticked for you. The mark is the agent's reading, not a finding of CorPole. Only the agent's own recording sets it, once; nobody edits or removes it on the screen, and a link you add by hand is not a mark. If the marked direction is replaced meanwhile, the mark is not dropped: the line reads "The agent says it contradicted DEC-…, which DEC-… has replaced", and the direction that replaced it stands in the choice. Only when nothing in force is left in that chain does the line say so, and Confirm is one click again. The mark stays with the sentence when you have it written down as a decision: its card on **Waiting for you** shows **The agent's mark** and the marked direction beside the new one, and your AI client does not ask about it — the choice is made on the card. Open candidates are listed in the section **Candidates — not binding** above the Directions table; the section is there only while a candidate is open. Each row shows the sentence word for word, the agent connection that noted it, the day it was noted, the day it lapses ("lapses 2026-11-08"), and **Similar to DEC-…** when a direction in force resembles it. An open candidate is not repeated in the table below. - **Confirm** makes the candidate a direction in force: Accepted, with your name, the time and "confirmed on the screen" — exactly as when you confirm a relayed direction. When no direction in force resembles it, Confirm in its row is one click. What you confirm is exactly what the row shows: a candidate's title is its sentence (a long sentence is cut at a word, with "…"); the agent's own title is not kept. - **When a direction in force resembles it**, the row's button reads **Confirm…** and does not confirm: it opens the candidate's own page, and a quiet line under "Similar to DEC-…" says so ("Choose on its page whether it replaces that one or stands beside it."). There **Confirm** in the action row shows the similar directions with a checkbox each, none ticked for you, and two buttons: **Confirm and replace** (the ones you tick become Superseded and point to the new direction) or **Confirm, keep both**. - **Not a direction** dismisses it: it is Rejected with your name, and the list and its page read **Dismissed — not a direction**. Your agent does not note that sentence again, and it cannot bring it back as a relayed direction either: both are refused, it is told you dismissed it, and no card opens. If it is yours after all, open the dismissed candidate (it stays in the table below) and choose **Reopen as candidate** at the top of its page. The same holds the other way round: a sentence you called **Not mine** on a relayed direction's card is not noted as a candidate for you. - **Reopen as candidate** is on the page of a candidate that was dismissed or that lapsed, for people who may accept and reject decisions. It is an open candidate again, back in the section above the table: the day it was noted is kept, and its 30 days start on the day you reopen it. The limit of 10 open candidates holds, and a sentence that is meanwhile in force, waits as a relayed direction or is another open candidate is not reopened; the page says which. Only a person does this, on the screen: your agent cannot. - **After you act**, a strip at the top says what happened: "DEC-… is a direction in force now: confirmed on the screen." or "DEC-… is dismissed — not a direction. Your agent does not note this sentence again." A refusal is shown the same way, as one sentence that says what to do instead. - **While guidance is suspended**, a candidate that resembles a direction in force cannot be confirmed: the choice between replacing and keeping both waits until guidance is back on, and its page says so. A candidate that resembles none is confirmed as usual, and **Not a direction** always works. - **Lapse.** A candidate nobody confirmed lapses 30 days after it was noted. From that moment it is no longer offered and no longer counted, and it reads **Lapsed — not confirmed in 30 days**; a daily job also sets it to Rejected, with nobody as its decider. If it was your direction after all, reopen it on its page (**Reopen as candidate**) or tell your agent the direction again. - **At most 10 candidates are open in a solution.** The eleventh is not stored; your agent is told to send you here to confirm or dismiss the others. A lapsed or dismissed candidate frees its place. - **The candidate's own page** says "A direction candidate your agent noted in passing — not binding" with the day it lapses, and offers the same two acts, **Confirm** and **Not a direction**, in the action row. The **Status** menu offers no move for a candidate, and **Waiting for you** does not list it. - **Who can.** Confirming and dismissing need the right to accept and reject decisions (the same right as accepting a direction). Without it you see the section and the page read-only, with a line saying who can. - **The same sentence twice.** If your agent notes a sentence that is already an open candidate, nothing new is stored. If the sentence already waits as a relayed direction, the agent is given that direction's card; if it is already in force, it is told so. **Replace or keep both is your choice, on the card.** When your agent relays a direction that resembles one in force (their sentences share most of their meaningful words), the new direction's card on **Waiting for you** shows the two side by side: the one in force with its code, who confirmed it and when, and the new one. Up to three similar directions are listed, newest first. Instead of one Confirm there are two buttons. **Confirm and replace**: the new direction is Accepted and each direction you ticked becomes Superseded; the most similar one is ticked when the card opens, and you can tick others or untick it. **Confirm, keep both**: the new direction is Accepted and the others stay in force beside it. **Correct** offers the same two buttons for your own wording. **This is not mine** is as before. - A replaced direction is not deleted. It stays in the list as Superseded, and its page and its row point to the direction that replaced it; the new one's page says which ones it replaces. Both histories keep who did it and when. - Your AI client never asks about replacing. When a similar direction is in force, a new direction is not asked in the client at all: it waits on its card, and your agent is told why. - If a direction the card shows was replaced or withdrawn by someone else meanwhile, your confirm is refused with a sentence on the card and nothing is written. Read the card again: it shows what is in force now. - Your agent is told what you did with its next tool answer, and with your next prompt where the plugin's hooks are on, by code: "confirmed DEC-…, replacing DEC-…". **Withdrawing a direction.** A direction in force that no longer holds, with nothing in its place, is withdrawn: **Withdraw** in the action row of the direction's page, or in its row of the Directions list. Write why (at least 5 characters); the reason is kept in the direction's history and shown in the list. The direction is not deleted: it becomes **Superseded** and says "nothing replaces it". Only people who may decide on knowledge can withdraw, and only a direction that is Accepted — one that still waits is settled on its card. The **Status** menu does not offer Superseded for a direction in force, so a direction never leaves force without a reason. Your agent is told "a person withdrew DEC-…" and reads the reason on the direction itself. **A direction changes only by its own acts.** A direction comes into force when a person confirms it (on its card, or in a question their client shows), and leaves force when a new direction replaces it on that direction's card or when it is withdrawn with a reason. Nothing else moves it, and what is refused is not offered: - **In force (Accepted):** the **Status** menu offers no move, **Delete** is not offered, and its title, sentence and code are shown read-only on its page, with a line that says how a direction changes (notes can still be edited). Under the Status field the page says what ends it. To change what it says, tell your agent the new direction and choose **Confirm and replace** on its card. To end it, **Withdraw**. - **Superseded (replaced or withdrawn):** it is not reopened and not deleted — it is the history of what held, and other directions point to it. If it should hold again, say it again as a new direction. - **Proposed (relayed, not confirmed):** you can accept it on its own page with **Status → Accepted**, or reject it there — unless a similar direction is in force. A new direction is never accepted beside a similar one without your choice. In a solution under guided start the page then refuses and gives the address of its card (if the card was missing it is opened); while guidance is suspended it says the choice waits until guidance is back on. Where you have no card — the solution is not under guided start, or guided start is not turned on for you in it — the direction's page has an **Accept** button in the action row that lists the similar directions and offers **Accept and replace** (the ones you tick become Superseded) and **Accept, keep both**. Like the card, that form holds what it showed you: if another similar direction was confirmed meanwhile, or the direction's text changed, nothing is written and the page asks you to read it and choose again. It can be deleted; its card closes with it. - **Correct on the card compares your wording.** If the wording you write resembles a direction in force that the card had not shown beside it, nothing is written: the card comes back with your wording kept in the field (it is kept for five minutes, on your browser and for you only, and never put in the page's address; a very long wording in a non-Latin script cannot be kept and the card then asks you to write it again) and that direction shown beside it, and you choose **Confirm my wording and replace** or **Confirm my wording, keep both**. - **A page left open.** If a direction changed while its page was open (it was confirmed on its card, say), a status move or a delete from that page is refused with a sentence and nothing is written. - **Rejected:** it is not reopened. Say it again if it is yours after all. - **Links:** the "Supersedes" link of a direction is written when a person confirms a replacement on a card. It cannot be added or removed by hand on a direction, and accepting a decision that carries such a link never supersedes a direction. - Each refusal is one sentence that says what to do instead. Your AI client never asks about a direction that resembles one in force, in any solution: the choice is yours, on the screen. Known limit: a direction you write by hand on the screen of a solution under guided start opens no card; if a similar one is in force, tell your agent the direction instead. **Superseded with no replacement** means: this was a direction once, a person withdrew it, and no other direction took its place. Agents no longer follow it. #### Retrospectives with agents - About **once a day** per solution and person, after real work, CorPole asks the agent what it learned and what could be done cheaper, faster or better. Its answers arrive here as proposed lessons and ideas marked AI. In a solution under guided start the request opens with `CorPole guided (RETRO)`, one of the few lines in a tool answer that the agent's rules (BR-007) let direct it — everything else it reads there is data — so an agent that keeps its rules does not skip the request as data. - In Claude Code, **/corpole:retro** runs a retrospective on demand and can bring in lessons from the agent's own memory files (you see the list first; secrets are masked). - Workspace owners and admins can **Share with the whole workspace** an accepted lesson: every solution then gives it to its agents, with the solution it came from. Accept or reject each one. On an accepted lesson, **Promote to solution rule** turns it into a solution agent rule (needs the Integrations permission); on an idea, **Create work item** makes an epic, story or task linked to it. #### Tenant-wide knowledge and exceptions Owners and admins can make standards and glossary terms tenant-wide: every solution inherits them. A solution that needs an exception records a decision that **waives** the standard; the waiver takes effect when the decision is accepted, and the standard is then left out of that solution's context. #### What agents do with it - Read the standards (get_standards) and follow the MUST ones. - Treat accepted decisions as binding; proposed ones are not. - Stop and ask when an open question concerns their work; raise new questions with ask_question instead of guessing, and propose choices with propose_decision. - Use glossary terms exactly; they are matched in the text of the work automatically. ### Decisions: propose, accept, supersede Source: https://corpole.com/support/knowledge/decisions · Knowledge Accepted decisions bind the records and work they govern. Proposed ones do not. #### Steps 1. Ask the agent to propose a decision when a design choice is made, or write one yourself. 2. Link it to what it governs. 3. Accept it; from then on agents treat it as binding. 4. When it changes, accept a new decision that supersedes it. #### States Proposed → Accepted / Rejected → Superseded. ### Questions: how agents ask instead of guessing Source: https://corpole.com/support/knowledge/questions · Knowledge When something is missing or ambiguous, the agent records a question with its working assumption. #### How it works - The agent opens a question linked to what it concerns, and says what it assumes until someone answers. - Low risk: it goes on with the assumption and tells you. High risk: it waits. - An open question on its work makes the agent stop and ask. #### States Open → Answered. ### Standards, and waiving one with a decision Source: https://corpole.com/support/knowledge/standards-and-waivers · Knowledge Standards say how work is done. A solution records an exception with an accepted decision that waives it. #### Steps 1. Write the standard (coding, security, testing, compliance) as Must or Should. 2. Make it tenant-wide or account-wide if every solution should inherit it. 3. For an exception, accept a decision that **waives** the standard in that solution. #### Keep in mind > **Caution:** Mandatory account-wide standards (for example regulatory ones) cannot be waived by a solution decision. ### Lessons and improvement ideas Source: https://corpole.com/support/knowledge/lessons-and-ideas · Knowledge What agents learn becomes shared, and ideas can become work. #### Lessons - Something learned the hard way and what to do instead. - Accepted lessons are given to every agent in the solution. - A lesson can be promoted to a solution rule. - Closing an urgent initiative's post-incident review proposes a lesson. #### Improvement ideas - A way to cut cost, speed up delivery or improve quality. - An accepted idea can become an epic, story or task. #### How they arrive CorPole asks agents about once a day per solution and person, after real work. `/corpole:retro` runs one on demand and can import lessons from the agent's memory files after you approve them. ### Governance preview Source: https://corpole.com/support/agent-policy-and-rules/governance-preview · Agent policy & rules 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. #### What you can preview - **Ready or Done gate** to enforced or advisory: the moves of the last 30 days that would have been refused, and the waiting items it would stop today. - **Agents in CorPole** (e.g. report defects) to forbidden or allowed: the agent calls of the last 30 days that would have been refused or let through. - **Agents in the code** (e.g. add dependencies) to allowed, ask first or forbidden: which solutions' levels change; the account's floor and a solution's stricter level stay; the repository kit must be re-applied where Claude Code rules change. #### Good to know The past is read against today's state: an item fixed since it was moved is not counted. Code actions happen outside CorPole, so their past count is unknown. Make the change afterwards in Tenant settings or Solution settings › Agent policy; your agent can run the same preview with preview_governance_change. ### Solution settings Source: https://corpole.com/support/agent-policy-and-rules/project-settings-screen · Agent policy & rules 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. #### Issue tracker **Issue tracker** shows the Jira or Azure DevOps solution this solution syncs with. The connection belongs to the tenant (Tenant settings); the solution's Integrations people can **Sync now**, **pause** the sync for this solution, and settle its **conflicts** — a field changed on both sides since the last sync — by keeping CorPole's value or taking the tracker's. #### Solution settings for agents **Record language**: agents write this solution's records, criteria, questions and work items in it, whatever language you talk to them in. When it is not set, the agent asks during the kickoff. **Go ahead without the kickoff**: in a new solution without any Authority record, someone who can make records Authority may let work start before the kickoff interview, with a reason. Agents stop offering the interview and the code gate stops asking until the first Authority record; the choice is kept in the history and can be withdrawn. If the tenant's gate for new solutions is enforced, it still applies. #### Authority handover | Tier | Agents | | --- | --- | | **Shadow** | Read CorPole, but the repository's own sources still lead; conflicts go to you. | | **Shared** | CorPole wins where it has an Authority record; elsewhere the old sources apply and the agent proposes moving them in. | | **Full** | CorPole is the only source; old documents point to it. | Solutions created with existing code start in Shadow; everything else is Full. A component can have its own tier (an old repository in Shadow, a new one in Full); the solution's tier is the lowest of its components. Only people who manage the solution's integrations declare the tier; every change is kept in the history. Re-apply the repository kit afterwards so CLAUDE.md says the same. **Inventory** lists what governs the solution outside CorPole — agent rule files, requirement documents, ADRs, glossaries, tickets — with its size and status: **To move**, **Moved**, **Historical** or **Stays outside**. Agents record it during the handover; you settle what stays outside. **Readiness** shows the share of settled sources, Authority records, drafts waiting for review and open questions, and whether the next tier is due: Shared needs an inventory, half of it settled and at least one Authority record; Full needs every source settled, no draft waiting and no open question. #### Agent policy Per action — migrations, dependencies, CI/CD, security code, tests, public contracts, merging — choose **Allowed**, **Ask first** or **Forbidden**. The solution inherits the tenant's policy and can only make it stricter. Forbidden CorPole actions are refused by the server; code actions become Claude Code permission rules through the repository kit. **Guarded areas**: for security code, tests, public contracts, CI/CD and production access you can list the files that belong to them (e.g. `src/auth/**`). An agent may change those files only at that action's level: Claude Code asks or refuses before the edit, even without re-applying the repository kit, and the PR check flags them for any client. Areas add up from account to tenant to solution. When you allow an agent to change a guarded area or ungoverned code in Claude Code, the plugin tells CorPole and the approval is kept in the history: who allowed which agent to do what. Ungoverned code is recorded as your approval only where the edit gate asked you about that file shortly before; a file outside the repository is never recorded as one. When the edit gate asks you, your agent is told too: that the gate asked, why, and that your yes allows that one change and nothing more. Such an entry reads **Allowed in the client**, on the Changes page, in the audit trail and in what an agent gets from `get_changes`: "Not a change of the agent policy: a person allowed, in their client, an edit the edit gate had asked about (file notes.md)." It is not a change of the policy on this page. A file outside the repository is named by its file name only; the full path is in the call itself, under **Agent activity**, where the call is listed as `allowed in the client`. When a hook credential reported it, the entry says so. #### Components The parts of the solution — the web app, the mobile app, a service. Add, rename or remove them here (a component with a repository or onboarded modules cannot be removed; the work and records of a removed one move to the main component). Each component has its repositories or monorepo folders, its modules and its technical design, and can be at its own authority tier. #### Repositories and CI Connect each repository of the solution: the provider (GitHub or GitLab), its path (owner/name on GitHub, group/project on GitLab), and for a monorepo the folder and the component it holds. Each repository gets its own webhook secret; add the webhook with the URL shown. On GitLab use it as the secret token, or paste the signing token GitLab generates (stronger). Change requests (pull requests, merge requests) and commits that mention a story, task or defect code link themselves and move the work. CI can report test results with a service token from **Agents → Agent tokens**. A repository can start a new component (e.g. Mobile app); with several components each can have its own authority tier, and the solution's tier is the lowest. The repository kit writes a GitLab merge request template and a CI file with the merge request check and test results for GitLab repositories. **Pull-request check: authority rules.** The CorPole check stops a pull request that builds on something unsettled. An open question about a cited record, or an open conflict between records, fails it. A criterion without a passing test, or a record that is still Draft or Approved, gives a warning. For each rule you choose error, warning or off, or keep the tenant's setting. Every finding tells the agent what to do. To pass one pull request with an open question the team accepts, add the label open-question-accepted. **Check mode and connection health.** A newly connected repository's CorPole check starts **advisory**: it reports what would fail and still passes, so an older repository is not blocked on day one. Once 90% of its checked pull requests cite a record or work item (at least 10 in 30 days), it becomes **enforced** by itself and the people who manage integrations are told. You can switch it earlier, or keep it advisory. Make the check "CorPole requirements / pr-check" required in the repository's branch protection, then confirm it here. The connection's health lists the webhook, the PR check, the required check, the repository kit, the agent files and recent pull requests, and says what to do about each missing piece. **The AI semantic review and your directions.** When the AI semantic review is on, it reads, beside the Authority records the pull request cites, the directions in force in the solution — at most ten, the portfolio ones first, each quoted on one line. It runs when the pull request cites an Authority record or names a direction in force by its code in its title. A diff that plainly goes against a direction gets **possible requirement gap** with the direction's code, as a warning: it never blocks the merge. A direction whose sentence looks like it holds a secret is not sent. ### Agent rules Source: https://corpole.com/support/agent-policy-and-rules/agent-rules · Agent policy & rules The behavioural rules every AI agent connected to CorPole follows, and how each level adds to them. #### Working modes and lasting instructions **Working modes** are ready-made rules you switch on for yourself (Personal tab) or for a solution: *Plan first*, *Small steps*, *Analysis only*, *Tests first*, *Smallest change*, *Challenge me*. Agents follow them from their next session. You can also just tell your agent. **Where a lasting instruction lives depends on whom it is for.** A preference about how the agent works for you alone — short answers, a language, your own style — stays in your AI client's own memory or settings; CorPole is not asked and nothing is stored here. What should hold for every agent of the solution — a convention, a term, a constraint, a standard, a team way of working — the agent asks about once ("Shall I propose this as a rule for the whole solution?") and, on your yes, proposes: a solution rule, constraint, standard or glossary term arrives as a Draft for approval. If you want a personal rule kept in CorPole all the same, say so ("keep this in CorPole for me"): it is kept as a Draft of yours that you switch on under your initials › Personal rules. A permission (what agents may do on their own) stays with the agent policy under ⚙ › Solution settings. #### How rules flow Rules flow down: **platform → account → tenant → solution → you**. The agent acting for you receives all of them, in order, when it connects and whenever it reads the agent policy; each rule shows where it came from. | You can | Where | | --- | --- | | **Add** a rule | At any level you manage. | | **Tighten** an inherited rule | Adds a sentence at your level; the original text stays. | | **Switch off** an inherited rule | Only when it is marked optional and nobody above enforces it. | | **Enforce** a rule | Account, tenant or solution: nobody below may switch it off. | | **Activate** a proposed rule | Solution (Solution rules): agents propose rules from rule files, lessons or the conversation as Drafts; **Activate** or **Turn down** each one. Nothing applies until you do. | | **See** what people changed for themselves | Solution: how many members switched off each optional rule and how many have personal rules — counts only, personal rules stay private. When you add a rule, the rules already set above it are listed by category so it does not contradict them. | #### Who manages which level - Platform — CorPole's platform administrators. **Locked** platform rules keep CorPole working (permissions, Authority first, propose instead of decide, stop at conflicts, hands off its own controls, no secrets); they cannot be switched off, retired or deleted. - Account — account owners and admins. Tenant owners and admins are notified when a platform or account rule is added, changed or enforced. - Tenant — tenant owners and admins. - Solution — people with the Integrations permission on the solution. - You — your own rules, followed by the agent that acts for you. > **Tip:** Rules tell the agent how to behave. What it is allowed to do is decided by the agent policy (account, tenant settings, Solution settings) and by your permissions, which CorPole checks on every call. ### Waiting for you Source: https://corpole.com/support/agent-policy-and-rules/decisions · Agent policy & rules 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. #### Where to find it The **Waiting** counter in the context row below the top bar shows how many cards wait for you in the current solution; it turns amber when something waits and opens this page. **Waiting for you** in the menu (under General) and in the avatar menu opens it too. The screen has one name everywhere: the menu, the page, the browser tab and what your agent calls it are all **Waiting for you**. **Decisions** in the menus means only the list of decision records (Knowledge). **Home** (General › Home, the page that greets you) does not list the cards. Under **Waiting for you** it shows one line — the same sentence this page shows, for example "3 cards wait for you, 1 prepared by your agent." — and the link **Open Waiting for you**. Home also shows the agents that wait for you, what waits in your other solutions and your unread notices. #### How it works 1. Ask your agent "what waits for me?" or "prepare what waits for me". It reads each item and stores a two-line summary and a recommendation (approve, turn down, or a proposed answer). 2. Open **Waiting for you** (the menu, the **Waiting** counter, or your initials › Waiting for you). Prepared cards show the agent's summary; its recommendation is preselected. 3. Change what you want, leave the rest on **Later**, and **Apply my choices**. Each card is applied as you, with your roles checked; the history says which agent prepared it. 4. **Approve on a draft is a review.** On an agent's draft the choice reads **Approve (reviewed — binds nothing yet)**, with the line "Approve marks it reviewed (Approved); it binds nothing until a person makes it Authority on its page — only Authority binds." The message after **Apply my choices** says the same. The notices that tell you drafts wait for review say "Nothing binds until a person makes it Authority in CorPole (Approved means reviewed; only Authority binds)." Your agent never decides for you, and its word never makes something yours. You can tell it an answer ("the answer to QST-… is …") or a decision taken in a meeting or by the client; it writes down the wording and passes it on. What happens next depends on your AI client: - **Your client can ask you.** A question appears in the client and shows everything your yes would record, the weightiest first: who is said to have decided, the work priorities it would change, the records it would govern, then the title, the text and the context. If you confirm it there, the answer is recorded as yours, or the decision as **Accepted** with you as the decider (accepting needs the permission to decide on knowledge). It is kept as confirmed **in the client**. The question is valid for ten minutes and only for that exact content; after that, or if anything in it changed, you are asked again. - **It is too long for the client.** A decision or an answer that does not fit one question in the client (about 1,500 characters with its labels) is never cut and never asked there: you would be accepting text you were not shown. It is stored as a proposed decision or a filled-in answer, as below. - **Your client cannot ask you, or shows no question.** Some clients, the Claude desktop app among them, say they can ask and then show nothing. Nothing is lost and nothing is recorded as yours: the decision is stored as a **Proposed decision** and waits in this list, and the answer is filled into its question here, marked "Prepared by" your agent with the note "Your agent passed this on as your answer from the conversation. It is not recorded as yours". The question stays open. - **You make it yours here.** Choose **Approve** on the proposed decision, or **Answer** on the question — change the filled-in text first if it is not what you said — and **Apply my choices**. It is then kept as confirmed **on the screen**, with your name and the time. **Later** leaves it waiting; **Turn down** rejects the proposed decision. - **Who the agent says decided.** When the agent named who took the decision (you, a client, a meeting), the item shows "The agent says this was decided by: "…" (meeting). This is the agent's claim, not a checked fact." The agent's words are inside the quotation marks, whatever they say; only what stands outside them is CorPole's. Read it before you approve: CorPole cannot check it. After you approve, the decision's note says that you accepted it and how, and keeps the agent's words labelled as its claim. **Priorities are not applied for you.** When the agent named work priorities with a decision you did not confirm in the client, they are only written at the end of the decision's text ("Priorities named with it (not applied): …"). Approving the decision here does not change them either. Set each one yourself on its work item, in the **Priority** field. Priorities change with a decision only when you confirmed it in the client, where they were shown to you, and your roles allow editing work. **Who is asked in the client.** Only a connection you sit behind asks you: your own personal token or your sign-in from the AI tool. A service token (a pipeline that runs in its creator's name), a package token shared with someone outside, an auditor's token and the hooks never ask and can never confirm anything in the client, even when their client says it could: what they pass on is always a proposal for the screen. The same statement sent again by the agent is not stored twice: the proposed decision that is already there is kept, and no second notice is sent. The same holds for a decision you just confirmed in the client: sent again within ten minutes, it is the decision that is already recorded — nothing is stored again and no priority is set again, so a priority you changed on the screen in between stays. "The same" means the very same call: when your agent corrects anything in it (who decided, a priority, a governed record) and you confirm again, that is recorded as another decision. The title of a decision and the name of who decided are one line each; an agent's call with a line break, a control character or a text-direction mark (an invisible character that reverses or isolates the reading direction) in either is refused. Letters of any language are fine, and so are the joiners some names need, a soft hyphen and other invisible characters that come along with pasted text. Confirming in the client is all or nothing: the decision, what it governs and the priorities it sets are stored together, so a call that fails halfway leaves nothing and can simply be sent again. If you rejected or deleted the decision on the screen in the meantime, the same call sent again does not bring it back: your agent is told what the decision is now. A person whose roles do not allow accepting decisions is not asked in the client; the decision waits for someone who may accept it. The decision's own page says how it was confirmed (see Knowledge). What "in the client" proves: that the answer came through your connected AI client for the exact text shown, not that you personally pressed the button. Whoever holds your connection could ask and answer. **On the screen** is the only way of confirming that proves a signed-in person; use it for anything that matters. **Authority is given on the screen only.** An agent can ask you in your client to approve records (Approved), but not to make them Authority: that binds every agent, and the question in a client shows only a record's code and title, not what it says. When you ask your agent for it, it answers that you do this on the requirements board, where you read the record first. **Accepting a decision your agent recorded.** Open the decision's page from the link your agent gives and use the **Status** button in the row of buttons at the top right (Status, Add, Delete, History): **Accepted** is under "Next step". The Status field inside the form is read-only and says so under it. The first sentence of "Consequences and options considered" is what the agent said about who decided; you can add your own text after it, but it cannot be changed or removed. ### Notices Source: https://corpole.com/support/agent-policy-and-rules/notices · Agent policy & rules 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. #### Where they reach you | Channel | How | | --- | --- | | Claude Code | Shown by Claude Code itself at session start and when you send a prompt (the plugin's hooks), so the model cannot drop it. | | Other agents | Added to the agent's next tool result as a note for you to pass on. | | CorPole | The bell in the top bar opens them next to help; this page keeps the full list. | | E-mail | A daily digest of decisions waiting for you (about 07:00 Istanbul time, only when there is something new) and an e-mail at once for urgent notices such as a production emergency. Turn either off under **E-mail** on your own page (avatar menu › **Notifications**). | | Your choice | Under **What you hear about** on your own page (avatar menu › **Notifications**), turn off topics you do not need: GitHub, agent health, agent activity, rules and access, quality, portfolio. Decisions waiting for you and emergencies always come through. | | Browser | Under **Browser notifications** on your own page, turn them on in each browser you use. The browser shows a notification when an agent needs your permission or has waited for your input, and for emergencies — even when CorPole is not open. | One open notice per topic: a newer one updates it (for example the count of drafts waiting) instead of piling up. **Open** takes you to the place to act; **Read** marks it done. #### Reading the list Every signed-in person reads their own notices. The bell opens the latest notices in the right drawer; All notices opens the dedicated page. Both views group each notice's heading, message, time and source, then its actions. Text has equal space on both sides of the content surface, wraps within narrow screens and follows the reading direction. Action buttons wrap when the available width is small. Opening the list does not mark its notices read. Read in the drawer or Mark read on the page marks that notice read; Mark all as read marks your notices read. Open follows the linked work; in the drawer it also marks that notice read and closes the drawer. These actions do not approve a decision or complete the linked work. Close the drawer to return to the record you were reading. #### What you are told about | Event | Who hears | | --- | --- | | An agent asks a question / proposes a decision | Requirement approvers / people who decide | | Your agent's change proposal is accepted or rejected | You (with the reason when rejected) | | Work your agent proposed is made Ready or cancelled | You | | A story or defect reaches Code review / Verification | People who close work / people who verify criteria | | A pull request is closed without merging | People who close work and the people on the item | | A criterion becomes Not met, or an Authority record changes or is retired | The people on the open work it affects | | The first binding requirement of a new solution; a new authority tier; a solution agent rule changes | Everyone in the solution | | An agent raises a suspected conflict between two records | People who edit relations (as a decision) | | An agent reports a defect / raises a risk | Triage / risk owners (security and compliance risks as decisions) | | Lessons and ideas proposed; onboarding thresholds met | Knowledge editors; requirement owners | | A production emergency opens or ends | Everyone in the solution; requirement owners get the follow-up | | A post-incident review proposes a lesson | Knowledge editors of the solution | | A demand you recorded is linked to an initiative, is not pursued, or is done | You (with the initiative and its mode, or the reason) | | New demands in the Funnel and demands waiting there over a week (once a day, only when there are some) | People who manage the portfolio | | Maintenance periods close and their open work is carried to the next period | People who manage the portfolio (with the number of items carried) | Your **agent** is told too: when the agent rules, the policy, the authority tier or an emergency change, or a requirement it is working on changes after it read it, its next tool result carries a note to re-read — until it does. #### Your agent is waiting With the Claude Code plugin, an amber label in the context row below the top bar tells you when your agent has finished, needs your permission or waits for your input — for the first 30 minutes of the wait. Dismiss it or go back to your agent. ### My sessions Source: https://corpole.com/support/agent-policy-and-rules/my-sessions · Agent policy & rules 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. #### How it works - Claude Code reports each session through the plugin (with your personal token): start, every prompt, when it stops or asks for permission, and the end. - Other tools have no such reports: their sessions are estimated from their calls to CorPole (a pause of more than 30 minutes starts a new one) and marked estimated. - Waiting for you counts up to 15 minutes per wait; longer waits count as idle. - Your solution sees sessions only by an anonymous label with times — no names, no agent or token names, no work — and when fewer than three people used agents in the period, only totals (Agents → Agent sessions). - Detail is kept 90 days; after that a session keeps only its totals and no longer shows whose it was. ### The agent policy: allowed, ask first, forbidden Source: https://corpole.com/support/agent-policy-and-rules/agent-policy · Agent policy & rules Per action, decide what an agent may do alone. CorPole enforces it before the action. #### Actions it covers Database migrations, dependencies, CI/CD and infrastructure, security code, changing tests to make them pass, breaking public contracts, merging, pushing to main, production data, and CorPole's own actions. #### How it is enforced - CorPole actions: a forbidden tool call is refused by the server and logged. - Code actions: the repository kit turns them into Claude Code permission rules (ask / deny). - Agents read the policy once per session and in every work context. #### Levels Account and tenant set a baseline; solutions inherit it and can only make it stricter. ### Write your own agent rule Source: https://corpole.com/support/agent-policy-and-rules/write-your-own-rule · Agent policy & rules Rules shape how an agent behaves. Yours apply to the agent that acts for you, on top of the solution's. #### Steps 1. Open **Agent rules** and choose the **You** level. 2. Add the rule in one sentence, e.g. "Explain a plan in three bullets before editing more than two files." 3. Your agent receives it with every policy read, after the platform, account, tenant and solution rules. #### Keep in mind - You can switch off an inherited rule only when it is optional and nobody above enforces it. - Locked platform rules (permissions, Authority first, propose instead of decide, stop at conflicts, no secrets) cannot be switched off. - What an agent is *allowed* to do is the policy, not the rules. ### What your agent reads at the start of a session Source: https://corpole.com/support/agent-policy-and-rules/what-the-agent-reads-first · Agent policy & rules Before it writes code, the agent reads its policy and rules, the standards and what changed. #### Order 1. **Agent policy and rules** (`get_agent_policy`), with the solution's open initiatives, its maintenance initiative and the session's choice. 2. **Standards** that apply (`get_standards`). 3. **Changes** since it last looked (`get_changes`). 4. For the item it works on, the **work context** (`get_work_context`). #### Keep in mind In Claude Code the plugin loads the binding records at session start. CorPole flags an agent that writes before reading the policy and tells it to read first. With more than one open initiative and no choice yet, the agent asks you once which one you work on and records it with `select_initiative` (kept for 12 hours). Defects go to the maintenance initiative unless you name another. ### What an agent can never do in CorPole Source: https://corpole.com/support/agent-policy-and-rules/what-an-agent-can-never-do · Agent policy & rules Some decisions always belong to a person, whatever the policy or the prompt. #### Never - Make a record Authority, approve or retire it - Accept a decision - Confirm a design draft - Review a demand, or move or close an initiative - Move work to Ready, Verification or Done - Merge, or approve or check a task - Edit or delete records - Change the agent policy, rules, permissions or drift thresholds - Declare a production emergency on its own judgement - Act beyond the permissions of the person it acts for ### Compliance matrix Source: https://corpole.com/support/traceability-and-quality/compliance-matrix · Traceability & quality 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. #### Reading a row - **Proven**: every criterion has a passing test (within the period, when one is chosen). **Partly proven**: some are. - **Failing**: a covering test failed or is blocked. **Not run**: tests exist but have no passing run (in the period). - **No test**, **No criterion**: the requirement cannot be proven yet. **No requirement carries it**: the standard is not linked to any record (use Applies to on the standard). - **Exempt** / **Exemption proposed**: an accepted or proposed decision waives the standard for this solution, with who decided and when. A MUST standard cannot be waived. #### For an audit Choose from and to: each test's result is its last run before the end of the period, and only runs within the period prove a criterion. **Only gaps** keeps what needs attention; **Export CSV** gives one row per criterion. The card on the right shows the last code conformance review (get_conformance_checklist and report_conformance). Coding agents ask the same with get_compliance_matrix. ### Baselines Source: https://corpole.com/support/traceability-and-quality/baselines · Traceability & quality 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. #### Taking one Give the moment a name and, if you like, what was agreed. People with the Board WIP limits and locks permission take baselines here; your agent does it with take_baseline. A baseline is kept for good and recorded in the history. #### Comparing - **Since then**: records added, retired or changed (status or text), criteria added, removed or changed (status or statement), work and tests (results) that changed, new decisions, and the key numbers then and now, with maturity. - **Compare with**: pick an earlier baseline, then a later one, to see what changed between two moments — for example between two quarters. - Your agent answers the same with compare_baseline, e.g. "what changed since the offer was accepted?" — useful against scope creep and for delivery notes. ### Audit trail Source: https://corpole.com/support/traceability-and-quality/audit-trail · Traceability & quality 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. #### Asking a question - Choose the period (from and to; the end day is included), then narrow it: a person, an agent, a token prefix, a code, a kind (for example Agent policy and rules, or Access and roles), an action or words. - The cards count the period: changes and agent calls, policy and access changes, refused calls, masked secrets and production emergencies. - **Export CSV** gives every matching entry, with the notes on completeness at the end. - Coding agents ask the same with get_audit_trail: mode exists answers yes or no with the first and last time, mode summary gives the counts. #### What the answer rests on The change history goes back to the solution's start. Agent calls are traced since the call trace began; before that the older access log is used, which does not know whom an agent acted for, so a person filter cannot include it. Full agent answers are kept 90 days, then only their beginning and fingerprint. A redacted value is shown as [redacted] and the redaction is itself an entry. When more entries match than can be read, the page says so. #### Who sees what Workspace owners, admins, auditors and people who manage the solution's integrations see the whole trail. Everyone else sees their own: their changes and the agent calls made for them. Nothing in the trail can be edited. ### Intent Map Source: https://corpole.com/support/traceability-and-quality/intent-map · Traceability & quality 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. #### How to read it | Column | What is there | Linked by | | --- | --- | --- | | Objectives, Business, Stakeholder | Why: the outcome and the needs | A requirement **refines** the one above it | | Solution, Technical | What is to be built or changed: functional, non-functional, solution and technical requirements (what the solution already is lives in its design records) | **Refines**; a technical requirement **realizes** a solution requirement | | Work | Stories and tasks | They **implement** a requirement or **cover** one of its criteria | | Tests | Test cases with their last result | They verify a criterion; shown under the work that covers the same criterion | Click a box to bring its branch forward — everything above and below it. **Hide the rest** leaves only that branch. **Open** goes to the record, work item or test. #### Filters - **Find**: a code or words from a title; each match stays with its whole branch. - **Objective**: only the branch of one objective. - **Authority / Approved / Draft**: which records to show; work and tests follow their records. - **Columns**: turn a column off, for example Stakeholder or Tests, to make the map narrower. - **Hide done work**: leave out stories and tasks that are done. The gap counts follow the filters. **Clear filters** brings everything back. #### Gaps | Gap | Meaning | | --- | --- | | No parent | Nothing above says why it exists: it refines no objective or requirement. | | Not broken down | An objective or business requirement with nothing below it. | | No work | A requirement to build that no story or task implements or covers. | | No test | A requirement with acceptance criteria that no test case verifies. | Choose a gap at the top to light every box with it and the branch it hangs from. Retired records and cancelled work are left out. ### Impact Map Source: https://corpole.com/support/traceability-and-quality/impact-map · Traceability & quality 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. #### What counts as reaching | From the item in the middle | To | Shown as | | --- | --- | --- | | A record | Records that refine, realize or depend on it | refines it · realizes it · depends on it | | A constraint | The records and work it constrains | is constrained by it | | A record | Stories, tasks, epics, work packages and defects linked to it or its criteria | implements it · serves it · delivers it · violates a criterion | | A record | Test cases of its criteria | tests a criterion | | A record or work item | Risks that threaten it | threatens it | | Two records | Each other, both ways | conflicts with · relates to | **What it rests on** reads the same links backwards: what the item depends on, so a change there would reach it. Retired records, cancelled work, obsolete tests and closed risks are left out. #### Using it - Type a code at the top, or click any item on a ring, to put it in the middle. The address keeps the choice, so you can share it. - **1–3 rings** sets how far to look. **Records / Work / Tests / Risks** hides a kind; what lies behind a hidden item still shows. - Hover an item to light the line that brought it there. On a crowded ring items become dots; hover shows the code. - The list on the right says, ring by ring, why each item is there and through which item. **Open** goes to the item in the middle. ### Test cases and traceability Source: https://corpole.com/support/traceability-and-quality/test-cases-and-traceability · Traceability & quality 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. #### How results drive criteria - A test case verifies one or more acceptance criteria — of requirements, or acceptance lines of design records such as `FDR-1A2B3C/AC2`; only **active** tests count. - Any failing active test makes its criteria **Not met**; when all active tests of a criterion have passed, it becomes **Met**. - Blocked or not-run tests leave the criterion as it is. People can still verify a criterion by hand. - A story or task cannot be moved to **Done** while a test of a criterion it covers is failing. #### Regression sets and UAT sessions **Test sets** (Test Cases → Test sets) keep what to run and what is left. A **regression set** belongs to the solution: CorPole fills it with the tests of what changed since a date — changed requirements, work finished since then, changed design records — riskiest first (failed last time, flaky, not run since the change, Authority), each with why. A **UAT session** belongs to an initiative: its requirement criteria become scenarios the business tries, with the role who tries each; write them in the business's words and without real personal data. Record each item as passed, failed or blocked. A test item is also recorded as a run of the test, so its criteria follow; a scenario without a test is the business accepting the criterion, so only a person who may verify criteria records it and the criterion takes the result with the session as evidence. Close the set with its outcome; items not run are counted. The initiative page lists its UAT sessions. Agents use get_regression_candidates, propose_test_set, get_test_set and report_test_set_result. #### History, flaky tests and quarantine Every run is kept. The test page shows the last 14 days as a strip of runs and says whether the test is passing, failing, **regressed** (passed, then started failing), recovered or **flaky** (passed and failed by turns, at least two flips). The Test Cases list counts flaky tests and filters them. A person who verifies criteria can **quarantine** a flaky test until it is fixed, with a reason and an optional review date. It keeps running and its runs are kept, but it is no evidence: its failures do not make criteria Not met or block Done, and while it is quarantined its criteria cannot be Met by their tests — one that was Met by tests goes back to Pending. **Release** it when it is stable; its latest result counts again. Agents read the history with get_test_history and ask the person to confirm quarantine_test in their client. #### Where results come from | Source | How | | --- | --- | | **CI** | POST /api/test-results with a service token (Agents → Agent tokens) that has the propose permission. Tests are named by code or automation reference. Report skipped tests too, and send complete: true for the whole suite: a test that passed and is now skipped or missing raises DRF-06. | | **Coding agent** | propose_test_case registers the tests it writes; report_test_result reports runs. | | **People** | The Passed / Failed / Blocked buttons on the test case page, for manual and UAT tests. | #### Code links Connect the GitHub or GitLab repositories under Solution settings → Repositories and CI. Change requests (pull or merge requests) and commits that mention a story, task, defect or record code in the title, description, branch name or commit message are linked to it. Opening a story's change request moves it to **Code review**; merging it moves it to **Verification**. Links can also be added by hand or by agents (link_code). On GitHub, with the webhook events **Pull request reviews** and **Workflow runs** (or **Check suites**), a review asking for changes is written into the history of the cited work and reaches the people behind it, and so their agent; the CI result of each change request shows next to it in the agent's work context. A CI failure on work in Code review is announced too. A defect that goes to Code review without a test that failed on it gets a warning: fixes start from a test that reproduces the bug. A change request closed without merging sends its work back from Code review to **In progress**. The repository kit also sends test results from CI: on GitHub **corpole-tests.yml** (upload JUnit reports as an artifact named `junit`), on GitLab the CI include. Results go to CorPole after every run, including skipped and missing tests. #### Two traceabilities **Solution → Traceability** shows what the solution is today, proven and located: each design record’s criteria, the tests that prove them, the code modules it describes and the requirements it realizes. **Initiative → Traceability** shows why a change is made and how far it has come: the objective each requirement serves, its criteria, tests and UAT, the work and the code — for the initiative chosen at the top. #### Traceability gaps **No test**: a criterion nothing proves. **No work**: a criterion no story or task covers. **No code**: covering work without a change request or commit. **Failing**: a test of the criterion fails. ### Defects Source: https://corpole.com/support/traceability-and-quality/defects · Traceability & quality 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. #### Workflow **New → Triage → Ready → In progress → Code review → Verification → Fixed** (or Cancelled for duplicates and won't-fix). A defect cannot leave Triage without a **severity**. AI agents move it to In progress and Code review; people verify and mark it Fixed. A defect that is not part of another item goes to the quarter's **maintenance** initiative, unless you or the agent name another; open ones move on to the next quarter's. Defects belong to the solution, so the initiative picker does not hide them. A fix can carry design changes that apply when it is Fixed. | Severity | Meaning | | --- | --- | | **Critical** | Service down, data loss or corruption, security or regulatory breach; no workaround. | | **High** | A main function fails or gives wrong results; workaround is hard. | | **Medium** | A function misbehaves; a reasonable workaround exists. | | **Low** | Cosmetic or minor inconvenience. | #### What it does to acceptance - A defect **violates** requirements or acceptance criteria. While it is open, a violated criterion is **Not met**. - When the defect is Fixed or Cancelled, the criterion goes back to Not verified and follows its tests again: the fix still has to be proven. - A defect cannot be Fixed while a test of a criterion it violates or covers is failing. #### Reporting Use **Report defect** on a failing test case or under an acceptance criterion: the title, steps, expected behaviour and violated criteria are filled in. Coding agents report defects they find with report_defect. ### Risk register Source: https://corpole.com/support/traceability-and-quality/risk-register · Traceability & quality 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. #### Scoring Probability and impact are rated 1–5. Their product is the score: **1–4 Low**, **5–9 Medium**, **10–14 High**, **15–25 Critical**. The matrix shows where the open risks sit; click a cell to list them. Residual scores record what remains after mitigation. #### States and rules | State | Rule | | --- | --- | | **Identified** | Raised; may be unscored. | | **Assessed** | Needs probability and impact. High and critical risks also need an owner and a response. | | **Mitigating** | Needs a mitigation plan or linked mitigating work. | | **Accepted** | Needs the Accept response and an **Accepted decision** linked with “is accepted by”. | | **Occurred** | It happened; handle it as an issue (often a defect or task). | | **Closed** | No longer relevant. | Set a next review date; overdue reviews are flagged in the register and on the Overview. #### Links and agents A risk **threatens** objectives, requirements or work, is **mitigated by** work, requirements or standards and is **accepted by** a decision. Coding agents get open high and critical risks with the work they threaten and can raise new ones with raise_risk. ### Acceptance criteria: Met, Not met, verified Source: https://corpole.com/support/traceability-and-quality/acceptance-criteria · Traceability & quality Criteria are separate items with their own codes and status. Proof comes from a test or a person. #### How they work - Each criterion has a code, e.g. `FR-001/AC2`, and a status: Not verified, Met or Not met. - Changing a criterion's text sets it back to Not verified. - A record's satisfaction is the share of its criteria that are Met. - Design records have criteria too: each acceptance line is one, e.g. `FDR-1A2B3C/AC2`, proven by tests the same way. #### Who verifies - A passing linked test, or a person with evidence. - An agent's report shows as "Agent-reported, not verified" until one of those confirms it. ### Link tests to criteria and let CI report Source: https://corpole.com/support/traceability-and-quality/link-tests-and-ci · Traceability & quality Register each test against the criteria it proves; results then update the criteria. #### Steps 1. Register the test with the criteria it covers (requirement or design criteria) and its automation reference exactly as CI reports it (the agent uses `propose_test_case`). 2. Report runs from CI with a service token, or let the agent report them. 3. Any failing active test makes its criteria Not met; all passing makes them Met. ### The change-request check and the no-requirement label Source: https://corpole.com/support/traceability-and-quality/the-github-check · Traceability & quality Every pull or merge request cites existing, non-retired record codes; trivial changes carry a label instead. #### What it checks - Fails without any record code, with an unknown code, or with a Retired record. A story code alone links the work but does not pass. - Warns on Draft or Approved records. - Skips change requests labelled `no-requirement`. #### The file check - A second job sends the files the change request changes; CorPole needs no GitHub or GitLab credentials for this. - Fails when ungoverned code is changed under the enforced onboarding gate; warns under the advisory one. - Warns about a module whose findings are still under review, files outside the modules of the cited work, other open change requests changing the same files, and a change request during an emergency that does not cite the emergency defect. #### Set it up Run `/corpole:init` (it detects GitHub or GitLab) and add `CORPOLE_TOKEN` with a service token: a repository secret on GitHub, a masked CI/CD variable on GitLab (with the `include:` of `.gitlab/corpole.yml`). ### Onboarding an existing codebase Source: https://corpole.com/support/existing-codebases/onboard-an-existing-codebase · Existing codebases 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. #### Principle Code says what the system **does**, not what it **should** do. So findings describe the solution as it is: each arrives as a **design draft** of the repository's component — FDR for functions, NFDR for qualities and compliance, TDR for technical design (every module becomes a TDR module draft), BDR for business rules — with its origin (**Tested** > **Documented** > **As-built**) and evidence. Objectives, needs and business or project constraints stay requirement drafts. Conflicts between sources become questions; people decide. #### How it works 1. Start onboarding here; CorPole opens the **Onboard …** initiative with its demand, and work during onboarding goes to it. Connect the coding agent with the propose permission. 2. Onboard each repository separately (/corpole:onboard in that repository; the plugin tells CorPole which one). Module paths are per component, so two repositories may both have `src/`. Quick baseline first: modules, stack decisions, glossary, existing tests, conflicts, defects and risks. The agent extracts with commands first to keep token use low. 3. Deep dive per module, typically right before it is changed (govern what you touch). 4. Review the drafts per module: **Confirm as the design**, **Wrong behaviour → defect** (the draft is retired and a defect opened), or **Reject**. A rejected finding is remembered with its reason: agents see it in their brief and cannot submit it again. 5. Agents may submit at most 300 findings per solution per hour, and at most 500 may wait for review; then they stop and ask you to review first. 6. Govern a module once a confirmed design record or an Authority record covers it; finish onboarding when the maturity is good enough. The Onboard initiative then closes if it has no open work. #### Authority tier A solution brought in with existing code starts in the **Shadow** tier: agents read CorPole, but the repository's own sources (CLAUDE.md, documents, ADRs) still lead. Use `/corpole:handover` to move those sources in as proposals, then declare **Shared** and later **Full** on the Solution settings page. With several components each can move at its own pace; the solution's tier is the lowest. #### Advisory or enforced The tenant chooses (Settings → Agent gates). **Advisory**: agents warn and Claude Code asks you before an ungoverned module is changed; finishing with open thresholds needs a reason. **Enforced**: changes to ungoverned modules are refused (MCP and the Claude Code hook) and onboarding finishes only when every threshold is met. ### Authority handover: Shadow, Shared, Full Source: https://corpole.com/support/existing-codebases/authority-handover-tiers · Existing codebases For solutions with existing sources, CorPole takes over authority step by step. #### Tiers | Tier | Agents | | --- | --- | | **Shadow** | Read CorPole, but the repository's sources still lead; conflicts go to you. | | **Shared** | CorPole wins where it has an Authority record; elsewhere the old sources apply and the agent proposes moving them in. | | **Full** | CorPole is the only source; old documents point to it. | #### Rules - Solutions created with existing code start in Shadow; everything else is Full. - A component can have its own tier; the solution's tier is the lowest of them. - Only people who manage the solution's integrations change the tier; each change is kept in the history. - Readiness on the Solution settings page shows whether the next tier is due. ### Move CLAUDE.md, ADRs and docs into CorPole Source: https://corpole.com/support/existing-codebases/move-claude-md-into-corpole · Existing codebases `/corpole:handover` inventories what governs the solution and proposes it as records. #### Steps 1. Run `/corpole:handover`. 2. Review the inventory: rule files, requirement documents, ADRs, glossaries. 3. Review the proposals: rules become standards or rules, ADRs decisions. What a document says the solution does becomes design drafts of the component (FDR, NFDR, TDR, BDR); objectives, needs and business or project constraints stay requirement Drafts. Conflicts come as questions. 4. Confirm the design drafts on the onboarding review page and approve the other proposals that hold; raise the tier when you trust it. ### My agent forgot what we decided yesterday Source: https://corpole.com/support/when-things-go-wrong/agent-forgot-what-we-decided · When things go wrong A decision made in one chat session is gone in the next. Decisions belong in records, not in chat history. #### What happened Yesterday you and the agent agreed on an approach. Today, in a new session, it proposes the opposite as if the conversation never happened. #### Why it happens A chat session is the agent's only memory. When the session ends, what was agreed there ends with it, unless it was written somewhere the next session reads. #### What CorPole does - Keeps decisions, requirements and constraints as records, so they outlive the session they were made in. - Gives the agent what binds at the start of every session: it reads the agent policy, the standards and what changed since it last looked (`get_changes`). - Hands the agent the work context of the item it works on: the why-chain, criteria, constraints and accepted decisions. #### What you do 1. Ask the agent to record the decision you just made: it proposes it with `propose_decision`. 2. Accept the decision in CorPole. From then on it binds for what it governs. 3. Start the next session and check that the agent cites it (the decision's code, e.g. DEC-4F20A1). #### Keep it from happening again - When you agree something in chat that should hold tomorrow, ask for it as a record before you close the session. - Run `/corpole:init` in the repository so the agent reads CorPole first in every session. #### Ask your agent "Record what we just agreed as a decision in CorPole, and cite it from now on." ### My agent followed a decision we had dropped Source: https://corpole.com/support/when-things-go-wrong/agent-followed-a-dropped-decision · When things go wrong An old document in the repository still describes the approach you abandoned, and the agent read it as current. #### What happened You changed direction weeks ago, but the agent rebuilt something the old way, citing a file in the repository. #### Why it happens A file has no state. Nothing tells an agent that an ADR or a note in `docs/` no longer applies, so it treats everything it finds as current. #### What CorPole does - Gives every record a state. A Retired record never reaches the agent's context. - Flags a pull request that cites a Retired record, and the change-request check fails on it. - Tells the agent that only Authority binds; Draft and Approved are informative. #### What you do 1. Find the record that describes the dropped approach and retire it, ideally with a `replaces` relation to the one that holds now. 2. Move the old file's content into CorPole with `/corpole:handover`, so the file stops being an authority. 3. Ask the agent to redo the change against the current Authority records. #### Keep it from happening again - Retire a record the moment it stops applying; do not just edit its text. - Keep direction-setting documents in CorPole rather than in the repository. ### My agent changed a requirement to fit its code Source: https://corpole.com/support/when-things-go-wrong/agent-changed-a-requirement-to-fit-its-code · When things go wrong The code did not meet the requirement, so the agent tried to change the requirement instead. In CorPole it can only propose. #### What happened A test failed against a requirement, and the agent suggested relaxing the requirement so the test would pass. #### Why it happens Agents optimise for a green result. When the requirement is just text they can edit, rewriting it is the shortest path. #### What CorPole does - Does not let an agent edit records. It can only propose a change, which arrives as a difference on the record page. - Keeps the Authority record unchanged until a person accepts the difference, following the edit rules and any second approver. - Treats the solution's design the same way: the agent can only attach a design change to its story, and it applies only when a person marks the work Done. #### What you do 1. Open the record and read the proposed difference and the agent's reason. 2. If the requirement was right, reject the change and ask the agent to fix the code. 3. If the requirement really should change, accept it; the change and its reason stay in the history. #### Keep it from happening again - Give requirements acceptance criteria that a test can check, so "done" is not up for negotiation. #### Ask your agent "The requirement stands. Fix the code so the test passes against FR-… as written." ### The requirement changed while the agent was working Source: https://corpole.com/support/when-things-go-wrong/requirement-changed-while-the-agent-was-working · When things go wrong Someone updated a requirement mid-story, and the agent kept building against the old version. #### What happened Halfway through a story, the product owner changed a requirement it implements. The agent carried on with what it had read an hour earlier. #### Why it happens The agent read the context once, at the start. Without a signal it has no reason to read it again. #### What CorPole does - Notices when a record the agent is working on changes after the agent last read it, and tells the agent in its next reply to read again first. - Lets the agent ask exactly what changed, by whom and why, with `get_changes`. #### What you do 1. Tell the agent the requirement changed, or let the signal do it. 2. Ask it to re-read the work context and say what the change means for the work already done. 3. Decide together whether to adjust or restart. #### Keep it from happening again - Give the reason when you change an Authority record; the agent sees it and can explain the impact. #### Ask your agent "What changed in CorPole since you started this story, and what does it mean for the work so far?" ### The agent says "done" but a criterion is not met Source: https://corpole.com/support/when-things-go-wrong/agent-says-done-but-criterion-not-met · When things go wrong The agent reported the work finished, but a criterion has no proof, or its test is failing. #### What happened The agent reported every criterion as met and moved the story on. The feature does not actually do one of the things it should. #### Why it happens An agent's "met" is a claim. Without a test or a person checking it, nothing stops the claim from being wrong. #### What CorPole does - Refuses a "met" report without evidence. - Shows an agent's unverified "met" as "Agent-reported, not verified"; only a passing test or a person verifies it. - Keeps a story out of Done while a covered criterion is not verified, or while a linked test fails (advisory or enforced, per tenant setting). Design acceptance lines (e.g. FDR-…/AC2) are criteria too, proven the same way. #### What you do 1. Open the requirement and look at each criterion's status and evidence. 2. Link a test to the criterion, or verify it yourself, or mark it Not met. 3. Send the story back to the agent with the failing criterion's code. #### Keep it from happening again - Ask agents to register a test for every criterion (`propose_test_case`) so CI decides, not the agent. - Set the Done gate to Enforced in the tenant's work settings. ### The same test keeps failing Source: https://corpole.com/support/when-things-go-wrong/same-test-keeps-failing · When things go wrong The agent is going round in circles, trying variations of the same fix. #### What happened The agent has changed the code several times, and the same test fails every time. #### Why it happens Without a stop signal an agent keeps trying small variations of an approach that does not work, instead of stepping back or asking. #### What CorPole does - Raises a drift signal after three consecutive failures of the same test on the same story, and tells the agent to change its approach or open a question. - Shows the signal under Agent health, and closes it on its own once the test passes. #### What you do 1. Read what the agent tried; the question it opens often shows the real blocker. 2. Answer the question, or check whether the requirement or the test is wrong. 3. When it is resolved, record the root cause; tick "keep as lesson" so the next agent knows. #### Keep it from happening again - Keep criteria specific enough to test; vague criteria produce tests that fail for the wrong reason. ### The agent wants to run a migration or add a dependency Source: https://corpole.com/support/when-things-go-wrong/agent-wants-to-run-a-migration · When things go wrong Some actions should never happen without a person. The agent policy decides which. #### What happened In the middle of a task, the agent was about to change the database schema, add a package or touch CI. #### Why it happens To an agent, a migration is just another command. It does not know which actions your team treats as sensitive unless you tell it. #### What CorPole does - Keeps an agent policy per solution: each kind of action is allowed, ask first, or forbidden. - Turns the policy into Claude Code permission rules through the repository kit, so the agent stops before the action. - Records a one-off "yes" to an ask-first action in the activity log. A forbidden action stays forbidden, even in an emergency. #### What you do 1. When the agent asks, look at what it wants to run and answer yes or no. 2. If it should never happen, set that action to forbidden on the Solution settings page (Agent policy). #### Keep it from happening again - Set the policy once per solution; tenant and account can set a baseline for every solution. ### Production is down: declaring an emergency Source: https://corpole.com/support/when-things-go-wrong/production-is-down · When things go wrong The fix cannot wait for a requirement. A time-boxed emergency lets the agent fix it now, on the record. #### What happened Production is broken and the agent refuses to change code that no Authority record governs. #### Why it happens The gates that normally keep agents inside approved scope are right on a normal day, and in the way during an outage. #### What CorPole does - Lets a person with the emergency permission (by default the Project lead) declare a production emergency, in the app or by telling the agent. - Opens a time-boxed window (4 hours by default, 12 at most), an urgent demand and an urgent initiative that starts in Implementing (it may exceed the WIP limit; that is recorded), and a critical defect in that initiative; a red Emergency label shows in the app. - While it is open, code gates advise instead of refusing; forbidden actions stay forbidden. The agent names the defect in the pull or merge request. - When the window closes, a follow-up task in the same initiative asks the people who can approve records to write the requirement and test that should govern the fix. - Closes the urgent initiative only with a post-incident review (what happened, why tests missed it, what changes), which becomes a proposed lesson. #### What you do 1. Declare the emergency, or tell your agent to (it will ask you to confirm; it cannot declare one on its own). 2. Let the agent fix it and link the fix to the emergency defect. 3. Afterwards, finish the follow-up task: the governing requirement and a test for it. 4. Write the post-incident review and close the urgent initiative; accept the lesson if it holds. #### Keep it from happening again - Know who in the solution holds the emergency permission before you need it. #### Ask your agent "Declare a production emergency for the checkout outage." ### Agent health shows a warning Source: https://corpole.com/support/when-things-go-wrong/agent-health-shows-a-warning · When things go wrong A drift signal means an agent is going off course. Resolve it with a root cause, and it can become a lesson. #### What happened The Agent health section on the Agents page lists one or more open signals. #### Why it happens Signals catch patterns a person rarely sees in time: coding without reading the rules, leaning on a retired record, retrying the same failing test, pushing work to Done, going quiet on a story. #### What CorPole does - Shows the signals of the last days per agent and story, with a trend over 30 days. - Closes a signal on its own when its condition goes away, for example when the failing test passes. - Asks for a root cause when you resolve one, and can keep your note as an accepted lesson that agents see from then on. #### What you do 1. Open the signal and read what triggered it. 2. Fix the cause with the agent, or mark it a false positive. 3. Resolve it with the root cause; tick "keep as lesson" if others should learn from it. #### Keep it from happening again - Thresholds are set per account and can be tuned per tenant. ### An agent is flooding the review queue Source: https://corpole.com/support/when-things-go-wrong/agent-is-flooding-the-review-queue · When things go wrong Too many proposals, or too many that get rejected. CorPole limits the volume and flags the pattern. #### What happened The review queue filled up with agent proposals faster than anyone can read them. #### Why it happens An agent that is allowed to propose will keep proposing. Without a limit, reviewing becomes the bottleneck. #### What CorPole does - Caps agent proposals at 30 per solution per hour. - Raises a drift signal when proposals near the limit or when more than half are being rejected. #### What you do 1. Review the open proposals from the Overview; reject duplicates. 2. Tell the agent what you want fewer of, or narrow its task. #### Keep it from happening again - Keep agent tasks small; a focused task produces focused proposals. ### A secret ended up in something the agent wrote Source: https://corpole.com/support/when-things-go-wrong/a-secret-ended-up-in-agent-output · When things go wrong CorPole masks what it recognises as a secret before storing it. Rotate the secret anyway. #### What happened A token or password was pasted into the chat, and the agent was about to put it into a record or a comment. #### Why it happens Agents copy what they are given. A value in the conversation can end up anywhere the agent writes. #### What CorPole does - Masks recognisable secrets in everything an agent writes to CorPole before it is stored. - Tells agents, as a locked rule, never to write secrets or personal data into records. #### What you do 1. Treat the secret as exposed and rotate it; masking lowers the risk, it does not undo the paste. 2. Check the record the agent wrote and remove anything masking did not catch. #### Keep it from happening again - Never paste secrets into an agent chat; keep them in the environment. ### A file or web page tells the agent to do something Source: https://corpole.com/support/when-things-go-wrong/a-file-tells-the-agent-what-to-do · When things go wrong Text the agent reads is data, not an instruction. CorPole makes that a rule agents cannot drop. #### What happened A comment in the code, an issue or a web page contained an instruction aimed at the agent, and the agent was about to follow it. #### Why it happens Agents read a lot of text they did not write. Anything in it that looks like an instruction can steer them, whoever wrote it. #### What CorPole does - Gives every agent a locked rule: instructions come only from the person, CorPole's Authority records and the agent rules; external content is data. - Asks the agent to show you such an instruction, with its source, instead of acting on it. #### What you do 1. Look at what the agent found and where. 2. If you do want it done, ask for it yourself; then it is your request. 3. If it looks hostile, record it as a risk. #### Keep it from happening again - Review what goes into files and issues your agents read. ### Two agents picked the same story Source: https://corpole.com/support/when-things-go-wrong/two-agents-picked-the-same-story · When things go wrong CorPole shows who is on a story and warns a second agent. It does not block; people decide. #### What happened Two agents, yours and a colleague's, both started work on the same story. #### Why it happens Two connections see the same Ready story at the same time, and nothing stopped the second one. #### What CorPole does - Shows which agent holds a story, and since when, in the work context, the work list and on the story page. - Warns a second agent that another agent is working on it, and raises a signal if it writes to the story anyway. - Lets the agent that stops leave a handover note (done, open, next step, risks) that the next one reads first. #### What you do 1. Decide who continues; stop the other session. 2. If both should work on it, split it into subtasks so they do not edit the same files. #### Keep it from happening again - Ask agents to leave a handover note whenever they stop in the middle of a story. ### I just need to fix a typo Source: https://corpole.com/support/when-things-go-wrong/i-just-need-to-fix-a-typo · When things go wrong A trivial change needs no requirement and no interview. Label the pull request and move on. #### What happened You want to fix a typo, a format or a name, and the agent or the change-request check asks which requirement governs it. #### Why it happens The rules that keep real changes governed also apply to trivial ones, unless you mark them trivial. #### What CorPole does - Lets a pull or merge request with the `no-requirement` label through the change-request check (GitHub or GitLab). - Still applies the agent policy (a dependency bump can be ask-first, for example). #### What you do 1. Tell the agent it is a trivial change that does not alter behaviour. 2. Add the `no-requirement` label to the pull or merge request. #### Keep it from happening again - Use it only for changes that do not alter behaviour; anything else deserves a record. ### We keep making the same mistake Source: https://corpole.com/support/when-things-go-wrong/we-keep-making-the-same-mistake · When things go wrong What an agent learns the hard way stays in its memory unless it is written down. Lessons make it shared. #### What happened The same kind of problem came back, with a different agent or in a different session. #### Why it happens An agent's memory files are its own. What one agent learned does not reach the next one. #### What CorPole does - Asks agents, at most once a day and at natural pauses, for lessons and improvement ideas. - Imports lessons from an agent's memory files with `/corpole:retro`, after you approve them. - Shows accepted lessons to every agent in the solution; a lesson can be promoted to a solution rule. #### What you do 1. Run `/corpole:retro` after a painful week. 2. Accept the lessons that are true; promote the important ones to rules. #### Keep it from happening again - When you resolve a drift signal, tick "keep as lesson". ### The client asks why we built it this way Source: https://corpole.com/support/when-things-go-wrong/client-asks-why-we-built-it-this-way · When things go wrong Decisions are records with their reasons, and every change keeps who made it and why. #### What happened A client or an auditor asks why the system behaves the way it does, and nobody remembers. #### Why it happens Reasons live in heads and chats. By the time someone asks, they are gone. #### What CorPole does - Keeps decisions (ADRs) with their context and consequences, linked to what they govern. - Keeps the solution's design (BDR, FDR, NFDR, TDR, ADR) as it is today; every version names the work, the requirements and the initiative that changed it. - Traces the chain back to the ask: design version, work, initiative, and the demand that says who asked, how, when and what. - Traces a requirement to its criteria, tests, work items and pull or merge requests. - Keeps an append-only history: who changed what, when, and the reason for every Authority change, whether a person, an agent, GitHub, GitLab or CI. #### What you do 1. Open the design record for the behaviour in question: its versions show which work and initiative changed it. 2. Follow the initiative to its demand, and the requirement to its decisions and relations. 3. Open the change history for the period in question. #### Keep it from happening again - Ask agents to propose a decision whenever a design choice is made. ### A new developer joins mid-project Source: https://corpole.com/support/when-things-go-wrong/new-developer-joins-mid-project · When things go wrong They connect their own agent under their own name and read the same records as everyone else. #### What happened Someone new joins the solution and needs to be productive this week, with their own agent. #### Why it happens Without one place for what binds, onboarding means forwarding documents and hoping they are current. #### What CorPole does - Gives each person their own agent identity (OAuth or a personal token), limited to their own permissions. - Serves every agent the same Authority records, design, decisions, standards and open work, and lists the open initiatives at session start. - Shows the handover notes other agents left on unfinished work. #### What you do 1. Invite them and give them a role. 2. Have them connect their agent and run `/corpole:init` in their clone. 3. Point them to a Ready story in an open initiative; their agent selects that initiative and reads the story's work context first. #### Keep it from happening again - Keep the solution's Start here in CorPole, not in a wiki page that ages. ### I inherited a half-built vibe-coded app Source: https://corpole.com/support/when-things-go-wrong/inherited-a-half-built-app · When things go wrong Onboarding reads the code and drafts the solution's design from it, for people to confirm before anything binds. #### What happened You took over an app built quickly with agents. There are no requirements and no design, just code. #### Why it happens Code shows what the app does, not what it should do. An agent that changes it has nothing to check against. #### What CorPole does - Runs onboarding as the "Onboard " initiative (with its demand), started with `/corpole:onboard`: a quick baseline, then module by module, one repository at a time. - Writes what it finds in the code, documents and tests as design drafts of that repository's component (modules become TDR drafts; behaviour FDR, rules BDR, qualities NFDR), never as binding records. Objectives and needs stay requirement drafts. - Guards modules nobody has reviewed yet: the agent asks first (advisory) or waits (enforced). #### What you do 1. Run `/corpole:onboard` in each repository and review the drafts on the onboarding page. 2. For each draft choose Confirm as the design, Wrong behaviour → defect, or Reject. 3. Leave onboarding when the maturity checks are met; the Onboard initiative closes once its work is done, and new work goes to your next initiative. #### Keep it from happening again - Review a module before the agent changes it. ### Our CLAUDE.md is 800 lines and contradicts itself Source: https://corpole.com/support/when-things-go-wrong/claude-md-is-huge-and-contradicts-itself · When things go wrong Move the rules into CorPole as proposals, resolve the contradictions, and hand authority over step by step. #### What happened The agent rule file grew over months. Rules contradict each other, and nobody knows which still apply. #### Why it happens A rule file has no states, owners or history. Every line looks equally current. #### What CorPole does - Inventories the solution's rule files, requirement documents and ADRs with `/corpole:handover`. - Proposes rules as standards, ADRs as decisions and documents as requirements; conflicts come up as questions, not choices. - Moves authority in tiers: Shadow, then Shared, then Full, where the old files point to CorPole. #### What you do 1. Run `/corpole:handover` and review the proposals. 2. Resolve the contradictions; approve what holds. 3. Raise the tier when you trust the records. #### Keep it from happening again - Once Full, add rules in CorPole, not in the file. ### My agent insists on something Authority forbids Source: https://corpole.com/support/when-things-go-wrong/agent-insists-on-something-authority-forbids · When things go wrong Even when you ask, the agent will not act against an Authority record. It proposes the change and shows who can make it. #### What happened You asked the agent for something that contradicts an Authority record, and it declined. #### Why it happens Authority binds the agent regardless of who asks in chat. That is what keeps agreed requirements from eroding one request at a time. #### What CorPole does - Has the agent stop and name the record it would break. - Records your request as a change proposal to that record. - Tells you who in the solution can change it; if you can, change the record first and the agent follows. #### What you do 1. Decide whether the record is still right. 2. If not, accept the change proposal (or have someone who can accept it), then ask again. #### Keep it from happening again - Keep Authority records current; a stale one will block good work. ### Product feedback Source: https://corpole.com/support/team-and-accounts/product-feedback · Team & accounts Request a feature, suggest an improvement or report a bug, and read replies from the product team. #### Send feedback Choose the megaphone Send feedback button in the top bar to open a dialog without leaving your work. Choose one of the three type cards (none is preselected), review the suggested product area, and enter a short title and optional details. For a bug, choose its impact and explain the steps, expected result and actual result. Do not include passwords or private customer documents. The draft is kept if sending fails. Cancel or Escape closes the dialog and returns focus to its trigger. The form includes the sanitized page path, screen size, language and application version. The four progress metrics show reviewed/released percentages and review/delivery durations; expand How is this calculated? for definitions and sample counts. A summary failure offers Retry without blocking sending. #### Read a reply Signed-in senders find their items and team replies on the separate Your feedback and team replies page linked below the form. The top-bar reply count opens that page; choose Mark replies as read after reading. After sending, the form is replaced by a thank-you and reference number. A visitor receives a private follow-up link once: use Copy and save it, and share it only with someone who may read the thread. Sending feedback does not promise a reply or delivery date. #### Review and delivery Only platform operators open Feedback review. Internal notes stay private. An item is marked Live only when an operator records the production commit, deployment address and what they verified. Public progress shows aggregate recorded decisions, not private submissions. ### Access review Source: https://corpole.com/support/team-and-accounts/access-review · Team & accounts 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. #### Doing a review 1. Look at **Flagged credentials**: not used for 90 days, never used, no end date, acting for someone who left (those are already refused), expired but not revoked. 2. Revoke what is no longer needed on the solution's Agents page; OAuth connections are removed by their owner or with the membership. 3. Check **People**: tenant roles and the solutions each person can read. 4. **Record the review** with the outcome. It is kept with the counts of that moment in the history (Access and roles) and appears in the audit trail. #### When someone leaves **What breaks if they leave?** lists their solutions, the service tokens acting for them (CI stops when they go: create a new token under someone who stays first), the personal tokens and connections that go with the membership, their open work, and the permissions only they hold in a solution (for example the only approver). The tenant's only owner cannot be removed. #### Who can use it Tenant owners, admins and auditors. Coding agents ask the same with get_access_review (optionally for one person) and record the outcome with record_access_review once the person confirms it. ### Time report Source: https://corpole.com/support/team-and-accounts/time-report · Team & accounts Your coding-agent time by day and solution, for an invoice or a weekly report, and the solution's day totals without names. #### My time - **Engaged** hours are the agent working plus waiting for you (up to 15 minutes per wait); longer waits are idle and not counted. - Each day and solution shows the sessions, the codes your agents touched and the work you moved to Done. - Pick the period (default: this month) and **Export CSV** for the invoice. Only you see your time. - Your agent answers the same with get_time_report, e.g. "how many hours did I work on the logistics solution this month?". #### The solution The solution tab shows day totals only: nobody's sessions are named to others, and with fewer than three people using agents even the number of people is hidden. #### What it rests on Claude Code reports sessions through the plugin; other tools' sessions are estimated from their calls to CorPole. Days are Türkiye days and a session counts on the day it started. Session detail is kept 90 days: older sessions no longer say whom they belonged to. ### Maturity settings Source: https://corpole.com/support/team-and-accounts/maturity-settings · Team & accounts 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. #### Three levels | Level | Who | What it may do | | --- | --- | --- | | Platform | CorPole's platform administrators | Sets the strict values and, for accounts, the floors and locks. | | Account | Account owners and admins | Softens down to the platform's floors, never below; sets the floors and locks for its tenants. | | Tenant | Tenant owners and admins | Softens down to the account's floors, or is stricter. Other members can read it. | Open them under ⚙ › **Platform**, **Account** or **Tenant** › Maturity settings. A solution only picks its profile (⚙ › Solution settings). #### What you set - **Thresholds** — the numbers each level's conditions are measured against. Leave a field empty to keep the value from above. - **Dimensions** and **Conditions** — turn a dimension or a condition off. What is kept on above cannot be turned off here. - **How a level is reached** — **Step** (every condition of the level and those below must hold) or **Weighted** (the conditions are met on average for 75%; the step reading stays visible). - **Target profiles** — the target level of each dimension per profile, and the default profile for new solutions. A built-in profile may be lowered one level at most; Regulated keeps Verification and Agent governance at 3 or above. - **Where it shows** — Maturity in the left menu, the summary on the Overview, and the notice when a dimension falls below its target. #### Saving Every change asks **Why this change?** and is kept in the **History** with who made it. A value softer than allowed is saved at the floor, and the page says how many were. Every solution below is measured with the new settings at once. > **Tip:** Softening is never hidden: each solution's Maturity screen also shows the platform's reading and lists every softened threshold and by whom. ### Members Source: https://corpole.com/support/team-and-accounts/members-and-roles · Team & accounts The people in this tenant, their access level, the team of the active solution with its roles, and an access review. #### Access levels (tenant) | Level | Can | | --- | --- | | **Owner** | Every solution and permission, including granting or removing the owner role. | | **Admin** | Every solution and permission except managing owners; invites people, settings. | | **Auditor** | Reads every solution, its history and agent activity; changes nothing. | | **Member** | Only the solutions they are added to, with the permissions of their solution roles; creates solutions (and leads them). | | **Viewer** | Reads only the solutions they are added to. | #### Solution roles In **Solution access**, add people to the active solution and tick their roles (Product Owner, Business Analyst, Architect, Developer, Tester / QA, Risk Owner, Project Lead, or the account's own roles). Their permissions are the union of their roles. Solutions are visible only to the people added, unless a solution is opened to all tenant members (read). The **Declare a production emergency** permission lets a hotfix go ahead before its records exist (Agents → Production emergency). By default only the Project Lead holds it; if your account saved its roles before it existed, add it to the roles that should have it. Roles are defined per account (Account → Roles). The account owner decides whether tenants may change them (Settings → Roles) or must use the account's. AI agents never exceed the permissions of the person they act for. #### Access review Owners, admins and auditors see who reaches which solution with which roles, and when each person last signed in and last changed something. Review it periodically and remove access that is no longer needed. #### How to invite someone 1. Enter their e-mail address and choose a role under **Invite someone**. 2. Copy the link that appears. It is shown only once and no e-mail is sent, so share it yourself. 3. They open the link, sign in or create an account with that address, and join. #### Keep in mind - Links work once and expire after 7 days. A new invitation to the same address cancels the previous one. - A tenant always keeps at least one owner. - Lowering someone to viewer also removes an agent's permission to propose records through their connection. ### Account Source: https://corpole.com/support/team-and-accounts/account-and-tenants · Team & accounts 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. #### Tenants - Each tenant has its own members, solutions, portfolio, settings and knowledge. - Account owners and admins create tenants (the creator becomes the tenant's owner) and give account members access to tenants with a role. - Everyone switches between the tenants they belong to in the menu. #### Shared across tenants - **Account-wide standards and glossary terms**: choose the scope Account-wide when creating them. Every tenant and solution inherits them; only account owners and admins change them. - **Mandatory** standards cannot be waived by a solution decision; use them for bank-wide constraints and regulations such as BDDK and KVKK. - **Account agent policy**: a baseline for every tenant. Tenants and solutions can only make it stricter. - **Agent drift thresholds**: when CorPole flags an agent as going the wrong way (refused actions, test loops, stalled work, proposal floods, forced moves). Tenants may override them. ### Governance across the account Source: https://corpole.com/support/team-and-accounts/governance-across-the-account · Team & accounts For account owners and admins: one view of how the tenants and solutions of the account keep to its line. #### What it shows - **Tenants side by side**: solutions and their authority tiers, members, open drift signals, agent calls in the last seven days, emergencies in the last thirty. - **Agent policy different from the account's line**: every action where a tenant or a solution is stricter than the account, and where. - **Optional rules switched off** by tenants and solutions, with their reason; by people for themselves only as counts — their own choices stay private. - **Solution rules written more than once**: the same rule in two or more solutions. **Lift** creates it as a Draft at the tenant (or at the account when it spans tenants); review it in Agent rules, make it active, then retire the solution rules. Agents of account admins read the same with get_governance_overview. ### Option lists Source: https://corpole.com/support/team-and-accounts/option-lists · Team & accounts 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. #### Who changes what - **Account owners and admins** change the account's lists in Account → Option lists. Every tenant of the account sees the change. - For each list the account decides whether **tenants may change it**. By default they may not. - **Tenant owners and admins** change a list in Tenant settings → Option lists when the account lets them; their changes are laid over the account's. #### What a change does - **Label and description**: records keep the value's key, so old records show the new label too. - **Order**: the order values are offered in. - **Hidden**: not offered any more, still valid on records and in agent calls. - **Retired**: not offered and not accepted for new records; a record that already carries it keeps it. A tenant cannot bring back a value the account retired. - **Add value**: a new category. Its key comes from the label unless you give one; a new risk category belongs to the solution rather than an initiative. - **Reset** removes this level's change, so the value follows the level above again; for a value this level added it removes the value. Forms, the task approval and check settings and the agent tools (raise_risk, propose_work_items, get_standards, the rule and handover tools) all read the same list. #### Tenants with their own version - A tenant that has not changed a value follows the account's change at once. - Where a tenant has its own version, the row shows it. On save the account chooses: **keep the tenants' versions**, **override all** or **override the selected**. Overriding removes the tenant's version. - A **tenant owner** can **protect** a list. An override of a protected list does not apply; it waits in the owner's queue (Tenant settings → Option lists → Waiting for your approval) and the owner gets a notice. - The owner **accepts** (the value follows the account) or **rejects with a reason**. The account sees waiting and rejected overrides and the reasons. #### Changes and undo - Every change is recorded with who made it, when, why (the optional reason) and how it reached the tenants. - **Undo** the latest change to a value: a new change puts the value back as it was. Tenant versions that an override removed are not brought back. ### My ideas Source: https://corpole.com/support/team-and-accounts/my-ideas · Team & accounts 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. #### Private means private - Only you can see your ideas. No role changes that: not the tenant's owners or admins, not the account, not auditors, not shared packages, not someone else's agent. There is no permission to read all ideas. - Nobody is counted: how many ideas a person has appears on no screen, report or metric. - Ideas are encrypted with a key of your own before they are stored, so someone reading the database sees no text. The server can read them so that you can work with them; this is not end-to-end encryption, and operator access to keys is limited and audited. - You can download all your ideas (JSON) and delete any idea for good. If you leave a tenant, your ideas there are deleted, so download them first. - You choose how long your ideas are kept: until you delete them (the default), or deleted after 3, 6, 12, 24 or 36 months without a change. #### Seed and Shaped - **Seed**: one sentence. Not being sure is fine. - **Shaped**: the problem or opportunity, the hypothesis, who benefits, how you would know it works, a cost range, the timing, what it touches. Write the problem and the hypothesis to mark it shaped. - **Park** an idea for later (with a date if you like), **drop** it, or **bring it back**. - A bug is not an idea: report it as a defect in the solution. Defects are not private. #### With your AI agent - By default ideas never go to an AI provider. A tenant owner or admin can allow it (Tenant settings → Private ideas); then each person turns it on for themselves on My ideas. - When it is on, your own agent (a personal token or a connection you authorised) can keep an idea (capture_idea) and read yours back (my_ideas). What you write goes to that agent's provider under your tenant's agreement with it. - These calls are not traced or logged, and no shared package, auditor or service token ever sees the tools. - The tenant can limit which agent clients see the idea tools (Claude, ChatGPT, Gemini, Cursor, VS Code/Copilot, Windsurf, any other). A client is recognised by the name it declares. ### Roadmap indicators Source: https://corpole.com/support/team-and-accounts/roadmap-indicators · Team & accounts 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. #### How to read it - Each wave has a **leading indicator** (it must hold for the next wave to open) and a **stop threshold** (if crossed, find and fix the cause first). They come from docs/ROADMAP.md §8.1. - Readings are due **four weeks** after a wave ended; before that the page says it is too early, but shows the numbers so far. - Choose the tenant to read — CorPole's own tenant, or a pilot customer's. - ✓ met, ✗ not met, · not measurable from the data (for example a production bug, or a gate that rightly refused a move): check those by hand. - The ideas numbers are whole-tenant thresholds only: no number of people below five is shown, and nothing is per person. ### Agent benchmark Source: https://corpole.com/support/team-and-accounts/agent-benchmark · Team & accounts For platform admins: how CorPole changes coding agents' cost and correctness, compared with requirements kept as markdown in the repository — suite by suite. #### What it measures - The same tasks run with Claude Code in two arms: **docs** (requirements in docs/requirements.md) and **corpole** (Authority records read through MCP). Both arms get the same information. - Ordinary tasks are judged by hidden acceptance tests. Trap tasks — a vague criterion, a conflict, an outdated note — by behaviour: **stopped and asked** is correct; building it and flagging it afterwards is not. - The key figure is **$ per correct task**. Medians and the p25–p75 spread come from repetitions; fewer than three repetitions are a sample, not a measurement. - **CorPole tools by context cost** shows which MCP tools return the most text — the first places to trim. - A **regression** is flagged when $ per correct task rises more than 15%, or correctness falls 10 points or more, against the previous suite of the same model. #### Running it node bench/run.mjs --reps 3 --record runs the suite and records it here. A weekly GitHub Actions job does the same once its Anthropic key is configured (bench/README.md). Every run costs money; each is capped. ### Security Source: https://corpole.com/support/team-and-accounts/security-suite · Team & accounts For platform admins: how robust CorPole's security is — each security suite's latest run, what is new or fixed, and the trend. #### The suites - **Authorization matrix:** every MCP tool is called by every kind of principal. No tenant may read another's data, and no viewer, auditor or read-only connection may write. - **Data-level guarantees:** the database itself refuses rewritten history, links across tenants and unsealed private ideas. - **Web and OAuth probes:** headers, the session cookie, sign-in throttling and redirects, and the OAuth server end to end. **Live headers** repeats the header checks, read-only, on corpole.com. - **Static and supply chain:** known-vulnerable dependencies, secrets anywhere in the git history, and insecure code patterns. #### Reading it - Findings are graded **critical**, **high**, **medium** and **low**. A critical or high finding fails the run, and fails a pull request that touches access, data or the web surface. - **New** and **fixed** compare a run with the previous run of the same suite. Open a run to see its findings, the guarantees that held and its notes. - The suites run weekly and on every push to main; the runs from main are recorded here. They seed their own synthetic data and cost nothing. ### AI usage Source: https://corpole.com/support/team-and-accounts/ai-usage · Team & accounts For platform admins: the calls CorPole's own AI features made to the model, per tenant and per feature, with their tokens. #### What is counted - Every call CorPole itself makes to the model: suggestions in the setup, document extraction, drafts from a story, relation suggestions. Each is recorded with its tenant, solution, person, feature and tokens (input, output, cache read). - Coding agents connected through MCP use their own models and their own accounts; they are not counted here. - **Sandboxes** are listed apart and may make 50 calls a day each; after that the feature says the daily allowance is used up. ### Features Source: https://corpole.com/support/team-and-accounts/feature-flags · Team & accounts For platform admins: the flags that bring big changes to people step by step — first chosen people and sandboxes, then everyone. #### How a flag works - **Off** — for nobody. **Chosen people** — only the people named by e-mail. **Chosen tenants** — the tenants ticked, every sandbox, and the people named. **On** — for everyone. - Big changes use a flag: flows decided in an ADR, or ones that change several screens. Small improvements go out directly. - Every change is kept in the flag's history. A flag older than 60 days is marked: open it for everyone and remove it from the code. ### Your theme Source: https://corpole.com/support/team-and-accounts/your-theme · Team & accounts Change any setting of the platform theme for yourself, see it in the preview, then save it in this browser. #### How the page works - The settings are on one side and a **preview** on the other: a small page with a menu, cards, statuses, a table and a form drawn in your draft. The settings scroll; the preview stays in view. On a narrow screen a compact preview stays above the settings, and **Expand preview** shows it whole. - A change is a **draft**: only the preview shows it, the rest of CorPole keeps your saved theme. **Save changes** keeps the draft in this browser (another browser keeps its own) and the page repaints in it; **Cancel** goes back to what you saved; **Reset this level** clears every setting you changed, so the platform's theme applies again once you save. - Each setting shows where its value comes from. **Use inherited value** drops your own value for that one setting and takes the platform's. - **Search theme settings** at the top finds a setting by its name or by why it is not available. - Leaving the page, reloading it or going back with an unsaved draft asks first. Where the browser cannot ask before going back, the draft is kept: when you open the page again, a note offers **Restore changes** or **Discard**. - If your theme was changed elsewhere since the page opened (in the account menu or another tab), the page says so and **Reload** shows it; nothing is overwritten without you seeing it. #### The settings | Group | What it changes | | --- | --- | | **Colour** | The **palette** (search it by name; the **Special** group sets its own frame and light levels), its **centre tone** (what is selected, primary buttons, links and information; each palette suggests one), the **light level** (Light near white, Tinted, Deep, Dark near black; **Follow device** takes Dark on a dark device), **contrast**, **colour amount**, **colour distribution** and the **marker** (centre tone or the palette's accent for selection, focus and links). | | **Surfaces** | The **material** (Opaque, Glass, Gradient, Line or Paper) and **corners**. With Glass its **transparency** and **frosting**, with Paper its **texture**; with another material these rows stay in the list, greyed out, with the material they need. | | **Backdrop** | The small one-colour pattern on the page is the platform's. You may keep its **strength** or turn it off (**None**); with Line there is no pattern. | | **Frame and layers** | The **frame** (the top bar and the left menus' surface) and how the two left menus stand apart: **stacking**, **layer step**, **layer colour**, **layer hue**, **layer contrast** and whether the steps hold on Paper and Line. | | **Type** | The **text size** of every page (Standard, Large, Larger) and the **page title size**. The font pairing is CorPole's and is shown as not offered. | | **Motion** | How much things move when they open and change. **Replay motion** in the preview shows it; with reduced motion on your device, movement stays off whatever you choose. | A setting that does not apply to your other choices stays in the list, greyed out, and says what it needs (for example **Available with Glass**). A value the platform no longer allows is named at the top with a way to it and **Use the inherited values**. Colour carries only a closed list of meanings whatever you choose: negative, attention, positive, information (the centre tone) and neutral. See **Visual language**. ### Theme Source: https://corpole.com/support/team-and-accounts/platform-theme · Team & accounts For platform admins: the one theme every tenant sees, set at runtime without a deploy. #### Setting the theme - The page is Projera UI's theme editor: the settings on one side and a **preview** on the other, a small page with a menu, cards, statuses, a table and a form drawn in your draft. The live pages are not touched; nobody, you included, sees the draft until you save. - Choose the **palette** (search it by name), its **centre tone** and every setting: contrast, material, corners, frame, colour amount and distribution, light, marker; with Glass its transparency and frosting, with Paper its texture; with every material but Line the **backdrop**, a small pattern in one colour on the page, and its strength, which people may only turn off for themselves; the two left menus' stacking, layer step, colour, hue and contrast; the page title size and motion. A setting that does not apply to the other choices stays greyed out and says what it needs; a **Special** palette sets its own frame and light levels. Text size and following the device are each person's; the font pairing is CorPole's. - **Save changes** sets the theme for every tenant at their next page. The **reason** above the editor is optional and kept in the **History** with who saved and what the theme was. **Cancel** goes back to the saved theme; **Use inherited value** on a setting returns it to CorPole's own. - Leaving the page, reloading it or going back with an unsaved draft asks first; where the browser cannot ask before going back, the draft is kept and offered back when you open the page again. - If another administrator saved the theme since the page opened, Save is refused and the page says so; **Reload** shows their theme. Nothing is overwritten silently. - People may still change any setting for themselves on **Your theme**; their choices sit on top of the platform theme and stay in their browser. - Until a theme is saved, CorPole's own applies: the Ocean blue palette on Projera UI's default, that is the Tinted light level, Paper, colour amount 2 over two tones and the accent as the marker. > **Tip:** Colour carries only a closed list of meanings in every theme: negative, attention, positive, information (the centre tone) and neutral. Groups of information have no colour; shapes tell them apart. ### Tenant settings Source: https://corpole.com/support/team-and-accounts/project-settings · Team & accounts Tenant-wide rules for all solutions. Owners and admins can change them. Open it from ⚙ in the top bar. #### Retention How long CorPole keeps what it records about people and agents: the **agent access log** 2 years (then deleted), **full texts of agent calls** 90 days (then the text goes; the call, digest and hash stay), **agent session detail** 90 days (then events go and the person is forgotten; totals stay), **prompt texts** 30 days (then the text goes). Owners and admins can shorten each period down to its minimum, never lengthen it; the daily run applies it. The change history and the records are the audit record and are kept — a value written by mistake is redacted, not deleted. #### Auditor access Owners and admins can let an **auditor** read some or all solutions through their AI client without making them a member: name the auditor and the purpose, choose the solutions (none chosen: all) and the end date (up to 90 days). The token is shown once with one address per solution (…/api/mcp?solution=KEY). It works on the MCP endpoint only and sees read tools only — nothing can be proposed, moved or changed — and every read is logged once in the solution it reads (Audit trail, agent "Auditor …"). The list shows last use and the number of reads; **End access** stops the token at once. The access review lists it as an auditor token. #### Issue trackers (Jira, Azure DevOps) Owners and admins connect the tenant's **Jira Cloud** site (address, a service account's e-mail and API token) or **Azure DevOps** organisation (address and a personal access token with Work Items read & write) once. CorPole checks the credentials and keeps the token encrypted. Every solution whose key or name matches a tracker project is **bound** to it — new solutions too, on the next sync — and the others can be bound by hand. From then on it syncs on its own: the webhook (one for the Jira site; in Azure DevOps one service hook per bound solution) brings changes at once, and CorPole reconciles every 15 minutes. - Epics, stories, tasks and defects become issues (types and statuses follow the editable mappings); the acceptance criteria appear under a marked line of the description. - Title, description, status, owner and parent move both ways. A field changed on both sides since the last sync is a **conflict** that a person settles, here or on the solution's settings. - A status set in the tracker passes the same checks as a move in CorPole, with the permissions of the member with the same e-mail. Moves by people CorPole does not recognise count as automated unless **Trust moves made in the tracker** is on; Done always needs its criteria met and no failing test. When CorPole refuses, it puts the status back and comments why. - A criterion line changed in the tracker becomes a **change proposal** on its record. New issues come into the bound solution's Backlog (switchable); issues deleted there are marked missing, and nothing is deleted in CorPole. #### Task governance Tasks are work without development. Per category (configuration, access, data change, documentation, operation) you can require **approval** before a task is carried out and a **check** by a person before it is Done. Nothing is required unless you turn it on. **Maker-checker**: the requester cannot approve, and whoever carried a task out cannot check it. AI agents never approve or check. #### Work gates - **Definition of Ready:** a story is Ready when it implements an Authority requirement and covers at least one of its criteria. - **Done:** a story or defect is Done when every criterion it covers is Met, confirmed by a person or a passing test — a criterion only an AI agent reported as met shows "Agent-reported, not verified". - **Advisory** lets the move happen and writes what was missing into the history; **Enforced** refuses it and says what is missing. - **Demand** ("no work without a demand"): work is committed — to Ready, or straight to In progress — and an initiative moves to Ready or Implementing only when the initiative answers a demand. Enforced by default; it can be relaxed to Advisory or Off. Initiatives the system opens (charter, onboarding, maintenance, urgent work) always have their demand. Check the effect first under Governance preview. #### Block reasons Work can only be marked blocked with one of these reasons, plus an optional note. One reason per line; leave empty to use the defaults. #### AI agent policy For each action, choose **Allowed**, **Ask first** or **Forbidden**: database migrations, dependencies, CI/CD and infrastructure, security code, changing tests to make them pass, breaking public contracts, merging, pushing to main, deploying and production data; and which CorPole actions agents may take (proposals, results, moving work and more). - CorPole actions are enforced by the server: a forbidden tool call is refused and logged. - Code actions with a command or path pattern become Claude Code permission rules (ask / deny) in the repository kit's .claude/settings.json. - All rules are given to agents with get_agent_policy and in every work context. - Solutions inherit the tenant policy and can only make it stricter (Solution settings). Changes are kept in the change history. #### Agent gates | Gate | Advisory (default) | Enforced | | --- | --- | --- | | Onboarding: ungoverned module | The agent warns; Claude Code asks you before the edit. | Edits to the module are refused until it is governed. | | New solution without any Authority record | The agent offers the kickoff interview first and asks before changing code. | No code changes until at least one record is Authority. | > **Tip:** During a declared production emergency both gates only advise (Agents → Production emergency). #### Agent drift thresholds Override the account's thresholds for this tenant. An empty field uses the account's value, shown as the placeholder. ### You Source: https://corpole.com/support/team-and-accounts/your-page · Team & accounts 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. #### What CorPole sent you **What CorPole sent you** lists the last e-mails and browser notifications CorPole tried to send you and whether the provider took them; when one was refused, the reason is shown (for example an invalid key, or a sender domain not verified yet). **Send me a test e-mail** and **Send me a test notification** try both channels at once. Addresses are kept masked and the list is kept 90 days. #### Suggestions from agents At the right moments your coding agent offers one short "Shall I …?" and acts only if you say yes: settle vague words before building a story (V-01), prove its criteria before review (V-02), check what a change reaches when files carry several requirements (V-03), turn repeated drift into a rule (V-05), go through decisions waiting for you (V-06), draft release notes when an initiative is delivered (V-07), take the tour of a new solution (V-08), answer a repeated question once (V-09), record an undelivered dependency as a risk (V-10); at the end of a session it offers a short summary of what it proposed (V-04). **Important only** (the default) keeps the first kind — rework and waiting decisions — up to three a day; **All** up to eight; **Off** none. The same suggestion about the same thing comes at most once a week. #### Where settings live | Menu | What is there | | --- | --- | | Left menu | Four parts, each answering one question. **Portfolio** — what we change and in which order: the portfolio board, demands, solutions, flow and the tenant and account maturity views. **Initiative** — the change under way, the one chosen at the top: this initiative's page, requirements, boards, work (defects included), planning check, forecast, its risks, decisions and questions, and baselines. **Solution** — what the system is today: overview, design, tests (test cases, known defects, solution risks), knowledge, the maps, traceability, maturity, compliance, changes, audit trail and agents. **Me** — what waits for you: decisions, notices and your sessions. The simple view keeps these parts with the everyday items and puts the rest under **More**. | | Top bar | **Tenant / Solution / Initiative**: choose the solution, and the initiative the Initiative part shows. Without a choice it is the solution's default initiative; **All open** is a choice you make. A note under the title says when a page is filtered, with a link to show all. | | ⚙ in the top bar | Administration, level by level: **Solution** (Solution settings with components, maturity profile, agent policy, repositories and CI, handover; solution access and rules; setup wizard), **Tenant** (tenant settings, members, rules), **Account** (for account owners and admins) and **Platform** (for platform administrators). Only levels you belong to are listed. | | Your initials | What belongs to you whichever solution is open: profile, notifications, your theme and its light level, agent tokens, sessions, prompts and personal rules; sign out. | #### Theme The platform administrator sets one theme for everyone. **Open your theme** goes to **Your theme**, where you change any of its settings for yourself with a preview before you save. The light level also changes at once from your account menu. #### Notifications **E-mail**: a daily digest of decisions waiting for you and an e-mail at once for urgent notices. **Browser notifications**: turn them on in each browser you use. **What you hear about**: mute topics you do not need; decisions waiting for you and emergencies always come through. ### Accounts, tenants and solutions Source: https://corpole.com/support/team-and-accounts/accounts-tenants-projects · Team & accounts Account → Tenant → Solution → Component. What is set higher up applies below; initiatives carry the work. #### A freelancer or agency with several clients Give **each client its own tenant**: its own members, rules, demands, portfolio board and solutions, so one client never sees another's requests or plans. Your account ties the tenants together — switch between them in the top bar, and **My overview** (All my solutions) shows your work across all of them. Keep your own products in a tenant of their own. The time report splits your time by solution and by initiative, for billing each client by change. #### Levels | Level | Holds | | --- | --- | | **Account** | The organisation; tenants; account-wide standards, glossary, agent policy baseline, drift thresholds, roles | | **Tenant** | Its own members, solutions, settings and knowledge; the portfolio of demands and initiatives | | **Solution** | The product or system governed: its components, design, tests, knowledge and agent connections | | **Component** | A part of the solution (web app, mobile app, service): its repositories, code modules and technical design | #### Initiatives An initiative answers one or more demands and holds the requirements and work for that change. Each solution also has a quarterly maintenance initiative for defects. ### Access levels and solution roles Source: https://corpole.com/support/team-and-accounts/access-levels-and-project-roles · Team & accounts A tenant access level says how far someone reaches; solution roles say what they may do in a solution. #### Tenant access levels | Level | Can | | --- | --- | | Owner | Everything, including managing owners | | Admin | Everything except managing owners | | Auditor | Read every solution, its history and agent activity | | Member | The solutions they are added to, with their solution roles | | Viewer | Read the solutions they are added to | #### Solution roles Product Owner, Business Analyst, Architect, Developer, Tester / QA, Risk Owner, Project Lead, or the account's own roles. Permissions are the union of a person's roles. Agents never exceed the person they act for. Reviewing demands and moving or closing initiatives needs the **portfolio.manage** permission (Product Owner and Project Lead have it). ### Maker-checker: a second person approves Source: https://corpole.com/support/team-and-accounts/maker-checker · Team & accounts The person who asks cannot approve, and the person who did it cannot check it. Agents never approve or check. #### Where it applies - Tasks: per category (configuration, access, data change, documentation, operation) you can require approval before and a check after. - Records and changes: follow the edit rules and the roles that may approve. ### Where your data lives, and what leaves your repository Source: https://corpole.com/support/security-and-data/where-your-data-lives · Security & data Records live in CorPole in the EU. Your code stays with you. #### Facts - Data is stored in PostgreSQL in the EU (Frankfurt); the application runs in Frankfurt. - Every agent connection is limited to one solution and is read-only unless the propose permission is granted. - Tokens are stored only as SHA-256 hashes; personal and service tokens expire and can be revoked, sign-in connections can be disconnected. - Agents cannot change or delete records; what they propose stays a Draft until a person reviews it. - CorPole does not read your repository. What reaches it is what agents write (records, proposals, test results, links) and change-request details from a connected GitHub or GitLab repository. - Optional AI help in the setup wizard sends the solution brief and uploaded documents to Anthropic's API; nothing is saved without your confirmation. - Secret-looking values are masked in everything an agent sends. ### Revoke an agent's access Source: https://corpole.com/support/security-and-data/revoke-agent-access · Security & data Revoke a token or disconnect a sign-in; the next call is refused. #### Steps 1. Open the solution's **Agents** page. 2. Personal and service tokens: revoke the token. People with the Integrations permission can revoke anyone's; the owner is notified. 3. Sign-in connections: disconnect under **Connected apps**. 4. If a token may have leaked, revoke it first, then create a new one. #### Automatically revoked - Expired tokens. - Connections of people removed from the tenant. - Connections to a solution that is no longer active. ### What is logged Source: https://corpole.com/support/security-and-data/what-is-logged · Security & data Every agent read and write, and every change to records and work, with who, when and why. #### Two logs | Log | Holds | | --- | --- | | **Agent activity** | Every agent call: agent, identity kind (personal, service, sign-in), time, action, record codes | | **Change history** | Every change to records, design records, criteria, relations, work, knowledge, tests, tokens and roles, and every step of a demand or initiative; the reason for every Authority change; append-only | ### 401 invalid_token Source: https://corpole.com/support/troubleshooting/401-invalid-token · Troubleshooting 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. #### Why it happens - The agent token was **revoked**, or its **expiry date** has passed. - The **solution is not active** (for example, archived). - The token's **owner can no longer read the solution**: their role or solution access was removed. A token never carries more than its owner's permissions. - An OAuth connection was **disconnected**, or its refresh token was reused and the connection was revoked for safety. #### Fix it 1. Using OAuth in Claude Code: run `/mcp`, select **corpole** and choose **Authenticate**. 2. Using a token: open **Agents → Agent tokens** in the solution, create a new personal token and replace the old one where your agent reads it (`CORPOLE_TOKEN` or `~/.config/corpole/token`). 3. If the token belongs to someone who left the solution, ask a person with the integrations permission to create a service token for CI. ### Claude Code shows corpole as failed Source: https://corpole.com/support/troubleshooting/claude-code-shows-corpole-as-failed · Troubleshooting The MCP server is listed but not connected. Usually Claude Code has neither a token nor an OAuth sign-in for it. #### Why it happens The CorPole plugin sends a token when it finds one in `CORPOLE_TOKEN` or in `~/.config/corpole/token`. Without a token it sends none, and Claude Code signs in with OAuth instead. If neither has happened yet, the server shows as failed or needing authentication. #### Fix it 1. Run `/mcp`, select **corpole** and choose **Authenticate**. Sign in to CorPole, pick the solution and approve. 2. Or set a token: create a personal token in **Agents → Agent tokens**, then either export `CORPOLE_TOKEN` in the shell Claude Code starts from, or save it to `~/.config/corpole/token`. 3. Restart the Claude Code session so it picks up the token. #### Adding the server without the plugin `claude mcp add --transport http corpole https://corpole.com/api/mcp`, then `/mcp` → **Authenticate**. ### The agent's proposal was refused Source: https://corpole.com/support/troubleshooting/propose-refused · Troubleshooting propose_record and the other write tools need the propose permission. A read-only connection can read everything its owner can, but cannot propose. #### Why it happens - The token was created **read-only**, or the OAuth connection was approved without the propose permission. - The person behind the connection is a **viewer** in the solution; proposing needs a role that may edit. - The solution's **proposal limit** was reached: agents may add at most 30 records per solution per hour. Review the open proposals and try again later. - **No initiative** could be found for new work or a requirement without a parent. It goes to the named initiative, else its parent's, else the session's choice, else the only open initiative besides maintenance. With several open initiatives and no choice, the tool refuses; defects go to the maintenance initiative unless one is named. - The solution's **no work without a demand** gate is enforced and the work's initiative answers no demand, so the work cannot move to Ready or straight to In progress. #### Fix it - Create a new token with **propose** ticked, or reconnect OAuth and grant propose on the consent screen. - If you are a viewer, ask a solution admin for a role that may edit. - For a missing initiative: tell the agent which one, or let it call `select_initiative` (the choice lasts 12 hours). `get_agent_policy` lists the open initiatives at session start. - For the demand gate: a person with portfolio.manage links a demand to the initiative on the Portfolio board. ### My agent ignores the requirements Source: https://corpole.com/support/troubleshooting/agent-ignores-requirements · Troubleshooting 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. #### Check these first 1. **Is the record Authority?** Draft and Approved records are informative; the agent asks before relying on them. Only Authority binds. What the solution does today is in its **design records** (FDR, NFDR, TDR and the others), which change only when work that carries a design change is Done. 2. **Does the repository say CorPole comes first?** Run `/corpole:init`. It adds a CLAUDE.md section that ranks Authority records above documents in the repository. 3. **Did the agent read them?** Open **Agents → Agent activity** and look for `get_authority_context` or `get_work_context` calls in this session. 4. **Does your client run hooks?** Claude Code with the plugin loads the Authority records at session start. Clients without hooks rely on the agent calling the tools; ask it to call `get_agent_policy` and `get_authority_context` first. #### Ask your agent "Read the binding CorPole requirements for this task before you continue, and cite the record codes you follow." ### My agent sees the wrong solution, or none Source: https://corpole.com/support/troubleshooting/agent-sees-the-wrong-project · Troubleshooting 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. #### Fix it - With OAuth: ask the agent to call `switch_solution` with the solution's key or name, or reconnect (`/mcp` → **Authenticate** in Claude Code) and pick the right solution on the consent screen. - With a token: use a token created in the right solution's **Agents → Agent tokens**. A token cannot switch solutions. - Right solution, wrong initiative: new work goes to the session's initiative. Ask the agent to call `select_initiative` with the right one. - A solution that is not active refuses every connection; see 401 invalid_token. ### "You don't have permission" Source: https://corpole.com/support/troubleshooting/you-dont-have-permission · Troubleshooting 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. #### Reading the refusal - It names the **permission** that is missing. - It lists **up to three people** in the solution who hold it. - It says **where in CorPole** the action is done, so the right person can do it or grant it. #### Things no agent can do Some actions are always a person's: making a record Authority, accepting a decision, moving work to Done, merging, and changing the agent policy, permissions or thresholds. An agent that is refused one of these should tell you where to do it. ### The change-request check fails (GitHub, GitLab) Source: https://corpole.com/support/troubleshooting/github-check-fails · Troubleshooting The CorPole check wants every pull request (GitHub) or merge request (GitLab) to cite at least one existing, non-retired record code. #### Why it fails - The pull request cites **no code** at all. - It cites a code that **does not exist**. - It cites a **Retired** record. A retired decision cannot come back through a merge. - It warns, without failing, when a cited record is only **Draft** or **Approved**. - The **file check** fails or warns on changed files: code no record governs, modules still under onboarding review, overlap with other open work, or a change made under an emergency. #### Fix it - Put the record code in the title or description, e.g. `FR-7C21A4`. A story code such as `ST-1A2B3C` links the work to the change as well, but the check itself needs the code of a record the change implements. - For a change that no requirement governs (a typo, formatting, a rename, a dependency patch) add the label `no-requirement`. It must not change behaviour. - If the check cannot reach CorPole at all, the token is missing or revoked: the repository secret `CORPOLE_TOKEN` on GitHub, the masked CI/CD variable `CORPOLE_TOKEN` on GitLab. A person with the integrations permission creates a service token for it. - On GitLab, check that `.gitlab-ci.yml` includes `.gitlab/corpole.yml` and that the pipeline runs for merge requests. ### Test results don't show up on the criteria Source: https://corpole.com/support/troubleshooting/test-results-missing-on-criteria · Troubleshooting 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. #### Check these 1. The test case is **linked to the criterion** (for example `FR-001/AC2`, or a design acceptance line such as `FDR-7C21A4/AC2`), not only to the record. 2. Its **automation reference** is exactly the name CI reports for the test. Registering the same reference again updates the test case. 3. Results are reported for that test: by CI, or by the agent with `report_test_result`. 4. The test case is **active**; obsolete tests do not count. #### How criteria follow tests Any failing active test makes its criteria **Not met**; all passing makes them **Met**. A story with a failing test cannot be moved to Done. ### Architecture Source: https://corpole.com/support/reference/architecture-model · Reference 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. #### Elements - Every element has an ArchiMate **type** (Strategy, Business, Application or Technology layer, or Grouping and Location), a **level** — conceptual, logical or physical — a **status** (current, planned, retired) and an **origin** (written, discovered, imported). - **Components, repositories and code modules** appear by themselves: a component is a physical Application Component, a repository or code module an Artifact that realizes its component. Their name comes from the row; deleting the row retires the element. - Capabilities, value streams, resources and courses of action belong to the **tenant** — the organisation's capability map — and solutions support them. Other shared parts (a core banking system, an identity provider) can belong to the tenant too. - The form offers the usual types; **Show every ArchiMate type** opens the full language. - Discovered elements count separately until someone with architecture.approve **verifies** them. #### Relations - Relations are ArchiMate's: composition, aggregation, assignment, realization, serving, access (read, write), influence, association, triggering, flow, specialization. - CorPole checks each one against ArchiMate's rules for the two element types and refuses an invalid one with the reason. The rules follow the specification's metamodel; CorPole uses ArchiMate-compatible language and is not a certified tool. - The chain from concept to code is built with **realization**: Business Object ← Data Object ← Artifact; Application Component ← Artifact (repository, code module). #### Discovery - Your agent reads the repository and reports what it finds: infrastructure as code, deployment definitions, API definitions, connection settings (never secrets) and dependency manifests. In Claude Code run **/corpole:architecture**; other agents use the report_architecture tool. - It can also **propose** conceptual elements — capabilities, business processes, business objects — with the links it sees. Proposed capabilities go to the tenant. - Everything arrives **discovered** and waits under **Discovered, waiting for review**: verify or discard in bulk. A component's, repository's or module's element can only be verified. - When a run covers a whole source, CorPole compares it with the confirmed model: a confirmed part that is gone opens **Architecture part missing** (DRF-24); a new part where the model was confirmed opens **Architecture part not in the model** (DRF-25). They appear with the other drift signals on the Agents page. - A confirmed element keeps the name and type a person confirmed; a later run only refreshes its description. #### Who changes what - A solution's elements: **architecture.edit** (the Architect role has it); verifying and retiring: **architecture.approve**. - The tenant's elements: tenant owners and admins, and account owners and admins. - Every change is in the change history (kind Architecture). ### Visual language Source: https://corpole.com/support/reference/visual-language · Reference The reference for colours, light levels and icons used across CorPole. #### How to read it - Colour carries a closed list of meanings: **Negative** (not met, errors, destructive actions, risk), **Attention** (something to review or handle with care), **Positive** (met, done), **Info** (the theme's centre tone: what is selected, primary buttons, links) and **Neutral** (everything else). - Groups of information (Intent, Requirements, Constraints, Verification…) have no colour of their own; risk alone reads the negative meaning. - Every entity type has its own shape with its abbreviation inside, in the text colour of the surface it sits on. Hover an icon to see its name. - The theme is the same for everyone and is set by the platform administrator. Each person chooses its **light level** in the account menu at the right of the top bar: **System** (dark when the device is dark), **Light** (near white), **Tinted** (the default), **Deep** (more colour) or **Dark** (near black). The choice stays in this browser. - The groups of the left menu and the **Administration**, **Help**, **Notices** and **Sign out** buttons carry one icon per meaning, shared with Projera's other products. No icon stands for two things: the same picture always means the same place. - **Relationships** lists the relation types, which record types each one may connect, and the rules that block or warn. > **Tip:** Planned groups and types already have a shape reserved, so the language stays consistent as new entities arrive. ### MCP tools Source: https://corpole.com/support/reference/mcp-tools · Reference Every tool the CorPole MCP server offers, the permission it needs and what it does. The server is at https://corpole.com/api/mcp. #### Tools | Tool | Access | What it does | | --- | --- | --- | | `get_authority_context` | Read | Every Authority record of the solution, grouped by type, with its acceptance criteria and their status, plus the agent instruction. Agents call it before writing or changing code. | | `search_requirements` | Read | Keyword search in title, code, statement and acceptance criteria. Defaults to Authority and Approved; Retired only on request. | | `get_record` | Read | Full detail of one record: state, statement, rationale, each acceptance criterion with its code (e.g. FR-001/AC2), status and evidence, satisfaction, owner, source, and unlinked technical requirements with similar wording. For a direction it also says whether it is in force and its chain (replaces, replaced by, or withdrawn with the reason). Also reads a decision, a question or another knowledge item of the solution by its code: type, state and text; for a decision who is said to have decided (marked as the relaying agent's claim) and how a person settled it — accepted or rejected, by whom, when and how, or "not theirs" said on its card; for a question its answer. | | `get_work_context` | Read | The context slice for one record or work item: acceptance criteria, the why-chain, realizing technical requirements, dependencies, constraints (linked and solution-wide), technical requirements that realize no requirement (the closest in wording with their statement), open conflicts, replacements; for work items also the theme → epic → story/task → subtask chain, the work package and the implemented requirements (inherited from the nearest parent when an item has none). | | `list_work_items` | Read | Themes, epics, work packages, stories, tasks and subtasks with status, parent and the requirements they implement, e.g. the stories that are Ready. Stories are work that involves development; tasks are work without development. | | `update_work_status` | Write (propose permission) | Moves a work item along its workflow: stories to In progress or Code review, tasks to In progress or Check, subtasks to Doing or Done. Approval, verification, check and Done are decided by people. | | `get_standards` | Read | Standards that apply to the solution (tenant-wide and solution; waived ones listed separately), with must/should enforcement. | | `search_knowledge` | Read | Search decisions, questions, glossary terms, standards and references. | | `ask_question` | Write (propose permission) | Records an open question with the working assumption, linked to what it concerns. | | `propose_decision` | Write (propose permission) | Proposes a decision the agent itself makes within what it may decide (an architecture or design choice, ADR); binding only once a person accepts it. A decision the person or someone else stated is recorded with record_decision instead, which keeps who decided and how. | | `propose_relation` | Write (propose permission) | Proposes a typed relation (refines, realizes, constrains, replaces, conflicts_with, relates_to). A person confirms it on the record page. | | `create_project` | Write (propose permission) | Creates a solution for the user in their workspace and switches an OAuth connection to it. An existing codebase starts onboarding; a new idea starts the kickoff interview. Under guided start CorPole asks the person in their AI client "Create the solution \"\" in ?": their yes creates it, a no creates nothing. A client that cannot ask creates it as before, and the history records that the name was the agent's word (channel agent_stated). archetype (multi_tenant_saas, internal_tool, consumer_app or api_service) is only the agent's suggestion and is never stored: the answer tells the agent to put the solution type to the person as a question with the four types and their consequences, its suggestion recommended (FND-Q1); the person can also choose it in Solution settings. The answer then names the preparation: "Next: its preparation (get_setup_brief): the solution brief, the solution type and the mode come first." | | `get_setup_brief` | Read | The kickoff interview for a new solution: interview rules, the steps with why and an example, what exists so far and what comes next. | | `submit_setup_records` | Write (propose permission) | Stores one confirmed kickoff section: solution brief, Draft records with criteria and links, open questions. Nothing binds until a person approves it. Where the person's client can ask them, the section is confirmed there first; a section whose summary is too long to show whole in that question is not stored — send it in smaller parts or with shorter titles. | | `propose_change` | Write (propose permission) | Proposes a change to an existing record. Nothing is applied until a person accepts the difference on the record page; accepting follows the edit rules. | | `get_package_brief` | Read | The shared work package, masked: what to do, criteria and how they are checked, constraints, standards, agent policy. The first call of a package token. | | `get_regression_candidates` | Read | The tests to run again after what changed since a date (changed requirements, finished work, changed design records), riskiest first with the reasons; quarantined tests left out. | | `propose_test_set` | Write (propose permission) | Keeps a regression set of the solution or a UAT session of an initiative (filled with its criteria with from_initiative). People run it on one page. All or nothing. | | `get_test_set` | Read | A test set's items in order with roles and results so far, and its outcome once closed. | | `report_test_set_result` | Write (propose permission) | Records the result of a test item of a set, also as a run of the test. UAT scenarios without a test are recorded by people. | | `get_test_history` | Read | Recent runs of a test and whether it is passing, failing, regressed or flaky; the same for every test of a criterion; or the solution's flaky and quarantined tests. | | `quarantine_test` | Write (person confirms; criteria.verify) | Quarantines a flaky test until it is fixed, or releases it. A quarantined test keeps running but is no evidence: its failures do not block, and its criteria cannot be Met by it. The person confirms in their own AI client, where the reason and the review date are shown; a reason too long to show whole is not asked and nothing changes. A service or package token never asks. | | `propose_bulk_change` | Write (propose permission) | Proposes the same change to many records with one reason, e.g. after a decision or a change in a regulation. All or nothing; people decide them together on one page or record by record, each under its record's rules. | | `get_change_batch` | Read | A bulk change proposal: its reason and source, and whether each record's change is open, accepted, rejected or superseded. | | `propose_work_items` | Write (propose permission) | Proposes epics, stories, tasks and subtasks into the Backlog. The agent can start one only after a person has moved it to Ready. The answer notes when their initiative answers no demand, so they cannot be committed under the enforced demand gate. | | `get_handover_brief` | Read | The solution's authority tier (Shadow, Shared, Full) and how to move agent rule files, requirement documents and ADRs into CorPole as proposals. Only a person changes the tier. | | `declare_emergency` | Write (emergency.declare) | Opens a time-boxed production emergency when a person allowed to declare one says so: code gates advise instead of refusing, forbidden actions stay forbidden, a defect tracks it. | | `get_repo_kit` | Read | Files that make a code repository treat CorPole as its requirements authority (the CorPole block in CLAUDE.md and AGENTS.md, pointer files for Gemini, Copilot and Cursor, team plugin settings, and the provider's change-request template and CI check: GitHub PR template and Actions, or GitLab merge request template and CI include). | | `propose_record` | Write (propose permission) | Adds a Draft marked as an AI proposal, with its acceptance criteria as separate items. Not binding until a person approves it. Limited to 30 per solution per hour. | | `report_acceptance_result` | Write (propose permission) | Records whether one acceptance criterion is met, with evidence. People see which agent reported it and can override it; the record's satisfaction updates. | | `get_agent_policy` | Read | What agents may do on their own, only after asking, or never (migrations, dependencies, CI/CD, merging, deploying, production data…), and the agent rules in force for this person. Called once per session. | | `get_changes` | Read | What changed since a moment: records, criteria, relations, work items, knowledge, tests and code links, with who, the field changes and the reason. Without since: since this agent last asked. | | `check_code_area` | Read | Before changing files: whether they are governed. During onboarding an ungoverned module is refused (enforced) or needs the user's agreement (advisory); a solution without any Authority record is treated the same until the kickoff has produced one. | | `get_onboarding_brief` | Read | How to bring an existing codebase under governance: the discovery protocol, the source trust order, the current modules and the maturity. | | `submit_onboarding_findings` | Write (propose permission) | Submits what was found in an existing codebase in one batch. Everything arrives as Drafts or proposals for people to review. | | `leave_handover_note` | Write (propose permission) | Leaves a note on an unfinished work item for whoever continues it: what is done, what is open, the next step. Shown at the top of get_work_context. | | `link_code` | Write (propose permission) | Attaches a pull request, commit, branch, file or CI run to a story, task or record. Connected repositories link pull requests that mention the code automatically. | | `propose_test_case` | Write (propose permission) | Registers a test that proves acceptance criteria. The automation reference must match how CI reports the test, so results update the criteria. | | `report_test_result` | Write (propose permission) | Reports one test run: passed, failed or blocked. Any failing active test makes its criteria Not met; all passing makes them Met. | | `report_defect` | Write (propose permission) | Records behaviour that breaks a requirement or criterion. Violated criteria become Not met until the defect is fixed and verified; people triage it first. | | `raise_risk` | Write (propose permission) | Records a risk in the register. It starts as Identified; people score it and decide the response. | | `submit_retrospective` | Write (propose permission) | Records lessons learned and improvement ideas. CorPole asks for this at most once a day. | | `submit_handover_inventory` | Propose | Records the sources that govern the solution outside CorPole (agent rule files, requirement documents, ADRs, glossaries, tickets) with their size and status: to move, moved, historical or staying outside. Rows are matched by path. Answers with the readiness for the next authority tier. | | `proceed_without_kickoff` | Propose (records.authorize) | For a new solution without Authority records: records that the user chose to build without the kickoff interview, with the reason. The code gate stops asking and agents stop offering the interview until the first Authority record; a person can withdraw it on Solution settings. | | `propose_rule` | Propose (knowledge.edit) | Proposes behavioural rules for agents on this solution — from an agent rule file, a recurring lesson or the conversation — as Draft solution rules. Rules already in force or proposed in other words are skipped. They apply only after someone who manages the solution's integrations activates them on the Rules page. | | `select_initiative` | Write | Chooses the open initiative this session's new work and requirements go to (12 hours); without a code it lists the open initiatives and the current choice. | | `switch_solution` | Write | The same as switch_project, named for the delivery model: moves an OAuth connection to another solution. | | `switch_project` | Write | Moves an OAuth connection to another solution the user can open; every switch is written to both solutions' history. A token belongs to one solution: for a token connection the answer links the page where the user creates a token for the other solution. | | `what_do_we_have` | Read | Does the solution have it: matching requirements with their state, whether work built them and tests prove them, related decisions, lessons and questions, and work that mentions it without a requirement. | | `explain_change` | Read | Why something exists: the requirement it serves and the chain above, who asked and approved, decisions behind it, and the reasons agents gave when linking the code. | | `check_readiness` | Read | Ready / Not ready for a work item or record, criterion by criterion: met, tested, failing tests, open defects, tests older than the criterion, open questions, conflicts, vague wording. | | `review_requirements` | Read | Quality and coverage scan: vague wording with no question, missing criteria, binding criteria with no test, conflicts, likely duplicates. | | `review_test_fit` | Read | Each criterion next to its tests with steps and automation, and warnings for stale, loosened or often skipped tests — for the agent to judge. | | `report_test_fit` | Propose | Records the agent's verdict on a criterion ↔ test pair in the test's history; a poor fit reaches the people who verify criteria. | | `get_conformance_checklist` | Read | What the code must conform to: binding constraints, non-functional and technical requirements, active standards — narrowed to a path's module. | | `report_conformance` | Propose | Records a conformance review's table in the solution history; deviations reach the integrations owners. | | `get_impact` | Read | What a change to a record reaches: open work that implements it or covers its criteria, the tests of its criteria, open pull requests of the record or that work, and the records that refine, realize or depend on it. | | `persist_instruction` | Propose | Keeps what should bind others in the solution: a Draft solution rule, constraint, standard or glossary term for approval. A personal working preference is not sent here — the agent keeps it in its client's own memory; a personal rule is kept in CorPole only when the person asks for it or the client has no memory of its own, and is then a Draft they turn on under Personal rules (in force at once only when they confirm it in a question their client shows them). What the agent says about the person's yes is not read. With direction true it records a direction exactly as record_decision does (the person's sentence word for word, waiting on its card). A permission (policy) is explained, not set. | | `set_working_mode` | Propose | Switches a ready-made working mode on or off — plan first, small steps, analysis only, tests first, smallest change, challenge me — for the person at once, or as a Draft solution rule. | | `get_decision_queue` | Read | What waits for the person's decision in the solution, by their permissions: agent drafts, change proposals, proposed decisions, open questions, proposed solution rules — with content, proposer and age. | | `prepare_decisions` | Propose | Stores the agent's short summary and recommendation per waiting item for the person's "Waiting for you" screen, where the person decides in one pass. Decides nothing. | | `answer_question` | Propose | Passes on the person's answer to an open question. Where the person's client can ask them, they confirm the exact answer there and it is recorded as theirs (confirmed in the client). Otherwise — also when the answer is too long to show whole in the client — it is kept as the agent's suggested answer, the question stays open, and the person applies it on the "Waiting for you" screen. The agent's word never makes an answer the person's. | | `record_decision` | Propose | With kind direction: records a direction — which way the work goes from now on — as the person's sentence, word for word (at most 600 characters; no context, governs_codes or priorities), with the scope this solution; the agent does not ask about making it permanent. The sentence is one line; the white space around it is cut. The same statement the person accepted themselves within the last 24 hours — on the screen or in the client — (same title, text, decider and channel) is answered Accepted already: nothing is stored (after an accept in the client the person is not asked again either), and governs_codes or priorities the accepted decision lacks are not added (the answer says so and where the person adds them); later, or with another decider, it is a new decision. A statement a person called not theirs on its card is not stored again with the same title, sentence, decider and channel — a context, governs_codes or priorities added to it do not make it another statement; the same holds for Accepted already, and an open proposal of the same statement is returned as it is with a note that the added context was not stored, and relayed decisions take the hourly proposal limits (30 by one agent in a solution, 100 by all agents). A direction's sentence that looks like it holds a secret or personal data (an access token or key, a password, an address with a password, a card number, an 11-digit identity number) is refused, not masked: nothing is stored and the answer says what it looks like. In a solution under guided start an unconfirmed decision or direction opens its own card on Waiting for you (Confirm, Correct the wording, This is not mine), and the answer gives the card's address. A direction that resembles one in force is not asked in the client: replacing it or keeping both is the person's choice on the card (Confirm and replace, Confirm keep both), and the answer says so. Records a decision taken in the conversation, a meeting or by someone outside, with who decided and the channel. Accepted only when the person may decide and confirms the exact wording in a question their client shows them; otherwise — also when it is too long to show whole in the client — it is stored as a proposed decision on the agent's word, with who decided kept as the agent's claim, and a person accepts it on the screen. The same statement sent again is not stored twice, and an accepted call sent again changes nothing. An accepted call is "the same" only with exactly the same content; a corrected one the person confirms again is another decision. title and decided_by are one line each (line breaks, control characters and text-direction marks are refused). An accept stores the decision, its governs links and its priorities together or not at all; sent again after the decision was rejected or deleted on the screen, it writes nothing and says what the decision is now. Only the person's own connection (personal token or sign-in) is asked; a service or package token always leaves a proposal. Work priorities the decision names change only with the person's confirmation in the client; for a proposed decision they are never applied and the person sets them on the work items. The agent's word never makes a decision the person's. | | `get_my_overview` | Read | Every solution the person can read, each in its own section: work in progress for them, decisions waiting, dates due in two weeks, maturity below target, serious issues; then the next two weeks across solutions. Each solution read is logged in that solution. | | `get_portfolio` | Read | Old name of get_my_overview, kept as an alias. "Portfolio" now means the Lean Portfolio (get_portfolio_board, get_flow_metrics). | | `get_status` | Read | For a person's own connection it lists the directions in force (code and sentence, newest first), or says none is in force. Status brief. For me: what others changed since my last change, where I left off, what is blocked or failing on my work, what waits for me. For the solution: progress, decisions waiting, serious risks, drift, bottlenecks, maturity below target. For the team: people and their open work, agents waiting, alerts. | | `get_maturity` | Read | Where the solution stands on seven dimensions (intent, requirements, verification, delivery, agent governance, codebase, decisions and knowledge) against its target profile, with at most three next steps. | | `approve_records` | Write (the person confirms in their client) | Moves records to Approved only after the user confirms in their AI client (MCP 2026-07-28 elicitation), with the user's own permissions and the board's checks. Making a record Authority is refused here: it binds every agent, so the person does it on the screen (the requirements board), where they read what the record says; the question in a client shows only its code and title. The confirmation counts for the records as they were when asked (type, priority, state, title, statement, rationale, acceptance criteria): one changed before the answer is asked again, and one changed while the approval is being written is reported as "changed while you were confirming; not approved". A list too long to show whole in one question is refused (approve fewer at once, or on the board); nothing is cut. Clients that cannot ask, and service or package tokens, send the user to the review board. | | `get_audit_trail` | Read (whole trail: integrations, owners, admins, auditors; others their own) | Changes and agent calls of a closed period in one timeline; exists answers yes or no with the first and last time, summary gives the period's security counts; every answer says what it rests on. | | `get_access_review` | Read (tenant owners, admins, auditors) | Members, solution access and agent credentials with unused, open-ended and orphaned ones flagged; for one person, what breaks when they leave. | | `record_access_review` | Write (tenant owners, admins, auditors) | Records that an access review was done, with the outcome and the counts of that moment, in the history and the audit trail. | | `get_compliance_matrix` | Read | Standards and binding requirements down to records, criteria, tests, results and exemptions, each Proven, Failing, Not run, No test, No criterion, Exempt…; for an audit period only runs within it prove a criterion. | | `get_time_report` | Read (me: only your own) | Agent session time by Türkiye day and solution: engaged, working, waiting and idle time, touched codes and finished work for you; day totals without names for the solution. | | `take_baseline` | Write (project.plan) | Names this moment and freezes records, criteria, work, tests, decisions and key numbers, to compare against later. | | `compare_baseline` | Read | What changed since a baseline (or between two): records, criteria, work, tests and decisions added, removed or changed, and the numbers then and now; lists baselines without arguments. | | `assess_request` | Write (members; save false = read) | Splits a request into its asks and compares each with the solution (New, Already there, Partly there, Retired before, May conflict), and records it as a demand in the Funnel with the assessment kept on it; received_at keeps the day it came in, and the answer names similar open demands. demand re-assesses an existing one (members only; the assessments against other solutions stay), save false only previews. | | `list_design_records` | Read | The solution's design today by kind (BDR, FDR, NFDR, TDR, ADR), with version, drafts to confirm and pending changes. | | `get_design_record` | Read | One design record: description, acceptance, versions with the work, requirements and initiative behind each, and pending changes. | | `propose_design_delta` | Write | Records the design change an open work item carries (add, change, retire); applied as a new version when the work is Done. Warns when other open work changes the same record. | | `get_flow_metrics` | Read | Flow time of demands and initiatives (median, 85%), flow efficiency, load per step against WIP limits, distribution by capacity type, velocity per week, and the step where work waits longest. | | `get_defect_trail` | Read | What a defect violates, its tests' last pass and first failure, and the recent changes that most likely caused it, ranked with reasons. | | `get_release_notes` | Read | What an initiative delivered: demands answered, design changes, delivered work, fixed defects, known limitations. | | `get_evidence_pack` | Read | The proof behind an initiative: requirements, criteria, tests and latest results, approvals, design changes with provenance, change requests with CI and reviews, what is still open. | | `get_portfolio_board` | Read | The Lean Portfolio Kanban: unlinked demands, initiatives by step with mode, stage, days in step, work finished/total, solutions and demands; WIP limits. | | `get_initiative` | Read | One initiative: mode, step, capacity, demands, solutions, work with open items, and the steps it may move to (Done only when all its work is closed). | | `list_demands` | Read | The workspace's demands with step, days in the step and linked initiatives. | | `get_demand` | Read | One demand: request, requester, channel, step, initiatives and the solutions they change, kept assessment. | | `check_planning` | Read | Which candidate items would pass the Ready gate and what each still lacks (requirement and criteria, triage, description, dependencies, blocks, open questions), and the active and Ready load per person and agent. | | `preview_governance_change` | Read (integrations, owners, admins, auditors) | What a gate, agent permission or code rule change would do before it is made: refused or freed moves and calls of the last 30 days, items stopped today, solutions whose level changes. Changes nothing. | | `get_my_signals` | Read | The connection's own open drift signals with why each matters, and the solution's accepted lessons. | | `get_project_tour` | Read | A tour for someone new: problem and objectives, binding decisions and standards, agent rules, glossary, open questions, where the work is, who is in it. | | `get_metrics` | Read | MET-01…10 of the solution with targets and what each counts. | | `track_requests` | Read | What came from one person, unit or customer and where it stands: records requested by them with build and test state, decisions they took, records they own or that mention them, questions and work naming them. | | `get_forecast` | Read | When the remaining work of the solution or one item with everything under it is likely done (50% and 85%), the chance of a target date, what slows it down, a pull-forward what-if and due dates against actual finish. | #### Permissions Read tools work on every connection. Write tools need the **propose** permission, and never make anything binding: they add Drafts, proposals or evidence for people to review. `declare_emergency` also needs the person to hold the emergency permission. ### Claude Code plugin commands Source: https://corpole.com/support/reference/plugin-commands · Reference The slash commands the CorPole plugin adds to Claude Code. #### Commands | Command | What it does | | --- | --- | | `/corpole:start` | Start a solution with CorPole: create it if needed (with its charter initiative and demand), then run the kickoff interview so the solution has binding requirements before code is written. | | `/corpole:onboard` | Onboard an existing codebase as the "Onboard " initiative: reverse-engineer modules, behaviour, data, tests and decisions as design drafts of the repository's component, for people to confirm, turn into defects or reject. Run it once per repository. | | `/corpole:handover` | Move what currently governs the solution (CLAUDE.md and other agent rule files, requirement documents, ADRs, glossaries) into CorPole as proposals. | | `/corpole:init` | Set up the repository so Claude Code and other coding agents treat CorPole as the requirements authority: the CorPole block in CLAUDE.md and AGENTS.md, pointer files for Gemini, Copilot and Cursor, team plugin settings, and optionally the change-request template and CI check for GitHub or GitLab. | | `/corpole:context` | Show the binding requirements for the solution, optionally filtered by topic. | | `/corpole:check` | Check the current changes against the solution's Authority requirements. | | `/corpole:retro` | Record lessons learned and improvement ideas, optionally importing lessons from the agent's memory files. | #### Install In Claude Code: `/plugin marketplace add Global-Agent-Factory/corpole-platform`, then `/plugin install corpole@corpole`. **Updating the plugin.** A new version does not install itself. In a terminal, refresh the catalogue first, then update each place the plugin is installed: `claude plugin marketplace update corpole`, then `claude plugin update corpole@corpole --scope user`. Where a repository carries the plugin in its own settings (set up by `/corpole:init`), run `claude plugin update corpole@corpole --scope project` in that repository's folder as well. Restart Claude Code and open a new session: a session that is already open keeps the version it started with. `claude plugin list` shows the version in each place. ### States and statuses Source: https://corpole.com/support/reference/states-and-statuses · Reference The four record states and the columns each work type moves through. #### Record states Every requirement, objective and constraint has one of four states. Only **Authority** binds people and agents. | State | Meaning | | --- | --- | | **Draft** | Working content that can still change freely. | | **Approved** | Reviewed and accepted, but not yet the binding coding authority. | | **Authority** | Canonical instruction for AI-assisted implementation and human delivery. | | **Retired** | Historical content that must not drive new implementation. | #### Work flows Work items do not use the four states; each work type moves through its own columns. Cancelled is always possible and kept off the board. | Work type | Columns | | --- | --- | | **Theme** | Planned → Active → Done | | **Epic** | Idea → Analysis → Ready → In delivery → Done | | **Work package** | Planned → In delivery → Done | | **Story** | Backlog → Ready → In progress → Code review → Verification → Done | | **Task** | Backlog → Awaiting approval → Ready → In progress → Check → Done | | **Defect** | New → Triage → Ready → In progress → Code review → Verification → Fixed | | **Subtask** | To do → Doing → Done | #### Work statuses | Status | Meaning | | --- | --- | | **Backlog** | Captured, not yet ready to start. | | **Idea** | A proposed epic, not yet analysed. | | **Analysis** | Scope, value and requirements are being worked out. | | **Awaiting approval** | Needs approval before it may be carried out. | | **Ready** | Clear enough (and approved where required) to start. | | **In progress** | Being worked on. | | **Code review** | Code is finished and its pull request is being reviewed. | | **Verification** | Merged; its acceptance criteria are being verified (test, UAT). | | **Check** | Carried out; a second person checks the result. | | **Done** | Accepted by a person. | | **Cancelled** | Will not be done. | ### Relation types Source: https://corpole.com/support/reference/relation-types · Reference The typed links between records, what each means and what agents do with it. #### Relations | Relation | Meaning | For agents | | --- | --- | --- | | **Refines** | The source details the target one level down the "why" chain: objective → business → stakeholder → functional / non-functional. | Read the chain upwards to understand why a requirement exists before implementing it. | | **Realizes** | A technical requirement states how a functional or non-functional requirement is achieved. | Use the realizing technical requirements when implementing the functional or quality requirement. | | **Constrains** | A constraint limits specific requirements, or names the objective it comes with. A constraint that constrains no requirement applies to the whole solution. | Respect every linked constraint and every solution-wide constraint. | | **Depends on** | The source can only be implemented or hold once the target does; both are requirements of the same type. | Implement or verify the dependency first; flag it if it is missing. | | **Replaces** | The source takes the place of an older record of the same type, which should be Retired. | Follow the replacing record; never implement the replaced one. | | **Conflicts with** | The two records cannot both hold. While the conflict is open neither can become Authority. | Stop and surface the conflict with both codes; do not pick a side. | | **Relates to** | Informational link only. | Background only; draw no conclusions from it. | ### Glossary Source: https://corpole.com/support/reference/glossary · Reference The words CorPole uses, in one place. #### 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 " 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. | ### OAuth details Source: https://corpole.com/support/reference/oauth-details · Reference Endpoints, flow, tokens and scopes for MCP clients that sign in to https://corpole.com/api/mcp on their own. #### Endpoints and flow | Item | Value | | --- | --- | | Protected resource metadata | `/.well-known/oauth-protected-resource/api/mcp` (RFC 9728) | | Authorization server metadata | `/.well-known/oauth-authorization-server` (RFC 8414) | | Client registration | Dynamic (`POST /api/oauth/register`, RFC 7591) or Client ID Metadata Documents (an https `client_id`) | | Flow | Authorization code with PKCE `S256` (required); public clients | | Redirect URIs | https, or http on a loopback address (any port) | | Tokens | Access 1 hour, refresh 30 days with rotation; reusing a code or a refresh token revokes the connection | | Revocation | `POST /api/oauth/revoke` (RFC 7009), or **Disconnect** on the solution's Agents page | #### Scopes | Scope | Allows | | --- | --- | | `read` | Read the solution's records, work, knowledge and standards. Always granted. | | `propose` | Add Drafts, change proposals, work items, tests, results, questions, decisions, defects and risks for people to review. Never makes anything binding. | The permissions are chosen on the consent screen; propose needs a role above viewer. A connection never has more permissions than the person who approved it.