Traceability & quality
Acceptance criteria, tests, CI results, defects and risks.
"Done" should mean the same thing to everyone, including the agent. CorPole makes it concrete: every requirement and design record carries acceptance criteria with their own codes (for example FDR-…/AC2), tests are linked to the criteria they prove, and CI results update the criteria automatically. A story with a failing test cannot quietly slip to Done.
Proof comes from a test or a person, not from a claim. An agent can report a criterion as met, but until a passing test or a person confirms it, the report is shown as agent-reported and not verified. The traceability view shows, for every criterion, its tests, the work that covers it and the code that changed.
Quality is also about what goes wrong. Defects record behaviour that breaks a requirement or criterion, with severity and the criteria they violate; the risk register scores what might go wrong by probability and impact and requires a recorded decision to accept a risk.
The articles here explain how criteria work, how to link tests and let CI report, how the change-request check keeps every pull or merge request tied to a record, and how to use the test, defect and risk screens.
Articles in Traceability & quality
- GuideCompliance matrixFrom 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.
- GuideBaselinesName 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.
- GuideAudit trailEvery 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.
- GuideIntent MapWhy 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.
- GuideImpact MapWhat 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.
- GuideTest cases and traceabilityTest 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.
- GuideDefectsA 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.
- GuideRisk registerRisks 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.
- ConceptAcceptance criteria: Met, Not met, verifiedCriteria are separate items with their own codes and status. Proof comes from a test or a person.
- How-toLink tests to criteria and let CI reportRegister each test against the criteria it proves; results then update the criteria.
- How-toThe change-request check and the no-requirement labelEvery pull or merge request cites existing, non-retired record codes; trivial changes carry a label instead.