Illustrative ARI portfolio

Prioritise improvement by business criticality and the strength of repository evidence. Open any row for the technical report behind the decision.

Decision boundaryStatic readiness is a prioritisation index. Portfolio zones identify candidates for separately evaluated tasks, not autonomous delivery. Task trials are separate; locally run trials are not sandboxed and verifier strength must be reviewed.

4repositories assessed

1critical systems

1capped by a critical finding

2candidates for bounded task trials

01 · Portfolio order

Where attention goes first

Priority combines criticality, static-score gap, production status, and critical caps. This index helps order remediation priorities; it does not predict outages or rank team performance.

Repository / system	Business context	Static score	Evidence / execution	Next decision	Priority index
payments-corePayments platform · Payments team	critical · production service · high	30/100 · L130	100% stable-check coverage · execution not run	foundation first cap: SAFE-01	400
customer-platformCustomer experience · Experience team	high · production service	84/100 · L284	100% stable-check coverage · execution not run	task-trial candidate	68
policy-apiPolicy services · Core platform	high · production service	100/100 · L4100	100% stable-check coverage · execution not run	task-trial candidate	20
docs-siteDeveloper documentation · Developer experience	low documentation	24/100 · L024	100% stable-check coverage · execution not run	profile review	Not ranked

Not ranked under the current code-centric rubric: docs-site (low, documentation). Review applicability before using their scores for decisions.

02 · Repeated constraints

Systemic fixes

ENV-03 appears in 2 repositories: customer-platform, payments-core
ENV-04 appears in 2 repositories: customer-platform, payments-core
GIT-01 appears in 2 repositories: customer-platform, payments-core
SAFE-02 appears in 2 repositories: customer-platform, payments-core

03 · Agent-task evidence

Trials stay separate

No empirical agent-task trials were supplied. Candidate zones do not establish task success.

04 · Critical risk register

What needs an owner

critical · payments-core: Static score capped by SAFE-01. Review the cited finding and remediate before a task trial.
high · payments-core: Production system with weak static controls. Validate release and rollback controls, then address top repository findings.

05 · Suggested sequence

90-day improvement plan

Days 0–30 · Close critical risks and evidence gaps

payments-core: Review the cited finding and remediate before a task trial.
payments-core: Validate release and rollback controls, then address top repository findings.

Days 31–60 · Remove recurring constraints

Address ENV-03 across 2 repositories, then rerun the same standard.
Address ENV-04 across 2 repositories, then rerun the same standard.
Address GIT-01 across 2 repositories, then rerun the same standard.
Address SAFE-02 across 2 repositories, then rerun the same standard.

Days 61–90 · Prove movement and bound agent use

Reassess with the same rubric and separate rubric effects from repository effects.
Run named, bounded agent-task trials only for agreed candidates.
Review deployment and operational evidence before any production-readiness claim.

A system owner should validate effort, dependencies, and sequencing before committing dates.

Method and limits

Priority index: criticality weight (critical 4, high 3, medium 2, low 1) × (100 − static score), plus 20 for production and 100 for a cap. Documentation, archived, monorepo, and unknown profiles are not ranked until their rubric applicability is reviewed. No cross-repository average is reported. Repository profiles may be manually corrected in the manifest. Static structural diagnostics do not change the score. Execution, when separately requested, is not a security sandbox.