1. Docs
2. Concepts

Risk Register and Architecture Debt

The architecture risks accepted or carried — from decisions, from active exceptions and from authors — each with an owner, a severity and a review date, and the architecture debt the records already show, derived and never logged.

#Why a Risk Register

Boards accept risks constantly: in decisions ("we accept single-region writes"), in exceptions, and in the conditions they attach to approvals. That acceptance usually lives in prose and minutes, with no owner and no date to look at it again. The Risk Register turns each accepted risk into a record with an owner, a severity and a review date. Where the record already exists, the register reads it: an exception is shown, never copied.

Architecture Debt is the other half. A head of architecture is asked "what are we carrying?", and the honest answer is a list of records anyone can open, not an estimate. Like the rest of the derived model, it is derived, never logged by hand.

#Where Risks Come From

An exception's risk is titled Exception to STD-010 · .NET Framework web apps are on hold, for example. Its description is the exception's reason, its severity the severity of the artefact it excepts, its owner the person who approved it, its application the one it covers, and its review date the exception's expiry. It has no RSK- code of its own.

#What a Risk Records

An author logs a risk with Log Risk on the register, or Add Risk on a decision:

• Title — at least five characters, naming what could go wrong, for example Single-region writes for admissions.
• Description (optional) — what could go wrong and what it would affect.
• Severity — Low, Medium, High or Critical.
• Owner — the person who looks after it; it defaults to whoever logs it.
• Review By (optional) — when the owner looks at it again.
• Applications (optional) — the applications it concerns. A risk logged against a decision takes the decision's applications automatically.

Each risk gets a code (RSK-0001) and records who logged it, when, its origin — human, or ai_assisted when it was logged from an AI suggestion — and, once closed, who closed it, when and why.

#Status

A risk tied to a decision shows proposed while the decision is proposed and withdrawn if it is rejected, superseded or deprecated. Once the decision is accepted, the risk shows the status its owner records.

Only the risk's owner, or whoever logged it, changes it: its status, severity, owner and review date. Every change is audited, and nothing is deleted: a closed risk stays on the register with its closing note.

#Review Overdue

A risk's review is overdue when its review date has passed and it is open or accepted. For an exception, the review date is its expiry. The register marks it Review overdue under the date and counts it in the hero band.

#Architecture Debt

Architecture debt is derived on every read, from records that already exist, and grouped by application. Nothing is stored and nobody logs it.

Each item has a title, a line of detail and, where there is one, the date it dates from. Debt clears when the record behind it clears — the finding is fixed, the condition met, the assessment or plan recorded, the component upgraded — never by marking it resolved.

#Accepted Risks on a Decision

A decision's page has an Accepted Risks section: the risks it accepts, with each one's severity, owner and status, on the register. Its Consequences say what accepting the decision means; this section turns the risks they name into records with an owner and a date.

• Add Risk — an author logs a risk against the decision. Its standing follows the decision: proposed while the decision is proposed, accepted once it is, withdrawn if it is rejected or superseded.
• Suggest from Consequences — with the Risk Extraction AI feature on, reads the decision's text and lists suggested risks, each with Log. With the feature off, the button is greyed with the reason. See Heuristics and AI.

See Decisions.

#The Risk Register Page

Risk → Risk Register brings it together:

• Counts in the hero band: open, accepted, high or critical, review overdue, and debt items.
• Log Risk, for authors.
• Risks — one row per risk, showing open, accepted and proposed ones by default; Show chooses all, or one status. Each row has the risk (its code, title, description and applications, and an AI-assisted tag where it came from a suggestion), its severity, its source (linked to the decision, for a decision's risk), its owner, its status, its review date, and Update. Update is offered to the owner and to whoever logged it; everyone else sees Owner only, and an exception's row says Via the exception.
• Architecture Debt — one row per application with how many items it carries and of which kinds. Expand an application for each item, linked to the record behind it, and the date it dates from. Search by application.

Severities and statuses are tags that carry colour, icon and word, and explain themselves on hover.

#Who Can Do What

Changing a risk is admitted at the route for create_decision, approve_review, decide_review or comment, so a board member who owns a risk can update it; the handler then checks that the person is its owner or logged it. Refused with 403:

• the platform admin and the auditor, logging or changing a risk;
• anyone else changing a risk they neither own nor logged.

An exception's risk is changed through the exception, never on the register. See Roles and capabilities.

#Where Risks Surface

• The evidence pack carries the register in scope: every risk for the tenant, or the risks that name the application. Each has its code, title, severity, status, source, owner, review date, the decision that accepts it, its origin, and who closed it with the note.
• A board pack lists Risks Needing Attention: open and accepted risks rated high or critical, and any risk whose review is overdue, with the register's counts.
• Governance Metrics gains a Risks and Debt row: open risks, high or critical, review overdue, and the architecture debt.

#Evidence and Audit

Every change is in the audit chain, recorded on the risk: risk:log with its code, severity, decision and origin; risk:<new status> when the status changes, for example risk:closed; risk:update for any other change — each with what changed and the note.

#Heuristics and AI

Everything that sets a risk's standing, or puts an item on the debt list, is deterministic:

• A decision's risk follows the decision's status, as above.
• A review is overdue when the review date has passed and the risk is open or accepted; an exception's review date is its expiry.
• Debt is derived on every read: findings by their age against debt.finding_days, drift as drift, expired exceptions only while their artefact still fails, legacy assessments and exit plans by their own registers.

AI is optional and only proposes. Risk Extraction is a per-feature switch under Settings → AI, off by default (see AI providers). With it on, Suggest from Consequences on a decision's page reads the decision's own text — its context, recommended option, justification and consequences — and suggests up to five risks it accepts:

• each has a title, a one-sentence description and a severity the text supports;
• it covers only what the text supports, and leaves out the risks already registered against the decision;
• a suggestion with a title under five characters, or a severity other than low, medium, high or critical, is dropped.

Nothing is stored when suggestions come back. Log opens the risk form filled in from the suggestion; the author checks that it holds, edits it, and logs it as their own. It is then recorded as ai_assisted and shows the AI-assisted tag. With the feature off, the button is greyed with the reason and the API answers 409. No AI sets a status, changes a risk or adds to the debt list. See AI in Archigov for what is sent.

#What It Deliberately Does Not Do

• It does not score risks. There is no likelihood × impact grid: severity is one judgement by a named person, and the board weighs the rest.
• It does not copy exceptions into the register, and a risk never changes an exception.
• It does not store debt, or let anyone mark debt resolved. Debt clears when the record behind it clears.
• It does not judge whether a risk is acceptable. It shows who accepted it, who owns it and when it is next looked at.

Note

The register shows which risks are accepted or carried, who owns each and when it is next reviewed, and the debt the records show. Archigov never asserts that a risk is acceptable or that you meet any framework: it shows evidence, not assurance.

Something unclear or out of date? Write to hello@archigov.com or open an issue on GitHub.