01 · Analysis
Selected source checksAnalysis
Harten’s reconstruction of this International Waste Shipments application produced a structured account of notification, assessment, consent, shipment records, financial guarantees, documents and audit. The published Harten-controlled run analysed an approximately 292,000-line public repository over three days. That is an observed analysis result, not elapsed time to modernise the application. Read the scope and limitations of the run.
The source checks below examine two areas within that wider account. They show the level of behavioural detail a replacement team needs before choosing how to implement the service.
Application review
Different date rules belong to different decisions
Source finding. The movement-date validator checks that a proposed date falls within consent, is not in the past and is no more than 30 calendar days ahead. The financial-guarantee decision date uses a different path: 20 working days from completion, excluding the start day and passing the competent authority into the calendar calculation.
Engineering consequence. These are different behaviours, not automatically a contradiction between “30 days” and “20 days”. Consolidating them into one deadline rule would lose the workflow, triggering event and calendar semantics.
Review required. Specify the purpose, starting event, date boundaries and competent-authority calendar for each rule. Ask the service owner which behaviour remains required. Proposed tests should include boundary dates, weekends and the applicable bank-holiday data.
Source checked: MovementDateValidator, FinancialGuarantee and WorkingDayCalculator. These describe implementation behaviour, not a statement of current legal requirements.
Application review
A financial guarantee is a lifecycle with service consequences
Source finding. The financial-guarantee model moves from received to complete, then to approved or refused. Approved guarantees can be released or superseded. Transitions raise a status-change event. A separate movement rule returns an error when it cannot obtain a current approved guarantee.
Engineering consequence. Treating a guarantee as a document with an editable status would miss the permitted transitions and the relationship to movement eligibility. Data migration also needs to preserve the context required to interpret existing records.
Review required. Establish how status history, decision dates and approval data are used across the service. Specify allowed and disallowed transitions, then test the movement rule with and without a current approved guarantee.
Source checked: FinancialGuarantee and ActiveApprovedFinancialGuarantee. Current review status: the link to a current approved guarantee is source-confirmed. Whether the replacement must preserve all existing approval, release and supersession behaviour remains for service-owner review; that decision is open. This selected relationship does not cover every movement rule.
Back to journey ↑
02 · App specification
Needs attentionApp specification
The reconstructed account spans business capabilities, component relationships, information, flows and review questions. It gives domain experts a concrete starting point for examining the service across technical boundaries.
| Specification area | What needs to be preserved or decided | Review responsibility |
|---|
| Dates and calendars | Separate rules by workflow, starting event, inclusion rules and calendar data. | Technical review of source paths, followed by service-owner confirmation of required behaviour. |
|---|
| Guarantee lifecycle | Permitted transitions, decision data, status history and movement eligibility. | Domain and technical review together; access and operational use require additional evidence. |
|---|
| Notification and shipment records | Relationships and records needed across the service, including documents and audit. | Confirm downstream use and retention needs with service and operational owners. |
|---|
| Evidence quality | Correct unsupported interpretations and references before relying on the specification. | Harten-led source review, with unresolved decisions assigned to the appropriate owner. |
|---|
Application review
Do not convert a documentation conflict into a business-rule claim
The broader PRSD specification still needs attention. References, diagrams and interpretations require reconciliation before full acceptance. The date example shows the necessary discipline: compare the source path and purpose before concluding that two statements conflict.
The source checks on this page are a limited editorial review. They neither amend the underlying product records nor establish that all outstanding specification questions have been resolved.
Back to journey ↑
03 · Modernisation plan
Planning prerequisitesModernisation plan
This example has reached reconstruction and specification review. A ready PRSD modernisation plan is not claimed. The next planning decision depends on an agreed application boundary, corrected material findings and confirmation of the behaviour the service needs to retain.
Once that baseline is accepted, the team can compare target options and sequence changes around the service relationships shown here. Any proposal to separate date calculation, guarantee processing or movement handling must account for the behaviour that crosses those boundaries.
Back to journey ↑
From a plan to accepted change.
A delivery engagement would need implemented changes, executed verification, data reconciliation and an accepted operational handover. Those outcomes are outside this worked example. No completed production migration is claimed.
