Eight stages, seven gates

A project enters the next stage only when this one is signed off.

Every gate checks records, not promises: which deliverables are signed off, what the tests and assessments say, which risks were accepted and until when. What each gate needs depends on the project's tier.

Stage 1InitiationIT Committee deck, initiation risk assessment
G1Stage 2RequirementsPRD with requirement IDs
G2Stage 3DesignData flow diagram, design references
G3Stage 4BuildApproved test cases
G4Stage 5TestingSIT and UAT summary reports
G5Stage 6Security validationSix assessments, findings, validation pack
G6Stage 7ReleaseChange request, rollback plan, readiness review
G7Stage 8Post-implementationPIR; its sign-off closes the project

What each gate requires
Gate	Closes	Opens when
G1	Initiation	The IT Committee presentation and the initiation risk assessment are signed off.
G2	Requirements	The PRD is signed off. An RTM baseline is stored automatically.
G3	Design	Per-tier rules the administrator can tune: medium and high tiers need a saved context DFD; high tier needs every Must requirement linked to a design element.
G4	Build	At least one test case is approved.
G5	Testing	SIT and UAT summary reports are signed off. An RTM baseline is stored.
G6	Security validation	Every mandatory assessment passed, and no Critical or High finding is open without an unexpired risk acceptance. A fix counts only after a retest.
G7	Release (go/no-go)	Change request, rollback plan and readiness review are signed off; no open Sev 1–2 defect without an accepted risk; any failed readiness check is acknowledged on the record.

Deliverables as records

Typed, versioned and hashed, not free-form documents.

Each deliverable is structured JSON built from a template and edited section by section, with guidance under every section. Exports carry the version's SHA-256 on every page.

Ten templates, from the IT Committee deck to the post-implementation review
Autosave every 10 seconds, with a warning when someone else saved first
Comments anchored to sections; submission waits until required sections are filled
Sections computed from records (test metrics, findings, gate checks) are read-only
Export to Word, PDF and PowerPoint, with an approvals and signature table once signed off

Deliverable editor with the AI assistant panel and a section labelled AI-generated — The PRD of the pilot project. The Objectives section still carries its AI-generated label.

Versions and diff

Every submitted version is frozen with its hash.

Submitting freezes the version and computes its SHA-256 over canonical JSON. Editing afterwards starts a new draft and voids pending approvals. A signed-off version never changes.

Each version shows whether a person, AI or both wrote it
Compare any two versions section by section, with provenance on each side
The approval trail lists who approved, when, and the statement they signed

Version list showing a signed-off version with its hash, L1 approval and sign-off statement

Section-by-section comparison of two versions of the SIT report

A worked example for every type

Start from the catalog, or on its own outside a project.

The Deliverables module lists all ten types with a worked example of the data each needs, its format and what it generates. Five of them can be created on their own, with the same AI drafting, reviews, sign-off and exports as inside a project.

Catalog of the ten deliverable types with their stage and a link to each worked example

Electronic sign-off

Nobody approves what they wrote, or a version they did not see.

Sign-off is an electronic signature: a fresh authenticator code, a meaning statement, and the exact version hash the approver saw. If the version changed underneath them, nothing is recorded.

Sign-off dialog with the version's SHA-256, the meaning statement, a confirmation box and an authenticator code field — The signer sees the full SHA-256 and the statement they are making, then enters a code that works once per 30-second step.

Maker-checker
Authors and editors of a version cannot approve it, one person cannot give both approvals, and administrators cannot approve at all.
Two levels
A Team Lead or Department Head gives the first approval; the Department Head signs off.
Bound to the hash
Approve and sign-off requests carry the hash the approver saw. A mismatch returns an error and records nothing.
Kept with the document
Signer, time, meaning, hash and authenticator time are stored and printed on the signed export.

New deliverable dialog with type, title, data classification, reviewer and the fields the type needs — The data classification chosen here decides which AI models may draft the deliverable.

AI drafts, people decide

Six AI tasks, one gateway, full provenance.

AI writes first drafts, reviews versions, rewrites sections, drafts the context diagram, proposes trace links and generates test cases. It never submits, approves or signs off, and nothing it writes takes effect until a person applies it.

Allowlist. Models are enabled per role and per data classification ceiling; Restricted projects may use only the on-premises model.
Budgets. Token limits per user and per project each month, a cap per request and two running jobs per user.
Emergency stop. One switch, checked at the request and again in the worker, failing closed.
Provenance. Model, prompt template version, input record and file hashes, tokens, cost and outcome for every call.
Guarded inputs. Reference files are passed as delimited data; the model gets no tools and its output is schema-validated.
Providers. Anthropic Claude, Google Gemini or vLLM on your own GPU, plus a deterministic mock for testing.

AI models administration: the on switch, budgets, and the allowlist with roles, classification ceilings and prices — Changes to the allowlist need a fresh authenticator code and are audited with before and after values.

Traceability and design

The traceability matrix is computed on every read, never typed.

Requirements come from the PRD's tables. Trace links connect them to design elements, test cases, defects, findings and change requests. Gaps show up the moment a link is missing or a test fails.

Requirements traceability matrix with coverage chips, gap counts and AI link proposals — Coverage and gaps at the top; baselines are stored automatically at G2, G5 and G7 and on demand.

Data flow diagram editor with trust boundaries and automatic checks — Checks flag flows that cross a trust boundary unencrypted, Restricted data reaching an external party, and orphan nodes.

Test management

SIT and UAT with the evidence attached where it happened.

Versioned test cases approved by a Team Lead; editing an approved case starts a new version
AI generation of positive, negative, boundary and UAT cases, with likely duplicates flagged
CSV and Excel import of up to 2,000 rows, validated row by row before anything is saved
An execution runner where a failed test always raises a defect, and a passing retest can close it
Evidence dropped onto an execution or the whole cycle, hashed, and read-only once the report is signed
UAT sign-off is blocked while a Sev 1 or 2 defect is open, unless a Department Head accepts the risk

Test case list linked to requirements, with the AI generation panel above it

Security validation

Six assessments stand between testing and release.

Information security testing, data movement control, SAST, DAST, SCA and vulnerability scanning, each mandatory by tier. Findings carry CWE or CVE references, owners and due dates, and link back to requirements and data flows.

A fix closes a finding only after a retest
Department Head risk acceptances carry a reason and an expiry date
The validation pack flags findings tied to Must requirements or boundary-crossing flows

Security validation page with the G6 readiness banner and six assessment cards

Release, review and evidence

Go/no-go from computed checks, then an evidence pack anyone can verify.

The production readiness review lists the checks the platform computes from records. Emergency changes stay flagged until their test evidence is attached. The post-implementation review closes the project for good.

G7 go/no-go checks with one acknowledged gap, release deliverables and two evidence packs ready to verify — One readiness check failed and was acknowledged at G7; the acknowledgement is stored with the gate decision.

What the evidence pack holds

Every signed-off deliverable as PDF
The current RTM and every stored baseline
Uploaded test evidence and security reports
Approvals with hashes, meaning statements and authenticator times; gates, cycles and defects
The project's hash-chained audit rows
A manifest with every file's SHA-256, checkable in the product or offline with a standard-library script

Portfolio of projects by stage with next gate, open severe defects and findings, and RTM coverage — The portfolio gives Department Heads and auditors every project's stage, next gate and coverage.

Roles

Five roles, 24 named permissions, one seeded table.

Every endpoint declares the permission it needs, and code never compares role names. People see only their own projects; Department Heads see their department; auditors see everything, read-only, and every view is itself audited.

Capability	Developer	Team Lead	Dept Head	Auditor	Admin
Write and submit deliverables, run AI, execute tests	✓	✓	✓	–	–
Create projects, manage members, first-level approval	–	✓	✓	–	–
Final sign-off, gate decisions, risk acceptance	–	–	✓	–	–
Export evidence packs	–	✓	✓	✓	–
Portfolio and audit log	–	–	✓	✓	audit log
Users, sessions, AI models, templates, settings	–	–	–	–	✓

Administrators run the system and see no project content.

The pilot

cognita dev ran its own release through all eight stages.

Before release, the platform took its own version 1.0 from intake to closure. A script drove the API with a live model, drafting every deliverable from the repository's own material and attaching real test and security evidence.

22AI jobs drafted the deliverables, the context diagram and the test cases.
52 · 38Requirements traced, and test cases approved and run.
31Files in the evidence pack, verified online and offline.
1,890Audit events at closure, with the hash chain intact.

The pilot's 24 findings were fixed before release. The project screenshots on this page come from that pilot.

Quality attributes

Targets written down, and measured.

Attribute	Target	Measured so far
Response time	p95 under 300 ms for reads and 600 ms for writes at 200 concurrent users	50-user run on a laptop: 0 failures, reads p95 14–24 ms, writes 76–77 ms. The 200-user run on production hardware is pending.
AI jobs	Start within 2 s; a full draft within 3 minutes	Pilot drafts took 9–21 seconds.
Recovery	RPO 1 hour, RTO 4 hours; quarterly restore drill	The restore drill runs in CI on every pull request and verifies row counts and the audit chain.
Availability	99.5% during business hours	Single-host Compose deployment with health checks on every service.
Security baseline	OWASP ASVS Level 2 and the OWASP Top 10	No high or critical findings in the hardening phase; nightly OWASP ZAP baseline.
Accessibility	WCAG 2.1 AA; every flow works by keyboard	axe checks on 10 screens fail the build on any serious or critical issue.
Capacity	500 active projects, 1,000 users, 2 TB of evidence	Designed for one organisation per installation.

cognita dev architecture Security controls

cognita dev

See a change go from intake to PIR.

We will walk a project through the gates, sign a deliverable, and verify an evidence pack in front of you.

Request a demo Next: cognita grc

The software lifecycle, gated and on the record.