Skip to main content

Structured Review Workflow

What it does​

A built-in, audit-grade review workflow for every artifact — AI-generated or hand-authored: submit → assigned reviewers comment → owner dispositions each comment → approve/reject/baseline.

Reviewer's view of an artifact in review: two comments tagged MAJOR and MINOR, and a banner stating that one critical/major comment must be dispositioned before approval is possible, with the Approve button disabled

The reviewer's side of a live review. Note what the banner is doing: one comment is tagged major, so Approve is disabled until the owner dispositions it. Severity is not decoration — it drives the gate. The reviewer also sees "Edit actions are disabled" on the document itself, because reviewing is a distinct access level, not just a permission to comment.

Why it matters​

Hardware reviews happen in PDFs and emails today. Comments get lost, dispositions are tribal knowledge, and audit trails don't exist. Creopus makes review state a first-class object.

How it works​

  • Lazy review sessions — created the moment the first reviewer is added.
  • Comment severity tagging — critical / major / minor / editorial.
  • Disposition states — open → accepted / rejected / deferred / noted (with reason and audit fields).
  • Round tracking — currentRound + rounds[] per-round snapshots.
  • Deadline + extension audit log — who extended, when, why.
  • Implement-on-review — one click on an "accepted" comment triggers AI to patch the artifact in place.

Owner's view after dispositioning: the major comment now carries an ACCEPTED badge and the disposition reason, the blocking banner is gone, and an "AI Implement Comments (1)" button has appeared

The same review after the owner dispositions the major comment. The disposition reason is recorded on the comment itself, the approval block clears, and "AI Implement Comments (1)" appears — accepting a comment is what makes it eligible for the AI to patch in place. The minor comment is still open, which is fine: only critical and major block approval.

Workflow states​

draft → in_review → change_requested → in_review → approved → baselined
                ↘ rejected

State transitions are logged with actor, timestamp, and reason.

Strict change control after baseline​

Baselining isn't just a label — it locks the document:

  • Once a document has ever been baselined, direct edits to its main content are blocked platform-wide. That applies to humans and to the AI agent equally.
  • The sanctioned change route is a working copy: copy the main document, make your changes there, review the colored diff against main, and merge. Every merge is a tracked revision, so the baseline's audit trail stays intact.
  • Attempting a direct edit surfaces a clear redirect ("Start a working copy →") rather than a silent failure.
  • Metadata that doesn't alter the engineering content — document info, renames, hierarchy links, attachments — stays editable.

This is the same discipline as an aerospace/automotive change board, encoded in the platform: baselined truth changes only through a reviewed, merged delta.