A risk assessment workflow can look controlled while the decision underneath it is already stale.
At Ironbark Cold Logistics, a fictional Australian cold-chain operator, the Wattle Creek distribution centre depends on standby generation. Its latest generator transfer test failed after 47 seconds. The supporting evidence is stale, a treatment is still awaiting a witnessed retest, and an independent challenge remains open. The dashboard does not hide that conflict behind a reassuring green status: residual exposure is 15 out of 25, five points above appetite.
That dashboard is the front door to a much larger risk assessment process. In week 16 of our case-study series, SwarmCraft planned a 74-task project to replace Archer as the authoritative enterprise-risk system inside a defined boundary. The resulting customer-owned operation connects the risk register, method versions, assessments, controls, evidence, treatments, challenges, appetite exceptions, reporting, migration and audit history.
It is not a prettier heatmap layered over Archer. It takes responsibility for the records that make a risk decision reproducible.
For the wider category, start with Best risk management software. Archer competitors examines the incumbent decision, while Why risk software sprawl grows when no system owns the complete risk decision explains why registers, evidence, treatments and approvals split across several tools.
The case for replacing the risk record
Archer sets a serious replacement bar. Its current Enterprise Risk Management documentation describes consolidated risks and controls, inherent and residual assessment, appetite and tolerance, consistent methods, delegated authority, escalation and reporting from one system of record.
The problem is not that Archer lacks risk features. It is that making a broad governance, risk and compliance platform fit a particular risk operation requires substantial customisation and specialist administration, while the organisation still works within Archer's product and commercial boundaries. When the platform cannot keep pace with the operation, people fall back to spreadsheets, document storage, project tools and email, and the risk record stops reflecting how decisions are actually made.
The Internal Audit Foundation and Baker Tilly surveyed 567 professionals in 2025 and found that nearly 60% still relied on word-processing files and spreadsheets for enterprise risk management. Only 21% reported using a dedicated governance, risk and compliance platform, while 20% used in-house tools.
Practitioner discussions reveal the same operating tension from another angle. In one recent discussion about Archer in a medium-sized, non-regulated organisation, the original poster described rising renewal cost, specialist administration and records that were not driving action. Other participants described Archer as comprehensive but clunky and questioned whether their narrower needs justified its breadth.
Those comments are anecdotes, not evidence that every Archer implementation has the same problem. They explain the Week 16 test: if the real operation is smaller than the platform, can the organisation own the complete risk decision without recreating the unused breadth?
The risk-operation boundary we chose
Inside the agreed boundary, the owned product is the risk system of record. Adjacent systems remain authoritative only for specialist facts they originate.
| Owned by the risk operation | Adjacent authority |
|---|---|
| Canonical risks, objectives, entities, relationships, accountable owners and taxonomy versions | Identity services authenticate people; finance, legal, safety, cyber, insurance and asset systems retain their specialist records |
| Effective assessment methods, inherent, residual and target exposure, appetite and tolerance | Source systems provide bounded observations; they do not choose the risk, method or score |
| Controls, evidence requirements, received evidence, freshness, review and verification | Document storage preserves files; it does not declare a control effective |
| Indicators, incidents, treatments, challenge, approval, delegated acceptance and review history | Project and notification tools may deliver work, but completion or acknowledgement does not reduce exposure |
| Versioned reports, cited record versions, approval, immutable artifacts and delivery evidence | Email or collaboration providers deliver approved artifacts; they do not approve the decision |
| Archer migration inventory, mappings, quarantine, reconciliation, cutover, rollback, export and audit evidence | Archer is the staged source during transition and ceases to be authoritative only after approved cutover |
This is an Archer replacement for one coherent enterprise-risk operation, not a feature-parity clone of every Archer application.
Project stats
| Measure | Week 16 evidence |
|---|---|
| SwarmCraft project | Risk Assessment |
| Planned implementation scope | 74 task packets |
| Current packet lanes | 74 Done |
| Target repository | 525 tracked files and 27,167 tracked lines across application and infrastructure paths at evidence review |
| Database | PostgreSQL with 13 versioned Flyway migrations |
| Repository verification | 120 API unit, 24 API integration and 57 web unit tests passing |
| Browser verification | 46 Playwright tests passing across desktop and narrow layouts |
| Maintained browser evidence | 17 deterministic screenshots; five concise Ironbark story captures selected for this article |
| Delivery target | Customer-managed cloud environment with recoverable background processing |
This is a production-shaped foundation, not evidence of a live Ironbark deployment. The product uses deterministic fictional fixtures. Live identity, customer policy, Archer exports, provider credentials, production role grants, migration approval and operational recovery still require customer-specific implementation and assurance.
The risk assessment workflow we built
The case follows one backup-power risk, ICL-ER-042, through a failed generator test, stale evidence, reassessment, challenge, treatment, migration and reporting.
| Role | Responsibility in the owned operation |
|---|---|
| Risk analyst and operation administrator | Maintains the record structure, reviews source evidence and coordinates the assessment without granting acceptance |
| Distribution-centre general manager | Owns the Wattle Creek risk and responds to the assessment basis and proposed treatments |
| Facilities manager | Owns the generator control and treatment work, supplies evidence and requests verification |
| Independent risk challenger | Questions the method, control claims and owner response without accepting the risk |
| Chief operating officer | Uses current delegated authority to accept or reject above-appetite exposure with conditions and expiry |
| Executive, board reader and auditor | Read audience-appropriate reports and drill through to the exact records behind the conclusion |
| Migration and organisation administrator | Governs Archer inventory, mappings, quarantine, cutover, rollback, access and audit evidence |
Risk assessment workflow steps
The implemented and tested risk assessment workflow follows these rules:
- Start with a server-calculated dashboard showing residual exposure, appetite status, the five-by-five matrix, exposure trend, treatment health and exact record links.
- Preserve the Archer source identity and versioned migration mapping instead of flattening every record into a new identifier.
- Receive control evidence with its source, observed time, received time and integrity metadata.
- Keep duplicate delivery separate from record matching: a retry may be suppressed, but ambiguous evidence still requires reconciliation.
- Resolve the assessment method and appetite policy effective for the relevant period.
- Keep source facts, deterministic calculation, AI suggestion, uncertainty, human response, challenge and decision as separate records.
- Prevent a stale document, completed treatment or accepted notification from changing exposure automatically.
- Require the risk owner to respond and an independent challenger to review the basis.
- Allow above-appetite acceptance only through a current delegated authority with conditions, expiry and a recorded reason.
- Track repair, contingency and witnessed-retest treatments without equating task completion with control effectiveness.
- Reassess only after new evidence is reviewed and the authoritative method is applied again.
- Route late or conflicting evidence to reconciliation rather than silently overwriting a newer decision.
- Generate a versioned risk brief from cited records and require human approval before distribution.
- Return to the dashboard, where every aggregate can resolve to the exact record history behind it.
These risk assessment workflow steps are a practical risk assessment workflow template: an event is not a score, a score is not acceptance, a completed task is not a verified control, and AI advice is not authority.
The dashboard starts with the exception
The opening dashboard is an operating surface rather than decorative business intelligence. The API returns the residual score, appetite threshold, trend, treatment state, evidence freshness, reviews, matrix cells and linked records. The browser does not calculate an alternative answer.
The exposure matrix uses the familiar four-band pattern—green low, yellow moderate, orange high and red critical—while appetite remains a separate policy decision. A score can therefore retain its ordinary severity rating and still show whether it breaches Ironbark's current appetite.
Every matrix cell is keyboard operable, supplies a text label and can resolve to the records in that cell. Colour is not the only signal.
Archer migration is a transfer of authority
The migration view does not call a batch successful because ten out of eleven records loaded. It stops cutover because the owner of one historical acceptance cannot be resolved.
The fictional rehearsal preserves the Archer snapshot, mapping version, source identifiers, relationships and attachment checksum. Risks, assessments, controls, evidence and treatments reconcile. The acceptance remains quarantined, so it cannot silently grant authority in the replacement.
The same surface shows a passed rollback rehearsal: ten staged records restored from the checkpoint, zero missing links and a matching generator attachment checksum. That is migration evidence, not permission to cut over. An authorised person still has to resolve the exception and make the go or no-go decision.
The broader target includes migration inventory, mapping, reconciliation, delta and recovery foundations. It does not connect to a live Archer tenant or execute a production cutover.
Risk Desk lets AI prepare work without becoming the decision-maker
Risk Desk uses the same typed server command boundary as the visual interface. In the implemented story, it proposes a witnessed generator retest and cites the assessment, failed evidence and treatment records that support the recommendation.
The user can see the recipient and the exact proposed change before anything happens. The first confirmation records intent but does not send the request. Execution then rechecks the authenticated person's permission, record version, recipient, confirmation identifier and idempotency key.
The accepted request still does not reduce the risk.
The receipt records a notification outcome. Residual exposure remains 15, and the evidence remains stale until a witnessed result is attached and reviewed. That is the product's most important AI boundary: conversation can remove interface friction without bypassing the risk assessment process.
The wider repository also contains a structured AI adapter and an MCP-compatible tool boundary with typed inputs, short-lived credentials, explicit confirmation, rate limits, timeout handling, idempotency and audit tests. A live model provider and production tool catalogue are not configured.
The report retains the decision basis
Reporting is audience-aware without producing a different truth for each audience. The executive and board views stay concise. The auditor view adds migration and rollback evidence while preserving the same residual exposure, appetite exception and decision state.
The displayed report is revision 7. It says that Wattle Creek remains above appetite, that a witnessed generator retest and independent challenge are due, and that no risk acceptance has been recorded. Each identifier opens the governed record behind the statement.
The repository defines a provider-neutral document-renderer contract and implements immutable object storage plus versioned notification delivery. A deterministic PDF renderer, report approval workflow and stale-report lifecycle are not yet implemented. The concise story capture proves the record-linked report view; it does not prove a complete browser journey through PDF preview, approval, email delivery and later staleness.
What the custom risk operation includes
| Capability | Week 16 implementation | Next responsible work for live operation |
|---|---|---|
| Risk record | Stable organisations, entities, objectives, risks, taxonomy and relationship revisions | Load the approved customer taxonomy, ownership and retention rules |
| Assessment | Versioned methods, deterministic scores, inherent, residual and target history | Confirm scoring definitions, review triggers and decision policy |
| Appetite and acceptance | Effective policies, exception history, challenge, delegation, expiry and default-deny authority | Configure reviewed grants, delegations and escalation thresholds |
| Controls and evidence | Linked controls, evidence, indicators, incidents, freshness and reconciliation foundations | Connect reviewed source adapters and evidence-handling policy |
| Treatments | Assignment, completion evidence, separate verification and reassessment requests | Configure real owners, dependencies, reminders and verification roles |
| Risk Desk and AI | Cited proposal, confirmation diff, receipt, structured AI adapter and MCP-compatible command boundary | Connect an approved model, evaluate outputs and activate only permitted tools |
| Dashboard and reporting | Server-authoritative matrix, trend, treatments, evidence, reviews and audience-specific record views | Implement the controlled PDF renderer, approval, staleness and protected delivery history |
| Archer migration | Versioned mappings, quarantine, source comparison, relationship proof and rollback evidence | Build and rehearse customer extraction, deltas, cutover and decommissioning |
| Security and continuity | Opaque sessions, server-side authorisation, audit persistence, readiness, backups and recovery runbooks | Configure production identity, secrets, grants, storage, monitoring and recovery objectives |
Technology implemented
| Layer | Week 16 implementation |
|---|---|
| Browser application | React 19 and Vite 7 with responsive risk, assessment, Risk Desk, reporting, migration and audit routes |
| Design system | A colocated token system, reusable primitives, documented adoption contract and separate review workbench |
| Dashboard | CSS Grid matrix, accessible table equivalent, server-calculated trend and linked operational panels |
| API | Node.js modular monolith with protected routes, domain rules and provider-neutral infrastructure contracts |
| Persistence | PostgreSQL client and 13 versioned Flyway migrations for security, risk records, assessments, operations, treatments, decisions, reconciliation, evidence delivery, notifications, jobs and appetite |
| AI and MCP | Structured-output adapter, deterministic mock and typed tool boundary with permission, confirmation, timeout, replay and audit controls |
| Migration | Temporary Archer read and reconciliation adapter, versioned mappings, comparison and rollback evidence |
| Reliability | Health and readiness separation, retry and recovery contracts, release evidence, backup and rollback runbooks |
| Verification | Node test runner, Vitest and Playwright with deterministic desktop and narrow-layout fixtures |
What the browser evidence proves
The 46 passing Playwright tests cover the full repository's browser contracts, including authentication recovery, server-authoritative assessment values, challenge history, governed Risk Desk actions, migration exceptions, reporting, keyboard navigation, responsive layouts and design-system behaviour.
The five concise Ironbark captures selected for this article prove a narrower editorial story:
- the Wattle Creek dashboard exposes residual 15, appetite 10, the matrix, trend and treatment state;
- Risk Desk cites exact records and separates proposal, confirmation and execution;
- an accepted notification leaves exposure and evidence unchanged;
- the Archer cutover remains blocked while one acceptance is quarantined; and
- the auditor report retains exact links to the assessment, evidence, challenge, migration and rollback records.
They do not yet tell the complete visual story we designed. The existing assessment-workbench and migration regression captures are long full-page test artifacts, so they were not copied into the article. A stronger final evidence set would add concise, staged screens for the failed-control arrival, assessment basis, owner response, independent challenge, executive acceptance, treatment verification, late-event reconciliation, PDF approval and the closing dashboard after reassessment.
That is a screenshot and product-composition gap, not permission to imply those browser journeys from the scenario alone.
How SwarmCraft structured the build
Before implementation began, SwarmCraft divided the product build into 74 task packets under the Risk Assessment project. The board moved from maintained context and domain vocabulary through database foundations, identity, authorisation, canonical risk records, method versions, evidence, treatments, challenge, acceptance, integrations, migration, visual design, system tests and recovery.
The foundation tasks established the React web application, Node.js API, PostgreSQL schema and authentication, authorisation and audit (AAA) boundaries. Sessions expire, permissions are enforced by the server against organisation and resource scope, and security outcomes and risk decisions retain separate audit histories.
The product tasks then built the versioned risk register, assessment methods, appetite rules, controls, evidence, treatments, challenges, acceptance, reporting and Archer migration. A reusable Ironbark design system supplies the colour tokens, typography, layout, status treatments, accessible controls, keyboard focus and responsive patterns used across those workflows.
The final task groups added provider boundaries, background recovery, deployment assets and operating runbooks. Automated checks cover API and web units, API integration, PostgreSQL migrations, wide and narrow browser journeys, keyboard interaction and deterministic screenshot evidence.
What this says about AI-built risk software
AI worked in two different roles.
First, an AI build agent worked through the project packets across application code, migrations, tests, infrastructure and runbooks. The output became credible through executable checks, browser evidence and human review—not because the task files reached Done.
Second, AI operates inside the product as a bounded risk assistant. It may assemble permitted evidence, identify contradictions, explain missing material and prepare a proposed command. It cannot choose the authoritative risk, select the method, set the score, declare a control effective, grant acceptance, distribute a report or migrate records by itself.
The useful pattern is not autonomous risk management. It is faster preparation around deterministic rules and accountable human decisions.
Replace the register, then own the responsibility
The Week 16 result is not another assessment questionnaire feeding Archer. It is an owned risk assessment workflow and decision operation with one traceable route from source evidence to an authorised outcome.
The replacement becomes credible when the organisation can answer these questions from its own records:
- Which version of the risk, method, appetite policy and delegation applied at the decision time?
- Which source event arrived, when was it observed and received, and was another delivery a retry?
- Which evidence supported each control claim, who reviewed it, and was it current for the assessment period?
- What did the deterministic method calculate, what did AI suggest, what did the owner answer and what did the challenger dispute?
- Who had authority to accept above-appetite exposure, under which conditions and until when?
- Which treatments were merely complete, which controls were verified, and which reassessment changed exposure?
- How was a late event reconciled without overwriting a newer decision?
- Which exact record versions produced the committee report, who approved it and when did it become stale?
- Did migrated identities, relationships, histories, attachments, permissions and reports reconcile before authority changed?
- Could the organisation restore, roll back, export and continue without creating duplicate risks or decisions?
Owning those answers is what turns risk assessment automation into a risk system of record.
Use Deep Discovery to plan the Archer replacement
An Archer replacement crosses consequential records, scoring methods, evidence, permissions, delegated authority, integrations, migration, cutover and continuity. Deep Discovery is the route for mapping those records and responsibilities into one coherent owned operation. It is currently available through a limited account-enabled rollout.
The goal is not a prettier risk matrix. It is a complete risk assessment process that the organisation can operate, explain, recover and improve on its own terms.
