Modernisation proposal for review; durations are indicative.

delivery-slices.md

This is an unapproved delivery proposal. Estimates are planning ranges rather than commitments and assume access to suitable non-production environments, source material and reviewers. They do not imply staffing, cost, production readiness or semantic completeness. Business calendars, change freezes, downtime allowances, licences, supplier lead times, production-like data and shared-environment contention remain unresolved. Estimates must be recalibrated after the first accepted slice using observed agent effort, human effort, waiting time and elapsed time.

DSL-001 Recover and Characterize the Executable Baseline

Changes: Recover the Executable and Operational Baseline; Establish Compatibility Characterization. Verifications: Verify the Executable Baseline and Compatibility Catalogue. Prerequisites: None. Owner: joint. Agent effort: Inventory supplied artefacts, compare configuration and interfaces, generate characterization candidates, classify discrepancies and maintain the compatibility catalogue; execution evidence and interpretation still require human review. Human effort: Application, platform, database, security and operations participants provide access, demonstrate runtime behaviour, identify operational dependencies and accept the inventory and unresolved gaps; availability is not assumed. Waiting time: Environment, source, database, configuration, log, file-store, supplier and operational-contact access may dominate elapsed time. Elapsed working days: 15 / 30 / 60.

The outcome is a reproducible non-production build and deployment, an authoritative inventory of discovered components and consumers, and one representative journey traced through identity, authorization, validation, persistence, audit, events, files or external effects, response and failure handling. This is the foundation for every later slice because compilation and existing tests do not prove executable or production behaviour.

The evidence-resolution gate requires confirmation of runtime and operating-system dependencies, database provider and migration state, active routes and middleware, background work, integrations, topology, configuration sources, backup arrangements and current authentication schemes. Acceptance requires repeated deployment, controlled configuration and schema state, documented successful, denied, malformed and dependency-failure observations, deployment recovery, a non-production restore demonstration and accountable review of exceptions. Unknown callers and production-only behaviour remain explicit blockers for affected changes.

Related changes: CHG-001, CHG-002

Related verifications: VER-001

DSL-002 Establish Measures and Approval Evidence

Changes: Establish Measures, Scenarios and Approval Gates. Verifications: Verify Measures, Scenarios and Approval Gates. Prerequisites: Recover and Characterize the Executable Baseline. Owner: joint. Agent effort: Derive candidate measurement definitions, instrument evidence collection where approved, separate automated runtime from human and waiting time, and prepare repeatable calculation and scenario templates. Human effort: Product, security, data, architecture, platform and operations representatives select measures, approve definitions and assign accountable ownership; no owner or target is presumed. Waiting time: A representative sampling period and access to deployment, incident, restore, security and reconciliation records are required before baselines can be credible. Elapsed working days: 8 / 18 / 35.

The outcome is a governed measurement catalogue for adopted indicators such as deployment frequency, change lead time, failed-change rate, restoration time, restore success, unresolved security findings, dead-letter age, reconciliation differences, authorization-test coverage and incidents. Each adopted measure must have an approved owner, source, baseline, target, sampling period and calculation method.

Acceptance requires evidence that values are measured rather than inferred and that scenario assumptions expose human effort, agent runtime, supplier or reviewer waiting, environment contention and elapsed time separately. The first slice’s observations trigger re-estimation of every remaining range. Benefit, capacity, readiness and schedule claims remain unverified until measurement and approval gates are satisfied.

Related changes: CHG-022

Related verifications: VER-012

DSL-003 Resolve Identity, Relationships and Authorization

Changes: Centralize Authoritative Party and Relationship Checks; Implement Centrally Testable Authorization Policies; Resolve Identity, Authentication and Secret Management. Verifications: Verify Party Relationships and Authorization Enforcement. Prerequisites: Recover and Characterize the Executable Baseline. Owner: joint. Agent effort: Trace enforcement points, construct action-resource-state test candidates, test tampering and denial paths, and implement bounded policy changes and secret-access integration after contracts are approved. Human effort: Security, product and application representatives decide identity lifecycle, authorization scope, exceptional access and relationship cardinalities and review high-impact actions. Waiting time: Identity-provider access, client and scope inventories, security review, external-user decisions and key-rotation facilities may delay acceptance. Elapsed working days: 20 / 40 / 80.

The outcome is an approved matrix covering identities, organisations, authorities, ownership, membership, resources and lifecycle state, followed by bounded activation of centrally testable policies. Every affected mutation must reload authoritative relationships rather than trust posted or hidden values. Existing allowed and denied outcomes remain preserved until reviewed.

Evidence gates include direct investigation of anonymous reachability, default-allow behaviour, state-changing retrieval methods, bearer and cookie precedence, malformed claims, inactive users, account recovery, auto-confirmation and attacker-influenced temporary-state deserialization. Acceptance requires tested deny paths, preservation of user-to-business relationships, no reliance on client controls, protected secrets where adopted and characterized behaviour during identity-provider outage, credential expiry and key rotation. Microsoft Entra ID, managed identities and Key Vault remain candidates rather than approved selections.

Related changes: CHG-007, CHG-008, CHG-009

Related verifications: VER-004

DSL-004 Formalize Lifecycles and Identifiers

Changes: Formalize Notification and Assessment Lifecycles; Separate Movement, Shipment, Receipt and Outcome Rules; Define Identifier Allocation and Lookup Contracts. Verifications: Verify Lifecycle and Identifier Contracts. Prerequisites: Recover and Characterize the Executable Baseline; Resolve Identity, Relationships and Authorization. Owner: joint. Agent effort: Capture observed transitions and identifier behaviour, generate boundary and concurrency tests, implement approved state and allocation controls, and compare persistence, audit, event and response effects. Human effort: Product, policy, movement, finance, reporting and data representatives resolve contradictory states, outcome precedence, actor permissions and identifier scope. Waiting time: Decisions on submitted versus awaiting-payment, partial rejection, terminal states, number formats and concurrent allocation may be the controlling delay. Elapsed working days: 20 / 45 / 90.

The outcome is separate, explicit contracts for notification, assessment, movement, shipment, receipt, rejection, recovery, completion and cancellation, preserving import, export and transit asymmetry. Enum order will not define lifecycle order. Identifier contracts will define normalization, visible format, uniqueness scope, malformed and unmatched results, shipment bounds and concurrency behaviour.

Acceptance requires approved transition and identifier contracts and tests for duplicate, stale and repeated commands, simultaneous allocation, failed saves, bulk interruption and event failure. State, editability, authorization, persistence, audit, events and failure semantics must reconcile at record level. No target state machine, uniqueness constraint or direct state-changing replacement is activated while its underlying decisions remain unresolved.

Related changes: CHG-004, CHG-005, CHG-006

Related verifications: VER-003

DSL-005 Resolve Calculations and Reference Meanings

Changes: Establish Authoritative Date and Calendar Semantics; Define Quantity, Unit and Rounding Contracts; Isolate Finance, Pricing, Payments and Refunds; Resolve Guarantee Cardinality and Decision Semantics; Preserve Route, Waste and Reference-Data Meaning. Verifications: Verify Dates, Quantities and Financial Calculations; Verify Guarantees, Routes and Reference Meanings. Prerequisites: Recover and Characterize the Executable Baseline; Formalize Lifecycles and Identifiers. Owner: joint. Agent effort: Profile relevant records, build boundary and record-level comparison suites, preserve historical distinctions, and implement only approved calendar, calculation, guarantee and reference-data rules. Human effort: Policy, business, finance, data, guarantee and security representatives decide contradictory rules, legal or policy meanings, precision, precedence, cardinality and separation-of-duty requirements. Waiting time: Authoritative calendar sources, financial decisions, historical-data interpretation and scarce specialist review can extend elapsed time materially. Elapsed working days: 30 / 65 / 130.

The outcome is an approved set of workflow-specific date, unit, quantity, rounding, pricing, refund, guarantee, route, facility and classification contracts. Historical obsolete, not-listed, not-applicable and sentinel values remain distinguishable. Heuristic conversions, commented-out limits and aggregate equality are not accepted as authority.

Evidence gates require profiling multiple approved guarantees, route ordinals, facility and treatment-site cardinalities, mixed units, decimal precision, overlapping prices, records containing both credit and debit, and conflicting date limits. Acceptance requires record-level comparison, classified discrepancies, server-side validation of untrusted values, concurrent guarantee and financial tests, and explicit decisions on warning versus blocking rules. No silent normalization, reclassification, deduplication or new guarantee uniqueness constraint is permitted.

Related changes: CHG-010, CHG-011, CHG-012, CHG-013, CHG-014

Related verifications: VER-005, VER-006

DSL-006 Introduce Modular and Durable Mutation Boundaries

Changes: Introduce an Incremental Modular Deployment Model; Introduce Durable Integration Delivery; Strengthen Transaction, Concurrency and Audit Boundaries; Deliver Through Reversible, Independently Verifiable Slices. Verifications: Verify Modular Deployment and Reversible Delivery; Verify Durable Effects, Transactions and Audit. Prerequisites: Recover and Characterize the Executable Baseline; Resolve Identity, Relationships and Authorization; Formalize Lifecycles and Identifiers. Owner: joint. Agent effort: Detect coupling and cross-boundary writes, implement a bounded compatibility interface, transactional seams and outbox candidates, and automate failure, replay and reconciliation tests. Human effort: Architecture, application, security and operations representatives approve authority boundaries, synchronous expectations, retry and ordering contracts, replay authority and recovery choices. Waiting time: Azure option validation, networking, dependency access, operational review and shared integration environments may control delivery. Elapsed working days: 25 / 55 / 110.

The outcome is one bounded capability operating behind preserved interfaces with a single authoritative writer, prohibited cross-boundary writes, controlled activation and documented rollback or forward recovery. Azure App Service is preferred only if baseline evidence supports it; Container Apps and bounded Functions remain conditional alternatives. A service-per-domain model and Azure Kubernetes Service are not assumed.

Where adopted, a transactional outbox and Azure Service Bus candidate must preserve required synchronous responses while making integration intent durable. Acceptance requires tests for failed saves, termination after commit, duplicate and out-of-order delivery, poison messages, dependency timeouts, replay and dead-letter handling. Audits must distinguish attempted, denied, failed and successful outcomes. Feature flags affecting authority, security or data meaning require restricted administration, audit, safe defaults and removal plans.

Related changes: CHG-003, CHG-016, CHG-018, CHG-021

Related verifications: VER-002, VER-008

DSL-007 Secure Files and Preserve Generated Documents

Changes: Secure Uploads, Downloads and Generated Documents. Verifications: Verify Files, Scanning and Generated Documents. Prerequisites: Recover and Characterize the Executable Baseline; Resolve Identity, Relationships and Authorization; Introduce Modular and Durable Mutation Boundaries. Owner: joint. Agent effort: Characterize file flows and generated outputs, automate metadata and document comparisons, implement quarantine and private-storage controls after selection, and test interruption and orphan reconciliation. Human effort: Security, data, operations and document consumers decide scanner outcomes, retention, legal hold, cleanup, rescanning and acceptable document differences. Waiting time: Scanner and conversion suppliers, protected representative files, retention decisions and consumer comparison reviews may cause substantial delay. Elapsed working days: 18 / 40 / 85.

The outcome is a bounded file capability that preserves authoritative relational ownership, filenames, versions, layouts, ordering and visible content while strengthening upload, download and scanning controls. Private Azure Blob Storage is a preferred candidate, not an approved destination.

Acceptance requires authorization tests, content-type and active-content checks, safe name and path handling, quarantine and promotion evidence, interrupted-transfer recovery, temporary-file cleanup and restoration from retained source material. Clean, virus, unknown, error, timeout and outage results require approved handling; unknown or unavailable scanning must not be treated as clean by assumption.

Related changes: CHG-015

Related verifications: VER-007

DSL-008 Establish Reporting and Operational Readiness

Changes: Separate Reporting Read Models Without Changing Outputs; Establish Azure Observability and SRE Operations. Verifications: Verify Reports and Operational Readiness. Prerequisites: Recover and Characterize the Executable Baseline; Introduce Modular and Durable Mutation Boundaries. Owner: joint. Agent effort: Capture report fixtures, compare record, field and presentation outputs, add correlated telemetry, and exercise operational and reconciliation runbooks. Human effort: Report consumers, product, data and operations representatives approve output compatibility, freshness, alert ownership, escalation and recovery procedures. Waiting time: Representative report data, downstream-consumer access, telemetry retention decisions and observation periods remain external dependencies. Elapsed working days: 18 / 40 / 80.

The outcome is controlled reporting read models or replicas only where freshness permits, plus correlation across requests, database work, outbox processing, messages and dependencies. Existing columns, aliases, workbook structures, ordering, status derivation, null handling and date boundaries remain preserved until accepted comparison supports change.

Acceptance requires small, empty and large report comparisons, authorization and sensitive-export checks, observed refresh and divergence behaviour, operational alert ownership, tested runbooks and backup restoration. Azure Monitor, Application Insights and Log Analytics remain candidates. Availability, performance, support hours, retention, report freshness, recovery-time and recovery-point objectives remain approval decisions rather than inferred targets.

Related changes: CHG-017, CHG-020

Related verifications: VER-009

DSL-009 Rehearse Deterministic Migration, Cutover and Recovery

Changes: Profile and Migrate Data Deterministically; Deliver Through Reversible, Independently Verifiable Slices; Establish Azure Observability and SRE Operations. Verifications: Verify Deterministic Data Migration and Recovery; Verify Cutover, Coexistence and Retirement. Prerequisites: Resolve Calculations and Reference Meanings; Secure Files and Preserve Generated Documents; Establish Reporting and Operational Readiness. Owner: joint. Agent effort: Execute profiling, preflight diagnostics, deterministic transformations, checkpoint and rerun tests, record-level reconciliation and controlled-routing rehearsals. Human effort: Data, business, security, operations and change authorities classify discrepancies, sample migrated records, approve authority boundaries and decide rollback, forward recovery, activation and retirement. Waiting time: Production-like data access, backup facilities, supplier attendance, change-freeze decisions, business calendars, consumer confirmation and full-rehearsal scheduling are critical dependencies. Elapsed working days: 30 / 70 / 150.

The outcome is a production-like rehearsal for each materially different migration pattern, followed by a full cutover rehearsal. Transformations must preserve source evidence, historical meanings and rejected records; define deterministic mappings, checkpoints, rerun behaviour and recovery; and avoid uncontrolled dual writing. Azure SQL Database remains the leading candidate only if compatibility is demonstrated, with Azure SQL Managed Instance retained as a coexistence option.

Acceptance requires classified and owned discrepancies, business-key and referential reconciliation, lifecycle and history continuity, valid financial and quantity comparisons, file and report checks, restore evidence, migration interruption and restart tests, message replay, dependency-failure handling and approved measurable activation and recovery triggers. Production activation and legacy retirement remain unapproved until all callers and scheduled work are addressed, observation and reconciliation are accepted, retained history is accessible, operational ownership is confirmed, and retention and deletion rules are approved.

Related changes: CHG-019, CHG-021, CHG-020

Related verifications: VER-010, VER-011