National Regulatory Services Agency - IT Portfolio and Roadmap (illustrative demonstration)

The funded plan is modelled to remove 25% of current assessed risk. The remaining 75% is what PERSISTS after the plan lands, and 85% of that sits on applications the plan does touch. It is not "unfunded risk".

5 applications carried modelled risk reduction while no initiative touches them (61.59 units). That credit is ZEROED before anything is drawn: a plan cannot be credited with fixing something nobody is paying to fix.

These are questions worth asking, not decisions. Four signals, each computed from the data and each shown with the evidence behind it. None of them says an application should be consolidated. That call needs an assessment of what the applications actually do, and this dataset does not contain one.

One procurement, several modules

These arrived under one name and one agreement. That makes them one commercial decision even where they are 5 operational ones - which cuts both ways, and is the reason the cluster is drawn.

One supplier, several applications

Taken from the agreement register's own curated linked_entity column. Nothing is joined on name similarity: a name-matched supplier map is a guess wearing the appearance of a join.

Superseded by a recorded target state

A target-state row is excluded from every assessed count. It is shown here because it is the one place the register states an intended consolidation outright.

Untouched by the plan, and not business-critical

This list is a question, not a recommendation: retire it, or fund it. An application can be absent from the plan because it is fine, because nobody owns it, or because it was forgotten - and nothing in this dataset distinguishes those three.

No saving is estimated and no candidate is ranked. A consolidation saving needs licence terms, exit costs, functional overlap and migration effort, none of which is in this dataset; a number produced without them would be a guess wearing a currency symbol. Nothing here says two applications do the same thing - only that something about them is shared.

Every signal is derived at build time from the register, the initiative footprints, the agreement register and the config's own family and identity declarations. Change the data and these change with it.

A weighted multi-criteria ranking of the discretionary plan. Work the institution has no choice about is ring-fenced above the model, not given a high weight — weight an obligation and a sufficiently attractive option eventually outranks it. Every score is shown as its parts, because a single number nobody can decompose is a number nobody can argue with.

The model, and the choice inside it

Delivery risk is applied last, as a confidence discount on the total (low 100%, medium 90%, high 80%) rather than as a criterion. A shaky initiative is not less worth doing — it is less likely to deliver what it promises, and blending that into the case FOR the work would hide it.

Ring-fenced: not ranked, because not optional

These consume 22% of the plan before a single discretionary choice is made. That is the real starting point of any funding conversation, and it is the number most portfolio ranking hides by listing obligations alongside options.

The ranking, with its working shown

Funded from is the lowest funding level at which the initiative survives the cut, with obligations committed first. It is a property of this ranking, not a plan.

Rank band is how far the row moves across 8 runs that vary one weight by half in either direction. A band is information, not an alarm: sliding two places inside the funded block changes no decision. What does change a decision is crossing the line where the money runs out, and that is measured separately below.

6 of 14 initiatives change funding outcome by more than 10 percentage points when the weights move. These are the rows where the weighting is doing real work: Sector reporting refresh (funded from 25%, or 45% under a different weighting); Enterprise data warehouse consolidation (funded from 50%, or 30% under a different weighting); Revenue collection platform upgrade (funded from 55%, or 35% under a different weighting); Travel and expense refresh (funded from 100%, or 80% under a different weighting); Regulatory performance automation (funded from 30%, or 45% under a different weighting); Executive reporting workspace refresh (funded from 90%, or 75% under a different weighting). Everything else is funded or deferred at the same level whichever defensible weighting is used, so arguing about the weights will not change what happens to it.

1 initiative cannot be scored at all and is absent from the ranking rather than placed at the bottom of it: IT operating model and sourcing review. It is missing at least one component, and a missing component is not a zero — scoring it as one would manufacture a last place out of a gap in the register.

Three panels in this pack count “initiatives the model cannot place” and get three different numbers. They are not in conflict, they are three questions: 1 cannot be scored at all (missing a component, above); 2 carry no modelled risk reduction, so they are absent from the value-for-money ranking; and 2 are held in the funding stepper’s manual-only tray, which takes either of those two faults. Read the noun, not the number.

It also sits outside the funding lever on Funding scenarios: it is neither funded nor cut at any level, because a model that could not rank it cannot decide to drop it either.

The weights are a choice, not a finding, and a different defensible choice reorders this list — which is why the rank band under weight variation sits beside every row. The scores are normalised WITHIN this portfolio, so 100 means best of these, never good. There is no benefit in money anywhere in the dataset, so there is no NPV, no IRR and no payback here; “value for money” is risk reduction per million, which is a proxy and fails wherever the benefit of an initiative is not risk. Nothing here says what to cut. It says what the model says, how much of that survives the model being wrong, and what it could not look at.

Strategic alignment and the obligations are AUTHORED inputs in this dataset. Risk reduction, value for money and contract urgency are derived by the engine from the register. The tab marks which is which per row.

2 initiative(s) carry no modelled risk reduction and are absent from this ranking. They are not shown to be low-value: the model cannot score them at all, which is a coverage gap, not a result.

This ranks RISK REDUCTION per unit of spend and nothing else. It omits benefit, capability and statutory-obligation value entirely. It is not a value ranking and must not be read as one.

A shared entity's reduction is SPLIT EQUALLY between the initiatives that touch it, so no initiative is credited twice for the same entity.

One question: is the AI spend a portfolio, or a scattering? This is the AI-classified slice of the same plan, on the same figures. It is not a separate portfolio and not a separate budget. Every initiative below also appears in the register, the roadmap and the funding stepper — cutting it here cuts it everywhere.

Applications these initiatives change

Consents Portal - Closure, Enforcement and Compliance Register, Enterprise Data Warehouse, Guidance and Standards Repository, Identity and Access Directory, Procurement and Supplier Portal, Regulatory Analysis Environment, Regulatory Performance Platform

The AI classification is an AUTHORED field on the initiative record, not a derivation. The engine cannot tell whether an initiative uses AI from its name, its owner or its spend, and does not try - so this tab is exactly as good as whoever filled the field in. No benefit, no productivity gain and no return is modelled anywhere on it: nothing in the dataset supports one.

Phasing bars are the same fiscal-year budget phasing used on the Roadmap tab, at the same scale. They are budget intent, not a delivery schedule.

1. 1Loan servicing vendor support ends2026-06-30 · 64 days ago
2. 2Regional office network contract expiry2026-12-31 · in 120 days
3. 3Disbursement request cutover2027-04-01 · in 211 days
4. 4Endpoint fleet end of life2027-09-30 · in 393 days
5. 5Primary data centre hosting agreement expiry2028-03-31 · in 576 days

2 recorded dependencies are contradicted by the dates. A follower cannot start before its predecessor finishes — that is the rule a scheduling tool enforces when you drag a bar. This artefact is read-only, so it checks the rule instead: Determinations modernisation starts 1171 days before Consents Portal re-platform - assessment and inspection finishes; Applicant services portal accessibility and hardening starts 730 days before Regional office network renewal finishes. The arrow is drawn in red and the contradiction is named rather than quietly straightened out.

1 of 22 initiatives carries no recorded start or end date. It is drawn hatched across the fiscal years it is funded in — Executive reporting workspace refresh. Zooming does not sharpen it: annual budget phasing is the only timing this dataset holds for it.

6 coordination links (two initiatives change the same application — they must talk, but neither waits for the other) and 2 blocking links (a recorded predecessor — this one genuinely waits). The distinction is the point: treating every relationship as blocking is what makes a schedule rigid, so only the 2 recorded predecessors get an arrow. The number beside each row is its own count of each, so the structure is readable without drawing every line; the lines themselves come forward on hover or focus. Click a bar or a row name for the initiative's detail.

What moved. 6 of 22 initiatives carry a previous plan, drawn as a thin bar beneath the current one with the shift shown beside the name. 4 moved out (worst +182d), 1 pulled in (best -91d), 1 unchanged. The other 16 have no baseline recorded — which is not the same as not having moved.

Zoom changes the AXIS, never the data. A quarterly gridline does not make an annual figure quarterly, and an initiative with no recorded dates is never given a quarter it does not have. No critical path and no derived running order is drawn: a tie means two initiatives change the same application, carries no arrowhead, and only a recorded predecessor gets one. The previous plan is a recorded baseline, not a reconstruction: where none was recorded, none is drawn, and no movement is inferred from anything else.

Bars use recorded start and end dates where the register holds them. Fiscal-year spend is budget intent, not a delivery schedule, and a divider inside a bar is where a year ends, not where a phase does.

Dated anchors and agreement cliffs

Anchor dates are the single source of truth. Every freeze window and every simulation in this artefact is derived from them, so moving a date here moves everything that depends on it.

Sequencing between initiatives is an editable T3 assumption, not a schedule of record. Coupling (shared entities, must coordinate) is derived and real; a running order is not.

No attack path and no attack graph is drawn. That needs vulnerability and telemetry data this dataset does not contain, and a path drawn without it is a picture of an assumption.

Use this when the network diagram gets too busy to read. Past roughly twenty initiatives a matrix is easier than a web of lines. Every initiative is a row and a column, and a mark means the pair is related. ● means coordination: they change the same application, in no particular order. ▶ means a recorded predecessor, and it points — read it as this row waits for that column.

Rows and columns are clustered: a greedy bandwidth-reducing pass puts related initiatives next to each other, so blocks near the diagonal are groups that move together. Clustering is a permutation — it reorders the same matrix and changes no relationship. 11 of 22 initiatives sit in at least one coordination pair; the rest are isolated rows, which is a finding about the register as much as about the plan.

Both forms are here because each is better at a different job. A network diagram is easier for following one chain from end to end; a matrix is easier for everything else once there are more than about twenty things in it. The relationship graph carries 55, so neither replaces the other.

A cell is a recorded relationship, nothing more. The matrix does not rank initiatives, does not compute a coupling score, and does not claim the clusters are teams, releases or workstreams — it claims only that those initiatives touch the same applications. An empty cell means no relationship is RECORDED, never that none exists.

Built from the same two sources as every other dependency surface here: the intersection of initiative footprints, and the recorded predecessor field.

Three questions, three readings of the same data. Applications answers what feeds what. Initiatives answers how the programme is tied to itself — a dashed curve where two initiatives change the same application, a solid arrow only where a predecessor is actually recorded. Both puts the programme inside the estate it changes.

33 applications, 20 initiatives, 28 application-to-application edges, 6 couplings, 2 recorded predecessors and 34 footprint links. Ring position carries no meaning — it is alphabetical within a group, not a rank, a score or a distance. 1 recorded edge not drawn: it attaches to a target state, which is a plan rather than something running, so it has no node here. That is why this count is 28 where the register's own reconciliation says 29.

This is a record of what the register says connects to what. It is NOT an attack graph, a data-flow diagram or a failure model: nothing in this dataset describes what happens when a node fails. An edge that is not drawn means the relationship is UNRECORDED, never that it does not exist.

Edges are the dependency records, the initiative footprints and the recorded predecessors — the same data the Dependencies, Register and Plan tabs count.

Cut the plan in 5% steps and watch what it costs. The cap is a share of the AUTO-RANKABLE pool ($49,920,000 across 20 initiatives), not of the whole plan: left on the whole plan the lever is inert whenever the unrankable tray is large.

2 initiative(s) ($3,830,000) are held in a MANUAL-ONLY tray. They have no priority rank or no modelled reduction, so the automatic cut order cannot rank them. They are never defunded first - using the coverage gap as a defund pool is the exact behaviour the funding stepper is gated against.

The same plan at every funding level. Obligations are committed first; the discretionary set is then funded in Prioritisation rank order until the money runs out. Move the slider and the schedule redraws — a deferred initiative is drawn hollow, not deleted, because deferring is a decision that stays visible.

1 initiative has no start or finish date and is drawn hatched, across the fiscal years the money is phased into rather than the period it actually runs: Executive reporting workspace refresh. The bar is a funding window, not a schedule.

A cut can break the plan, not just shorten it. At 0% funding, Applicant services portal accessibility and hardening is funded while Regional office network renewal is not — and the register records the second as a predecessor of the first. The model has no way to see that: it ranks initiatives one at a time. Sequencing has to be re-checked after any cut, and this tab flags it rather than drawing a plan that cannot run.

At 50% of the plan, 11 of 22 initiatives are funded and 53% of the modelled risk reduction survives — the shape of that curve, not the endpoints, is the argument. Obligations alone are $11,840,000, so any level below 25% funds nothing discretionary at all.

This lever and the one above it do not use the same denominator. The engine's trade-off caps on its auto-rankable pool ($49,920,000 across 20 initiatives) and holds the rest in a manual tray; this ladder caps on the whole plan ($53,750,000 across 22) and ring-fences obligations before anything is cut. Two levers, two different meanings for the same percentage — so 50% here is not 50% there, and the two are not to be read against each other.

Funding stops at the first initiative that does not fit, not at the last one that does. Skipping over an unaffordable item to buy cheaper ones further down is a different decision from funding in priority order — and it lets an initiative be funded at one level and cut at a higher one, which is not a plan anyone can act on. The price of the stricter rule is headroom left unspent at most levels; the readout above names it at every step rather than quietly filling it.

A deferred initiative does not return its money today. Spend is phased across years, and cutting an initiative that is already part-delivered recovers only what has not been committed — the dataset holds no commitment position, so this tab shows the plan value, not the recoverable amount. Nor is anything rescheduled: the surviving bars sit exactly where they sat, because freeing budget does not by itself pull work forward, and drawing it as though it did would invent a schedule nobody has agreed. The cut order comes from a model whose weights are a choice — see Prioritisation for how much of this order survives that choice being made differently.

Every level is computed at build time and embedded; the slider selects between precomputed sets and calculates nothing. Rank order comes from the Prioritisation tab, obligations from the register.

This sits BESIDE the baseline plan and is never added into it. The baseline plan total on every other tab is unchanged by this layer, and a gate fails the build if it moves.

Line-to-initiative matching: 10 clean, 1 name drift, 0 ambiguous, 2 unmatched. Ambiguous lines are reported, never split by rule.

A PROPOSED window is not an agreed one and is never drawn as though it were. Each window is derived from its anchor date plus an offset, so it moves when the anchor moves.

Every agreement this build knows about, aged at build time against 2026-09-02, with the register’s own route status and next action beside every day count. One table, one day-count implementation, one tier statement. transcription T1 - name, supplier, date, route status and next action are reproduced VERBATIM from the agreement register, including its own spelling; date accuracy T2 - the register is a planning snapshot maintained by the IT vendor-management function, not an extract from executed agreements.

2 agreements in the agreement register carry an expiry date that has already passed, and the register’s stated next action for each is written as something to be done rather than something done. The register records a remediation status for 2 of them, reproduced above verbatim; for the other 0 it records none, and this page asserts nothing either way about those. It states what the register holds: a date that has passed, and an action still phrased as an instruction.

Sorted most overdue first. Day counts are computed at build time from 2026-09-02 and re-age on every rebuild — they are not stored figures. transcription T1 - name, supplier, date, route status and next action are reproduced VERBATIM from the agreement register, including its own spelling; date accuracy T2 - the register is a planning snapshot maintained by the IT vendor-management function, not an extract from executed agreements.

Verified, not asserted: a build gate scans agreements[], anchors[], every key in the build data object and every key in the payload embedded in this file (420 distinct across the two, walked recursively and unioned) and the header row of the agreements CSV for any notice / termination / extension / renewal field, and stops the build if an undeclared one appears — because the correct response to real notice data is to render it and retire this panel, not to leave the panel standing beside it. It is a scan of field names: it cannot see a notice period written into free text, which is why the claim above is about fields. 42 key(s) exist only in the embedded payload and are covered by the union: align, apps, broken, budget, cells, criterion, critical_points, currency, cut, days, domain, exposure_driver, funded_from, funding, fys, group, groups, headroom, horizon, inits, level, levels, mandated, monitored, objective, obsolescence_driver, over, parts, phasing, points, rank_high, rank_low, rating, scored, scores, segments, spend, stopped, swing, tray, window, year_index.

The 10 things that come closest — and why none of them is a notice period

Shown in the source’s own words so the reader can judge the reading rather than take it. None of the 10 is a notice period, a termination right or an option term.

The most decision-relevant fact on this tab is a GAP. It is stated in words, and deliberately NOT drawn as an empty column: blank cells read as "no notice requirements apply", which is the opposite of what is known, and an empty column is byte-identical to a renderer that failed.

All 18 rows in full, nothing hidden behind a filter: 13 with a recorded expiry date (aged from 2026-09-02) and 5 without, grouped and labelled at the end. transcription T1 - name, supplier, date, route status and next action are reproduced VERBATIM from the agreement register, including its own spelling; date accuracy T2 - the register is a planning snapshot maintained by the IT vendor-management function, not an extract from executed agreements.

These links are CURATED in the data. Nothing here is auto-joined on name similarity: a name match between a register row and an entity is a guess, and a guess drawn as a join is indistinguishable from a confirmed mapping once it is on a page.

The coarse column is a display granularity, never a verdict. A row that passed its date earlier in the current month reads EXPIRED here, not "this month": the expired decision is taken from the day count on the right, and a build gate fails if the two ever disagree.

Contradictions are NAMED, not resolved. Picking whichever date is more comfortable and publishing that one would make the artefact internally consistent and externally wrong.

This artefact carries agreement dates in TWO places: the register, and the dated anchors that drive the roadmap cliff markers. They are not the same source and they do not agree. The pairs compared here are DECLARED in cliffs.anchor_links, never inferred from name similarity.

• Dates cluster on month boundaries. 11 of 13 recorded dates (85%) fall on the first or last day of a month, and 4 of them on the last day of the configured fiscal year (06-30). That is the signature of dates entered at planning granularity. Treat any single date as accurate to about a month unless the executed agreement has been checked.
• The stated period moves independently of the date on some rows. 1 rows have one without the other, computed at build time, so the field is not purely derived from the date on this data and may carry information. It is still not used as a cross-check here: a 12-month bucket cannot see most date errors, and the co-presence test says only that the two are not identical, not that either is right.
• The route status field is populated for 17 of 18. The other 1 row is blank. Blank means not recorded, never “nothing needed”.
• The effort field is 56% blank — never sort, rank or colour by it. Populated on only 8 of 18 rows. A sort on this column would order the agreement register by which cells someone happened to fill in. It is not rendered as a sortable or coloured dimension anywhere on this tab, and should not be added as one.
• Hand-entry artefacts are reproduced as-is · 4 found. Found by shape, not by a list in the code: status on Levy scheme sector partner portal support has a trailing question mark - the register hedging in its own hand; counterparty on Regional office network services has leading or trailing whitespace; counterparty on Primary data centre hosting has an embedded line break; action on Safeguards case management support has a typographic character left by a paste. They are not corrected here. This tab must reconcile line by line against the source file, and a silent tidy-up is an undocumented edit to someone else’s register. They are also the clearest available evidence of how the register is maintained.
• Only 17 of 18 agreements are linked to an entity in this model. Those links are curated in the data. The remaining 1 are not auto-joined on name similarity. Coverage is a data ask, not a derivation.
• Free text on this tab is rendered as visible, screenshot-able text. The register’s own route status and next-action strings are reproduced verbatim. If they name individuals or commercially sensitive detail, that is a wider surface than the same strings sitting in a data file. Stated so the release owner can decide, not silently widened — and the withheld-content guard runs over this tab like every other.

No per-row confidence band and no date-shape ranking is published. There are two states on this tab, date held and date not held. A confidence score would have to be built out of the register’s own fields, and the co-presence test above is how you find out whether those fields are independent enough to carry one.

These qualifications apply to the whole file. Repeating them on every row would train the reader to skip them; stating them once, here, is the alternative. Every figure in this list is derived at build time from the register itself.

What this tab says, before the caveats that qualify it. Every figure below is repeated in full — with its caveats, which are where the meaning is — in the sub-tabs that follow.

There is no posture score here, and there will not be one. Every number on this card set already exists below with the caveat that qualifies it, and each card says where. A composite would average an exposure score against a monitoring count against a concentration ratio — three different kinds of thing — and produce one number that hides the maximum, which is the only one worth acting on. Nothing here is ranked either: the order is what an executive needs first, not what is worst.

Read from the engine's derived cyber layer and risk-reach model at build time. If a layer is absent, its card is absent — nothing here is a written headline that outlives the data behind it.

A count tells you how many. This tells you whether they are a cluster or a scattering, and whether anyone is paying for them. Every application that carries both scores is placed by the two drivers the exposure count is built from; the ones that carry only one are named underneath rather than plotted. The shaded corner is that count — 4 applications at or above 4 on both. Watch what sits just outside it: those are one authored point from being in the corner, and they never appear in the number.

Every application in that corner is touched by at least one initiative. Being touched is not being fixed — the plan funds work on them, which is a different claim from the risk being closed.

15 applications sit within one point of the corner without being counted in it: Consents Portal - Lodgement, Consents Portal - Assessment, Enforcement and Compliance Register, Payments Gateway, Sector Reporting Workspace, Procurement and Supplier Portal, Travel and Expense System, Records and Correspondence Archive, External Collaboration Workspace, Complaints and Review Intake, Open Data Catalogue, Guidance and Standards Repository, Regulatory Analysis Environment, Identity and Access Directory, Endpoint Management Service. On a five-point authored scale that is one assessor's judgement, not a real boundary, which is why the band is drawn rather than left off the picture.

3 applications cannot be placed at all — they carry no score on one or both drivers, so they are absent from the plot rather than drawn at the origin. Plotting an unrated application at zero would draw it as the safest thing in the estate: Backup and Recovery Service, Storage Array (primary data centre), Legacy Reporting Warehouse.

The panel below counts 4 untestable, this map counts 3. The difference is Consents Portal (target): the exposure count runs across every entity in the register, and this map plots only what is running today, so the recorded target state is left out — a target state is a plan, not a thing that can be exposed. Neither figure is wrong; they are counting different sets.

Both axes and the bubble size are authored scores, not measurements, and the threshold is a configured choice — so the corner is a convention, not a cliff. There is no composite here and there will not be: averaging exposure against support life would hide the maximum, and the maximum is the number that matters. There is no likelihood, no attack path and no exploitability, because the dataset carries no vulnerability or telemetry data and a path drawn without it is a picture of an assumption. Position says where an application sits on two named drivers; it says nothing about whether anyone is trying to attack it.

Plotted from the same authored driver scores the exposure count is derived from, and the quadrant is reconciled against that count at build time — if the two disagreed, this panel would fail the build rather than publish a second number.

The engine's lead finding, in the order a person would say it. The panel itself sits underneath, collapsed — it is written to be correct before it is written to be quick, so it opens with its own caveats, and those are the last thing a reader needs first. It remains the authority: where it and this differ in wording, believe it.

On each row of that panel the circle is Exposure to Untrusted Networks and the square is Support Lifecycle Risk, on the 0–5 scale above them. They are never added: a 5 and a 2 would total the same as a 4 and a 4, and only one of those is this finding.

Read from the same derived object the panel below renders from, so the two cannot disagree.

4 entities score 4 or above on BOTH Exposure to Untrusted Networks and Support Lifecycle Risk. 0 sit at the maximum on both. 0 of them have no initiative touching them and no funding - and those two facts are one finding, not two.

Coloured by the two exposure dimensions only. The composite risk_rating is NOT used here: 3 of its drivers (Business Criticality, Resilience, Supplier Concentration) are not measures of exposure.

"No initiative" and "no funding" are ONE finding, not two. The funded flag is derived from initiative coverage - it agrees with "an initiative touches this entity" on 34 of the 34 register entities - so the two clauses are collinear and must not be read as two converging lines of evidence.

THIS COUNT IS A FLOOR. 4 of the 34 register entities carry no Exposure to Untrusted Networks and/or no Support Lifecycle Risk score at all, so they could not be tested against the threshold and are absent from the plot rather than shown to be safe: Backup and Recovery Service; Consents Portal (target); Legacy Reporting Warehouse; Storage Array (primary data centre).

2 of the 4 belong to one entity family (Consents Portal).

7 of the 17 log sources are live. 10 are PLANNED - which is labelled NOT MONITORED TODAY throughout, because a roadmap entry is not a control. 1 of the unmonitored sources map to entities in the exposed-and-unsupported set, covering 2 of those entities. 2 of the exposed set belong to one entity family (Consents Portal), and that family is on the not-monitored list.

"Planned" is labelled NOT MONITORED TODAY throughout. A roadmap entry is not a control, and counting planned sources as coverage is the most common way a monitoring picture flatters itself.

The link from a log source to register entities is a name-prefix match declared in config, not a field in either source document - T3. The two underlying lists are T1. T3 modelled / inferred

THE INTERSECTION IS A FLOOR, NOT A TOTAL. Only 3 of the 10 unmonitored sources have a name-prefix rule that can be tested against the 4 exposed-and-unsupported entities; the remaining 7 (Licence Renewals System, Payments Gateway, Applicant Services Portal, Regional Office Network Gateway, Databases, Regional office network switching, Virtualisation platform) have NO rule and were NOT assessed - they are not sources that were checked and came back clear.

2 monitoring gap(s) are recorded as accepted and unfunded. The aggregate is published; which ones they are is on the in-tenant dashboard.

3 of the 10 Information Security Assurance Framework (illustrative) standards are unchanged by the programme (post == current): Asset and configuration management; Third-party and supply chain assurance; Security awareness. A further 2 move by no more than 0.25 of a point on the 0-5 scale (Response planning 2.50->2.75; Network segmentation 2.00->2.25), so 5 of 10 end the programme at or within 0.25 of a point of where they started. The lowest-scoring standard that does not move at all is Asset and configuration management at 1.75.

6 of 11 change band; 4 strengthen within band

Ordinal band positions: 0 = Not Effective · 1 = Partially Effective · 2 = Effective.

6 of the 11 controls change effectiveness band. The other 5 do not: their label gains a qualifier while the band stays the same, which is a wording change in the source, not a measured band change. They are ringed and labelled NO BAND CHANGE for that reason.

The controls dumbbell places effectiveness labels on an ordinal axis so the pairs can be drawn. The source carries 3 bands; a qualifier suffix is not a band of its own, and the half-step it is drawn at is a drawing device (T3). Every count on this panel is computed on the RAW BAND with the suffix stripped, never on the drawn position. The labels themselves are T1. T3 modelled / inferred

The same 11 sub-risks the panel below holds, with the two stated destinations shown side by side instead of suppressed. The engine declines to draw a single target because the registers disagree, and it is right to — but “they disagree” does not say whether the gap is Low against Medium or Low against High, and those are different arguments to walk into. Showing both, attributed, decides nothing.

7 of 11 rows have two registers pointing at different destinations; 1 exists in only one of the two registers; 10 of 10 carry a planned control that is a character-for-character copy of the existing one. Each of those is a property of the register entry, not of the risk.

A planned control identical to the existing one is not a plan. 10 rows here state the same string twice, which is a data-entry artefact rather than evidence that a barrier is being added — and it is why neither this panel nor the one below will draw a barrier or bowtie view from these fields.

These risks are not linked to anything else in this pack, and that is a property of the data rather than an omission here. A register row carries an id, a title, two ratings and two free-text control strings — there is no application reference, no initiative reference and no owner anywhere on it. Joining these rows to the estate by matching words in their titles would manufacture a link the register does not hold, which is the one defect this pack refuses hardest. Nothing is averaged either: three ordinal bands on an authored scale are counted and compared, never scored. Where this panel and the one below differ in wording, <b>the panel below is the authority</b> — this one adds columns, not judgements.

Read from the same derived register object the panel below renders from. Every column here is a field that already exists on the row; nothing is inferred, joined or scored.

10 of the 10 register rows carry an IDENTICAL existing-controls and planned-controls string (only 9 distinct values across the whole register). That is a data-entry artefact, not evidence that planned barriers exist. No barrier / bowtie view is drawn from these fields.

No barrier / bowtie view is drawn from these fields.

KEYWORD BUCKET, NOT A FAILURE DOMAIN. "Network / connectivity" is a normalised label applied to dependency TEXT. The text underneath it mixes regional office circuits carried by third parties, internet egress for client and public channels, WAN circuits to the primary data centre, and cloud interconnect to the identity, dealing and payments services. Those are unrelated failure events: one bucket is not one thing that can fail. The sub-buckets below are a keyword split of the same text (T3) offered so the bucket is not read as a single point of failure; an entity can appear in more than one.

5 entities match more than one sub-bucket, so this column deliberately does not sum. T3 modelled / inferred

Only 30 of the 33 assessed entities carry any dependency text at all, so every count on this table is a FLOOR, not a count. An entity absent from a bucket has not been shown to be independent of it. These are floors.

"Resolved" means the far end names something we model - it does NOT mean the edge is verified. Of the 29 resolved edges, 11 are T1; 12 are T2; 6 are T3. Only 11 of the 29 entity-to-entity edges is documented in a non-draft source at all.

A fifth thing no edge can show: 3 of the 33 assessed entities carry no dependency text at all. They are never not connected - they are unrecorded.

Provenance re-tier

29 entity-to-entity edges were re-tiered from each edge's own recorded source string. Before: T1 29. After: T1 11, T2 12, T3 6.

Node identity

1 dependency endpoint reference(s) were merged onto their canonical register entity (Consents Portal - target state -> Consents Portal (target)). 0 self-loop(s) and 0 duplicate edge(s) created by the merge were dropped; pre-existing duplicates elsewhere in the graph are deliberately left alone, because removing them would move a published denominator as a side effect of an identity fix.

An unresolved endpoint is silently dropped by a force graph and renders as white space, which reads as "no dependency". A gate now fails the build if any entity-typed endpoint is outside the register.

Direction

Enterprise Data Warehouse has 7 inbound dependency edge(s) - entities that feed it - and 3 outbound edge(s) to register entities (7 to endpoints of any kind). INBOUND IS NOT BLAST RADIUS. Downstream blast radius is the outbound side, and the register-entity figure is a floor because components and named external parties are downstream too.

inbound is not blast radius.