Harten Modernisation Platform

Executive portfolio

Portfolio summary

A portfolio view of what is understood, what should move next, and where human judgement is required.

Portfolio positioning

Business value vs technical debt

Executive attention

Risks & governance blockers

Outcomes

Portfolio velocity & metrics

Change confidence

Your evidence-backed portfolio report

Deterministic scores derived from recorded evidence. AI may summarise; it cannot alter a score.

Application change confidence

Application report

Deterministic confidence, provenance and the next governed decision.

Live Work

Controlled transformation in progress: active work, last observed evidence and anything requiring intervention.

Outcomes

Measured program outcomes and compute economics. Nothing here is a promise; every number traces to run evidence or Azure billing.

Understanding delivered

Compute economics

Decisions

Consequential judgements requiring named human authority, with evidence context.

Service Health

Product guide

How MaaS works

Follow the evidence chain from source intake to a verified outcome. Each phase explains its decision, evidence, unknowns and next permitted action.

Evidence before inference

Every downstream object is pinned to the exact source snapshot that produced it.

Human authority at material gates

Models propose. Named people approve specifications, plans, decisions and release gates.

Fail closed

Missing or contradictory evidence blocks advancement instead of producing a plausible fiction.

Phase 1 · Partition

Build the application baseline

Add a repository, measure its source estate and partition it into bounded work units.

Screen map · Application Baselines

Use: Add Application, then inspect Application Baselines.
Decision: Is the repository measured and safely divided into analyzable work?
Evidence produced: Repository identity, commit/ref, languages, source volume, partitions, work units and batch plan.
Do next: Submit the smallest representative batch to Run Control.

Phase 2 · Run Control

Execute bounded analysis

Dispatch, observe and recover work without losing the application, batch or work-unit lineage.

Screen map · Execution Control

Use: Execution Control for interventions, Live Work for active delivery and Runs for history.
Decision: Did each work unit complete, fail its evidence contract or require recovery?
Evidence produced: Immutable run identity, events, model/runtime provenance, output pointers and teardown state.
Do next: Inspect failed attempts; consolidate completed batches only.

Phase 3 · Documentation

Consolidate application evidence

Review run evidence, recover explicit gaps and weave the complete application cloth.

Screen map · Application Evidence

Use: Run Evidence for one attempt, Evidence Consolidation for batches and Application Evidence for durable outputs.
Decision: Is the application cloth complete enough to support requirements without invention?
Evidence produced: Overview, HLD, LLD, diagrams, requirements, tests, unknowns and file hashes.
Do next: Generate the application specification from the exact completed Loom session.

Phase 4 · Requirements

Specify, plan and decide

Combine evidence with the modernisation brief, then create a governed plan and record material human decisions.

Screen map · Modernisation Plan

Use: Application Specification first, Modernisation Plan second, Decisions last.
Decision: Does the proposal preserve observed behaviour, expose unknowns and define verifiable change?
Evidence produced: Versioned specification, plan synthesis provenance, options, risks, dependencies, tests and attributed decisions.
Do next: Approve only the exact evidence-complete specification and plan version.

Phase 5 · Intelligent Modernisation

Deliver through an immutable envelope

Translate approved authority into bounded work, verify it against the baseline and measure only observed outcomes.

Screen map · Governed Delivery

DecisionEvidence

Use: Governed Delivery creates plan-linked work; Verification compares proof; Outcomes reports measured effects.
Decision: May this exact delivery envelope execute, and did its evidence satisfy the approved baseline?
Evidence produced: Envelope SHA, pinned specification and plan, work orders, ownership, validation, rollback and acceptance results.
Do next: Embed only verified outcomes. A blocked gate is a correct result, not a workflow failure.

Run Administration

Kill a live run or reconcile a stale run summary after teardown has already completed.

Run	Status	Application / work unit	Model	Updated	Resource group	Action

Execution Control

Repository or program Day Batch Run Auto-refresh idle

Run History

Completed and previous attempts for the selected scope.

Application / batch	Work unit	Outcome	Updated	Duration	Actions

Repository journey

Work-unit attempts

Current finding

Evidence

Attempt journey

Run detail

Stream idle

Controller record

Event trail

VM status / callback stream

Output artifacts

Completion event

Teardown

Runs

Every run the controller holds, by day, application, batch and work unit.

Loading run index

Select a date

Run index

Run Evidence

Select a run artifact

Controller-streamed Blob content

Evidence Consolidation

Consolidate application artifacts into HLD, LLD, diagrams, requirements, tests, and open questions.

Select an application

Application cloth

Waiting for application selection

Application Evidence

Browse durable Loom sessions and their generated documentation files.

Choose a generated file

Loom session exports

Choose a date and application

Choose a session and generated file to preview it.

Application Specification

Generate a governed draft from a completed Loom session and a proposed operator target outcome.

Choose an application

Phase 4 draft

Modernisation brief Describe the outcome, constraints, and evidence expectations

Target state What should the modernised application become? Preserve Which observed behaviours and interfaces must remain compatible? Specify Which functional, data, security, operational, and testing detail is required? Govern Which assumptions must be flagged for human approval?

Choose an application and Loom session

Modernisation Plan

Plan before execution: assemble evidence and specification context, then generate a governed plan draft for human review.

Plan context

Planning inputs

Use the governed application specification as the baseline, then add program constraints.

Application Derived from the Loom session Evidence baseline Completed Loom session Transformation objective Restored from the application specification when available Program constraints Optional on first generation · used as revision instructions when regenerating

Choose application, session, and objective.

PLAN-### v#

Draft

No plan loaded.

Phase 5 · Intelligent Modernisation

Governed Delivery

Translate an approved modernisation plan into bounded, evidence-linked delivery work with explicit authority and verification gates.

Work order generation blocked. An approved modernisation plan is required before implementation work can be proposed.

Work order	Status	Owner	Gate	Dependencies	Evidence

Intelligent Modernisation · Verify

Delivery Verification

Compare delivered evidence with the approved specification, plan, decisions, and acceptance tests.

Application Select an application evidence baseline

01 · Baseline

Approved specification

02 · Authority

Plan & decisions

03 · Delivery

Delivered evidence

04 · Proof

Acceptance tests

Investigations

Bounded collaboration contexts showing delegation, findings, challenges, evidence links, and required human review.

Phase 1 · Understand

Application Insights

Application scale, technology profile, and batch analysis progress from partition and runtime evidence.

Application Baselines

RepositoriesDashboard

Application Baseline

Repository plan

Local partition output

Applications

Current partition scope

Execution Batch Ranges

Selected partition plan

Submission

Preparing batch submission

Checking the active batch gate.

Submission JSON

Add Application

Repository URL Target owner Target repo Source ref Max concurrent drones Target lines/work unit

Partition objective

New Fleet Provision

What Must Be Proven Next

Use the run detail panel to prove click a run → controller events, VM state, model progress, generation state, output pointers, and no raw secret leakage.
Redesign the stop/delimiter contract without putting the active stop word in the prompt.
Rerun source-aware documentation only after that redesign.
Require useful section content, no process prose, no cap hit, no repeated tail, clean terminator, and contract_ok=true.
Prove Loom weave cleanly accepts the useful document thread.
After three stable runs, revisit whether MaaS moves out of Hart OS into its own service boundary.

Sign in

Portfolio summary

Business value vs technical debt

Risks & governance blockers

Portfolio velocity & metrics

Your evidence-backed portfolio report

Application report

Live Work

Outcomes

Understanding delivered

Compute economics

Decisions

Service Health

How MaaS works

Run Administration

Execution Control

Execution outcome

Journey coverage

Active now · All programs

Run History

Repository journey

Work-unit attempts

Current finding

Evidence

Attempt journey

Run detail

Controller record

Event trail

VM status / callback stream

Output artifacts

Completion event

Teardown

Runs

Select a date

Run Evidence

Select a run artifact

Evidence Consolidation

Select an application

Application Evidence

Choose a generated file

Application Specification

Choose an application

Choose a specification file

Modernisation Plan

PLAN-### v#

Governed Delivery

Delivery Verification

Approved specification

Plan & decisions

Delivered evidence

Acceptance tests

Investigations

Application Insights

Application Baselines

Application Baseline

Repository plan

Applications

Execution Batch Ranges

Preparing batch submission

Add Application

New Fleet Provision

What Must Be Proven Next