01 · Analysis
Selected source checksAnalysis
Harten reconstructed this International Waste Shipments application from an approximately 292,000-line public repository over three days. The resulting account covered notification, assessment, consent, shipment records, financial guarantees, documents and audit. Read the published reconstruction paper.
The source checks below show two examples of the behavioural detail recovered from the application.
Application finding
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. Combining them into one deadline rule would lose the workflow, triggering event and calendar semantics.
Specification implication. Keep the rules separate and record the purpose, starting event, date boundaries and competent-authority calendar for each one.
Source checked: MovementDateValidator, FinancialGuarantee and WorkingDayCalculator. These describe implementation behaviour, not current legal requirements.
Application finding
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.
Specification implication. Capture the lifecycle, status history, decision dates and the relationship between an approved guarantee and movement eligibility.
Source checked: FinancialGuarantee and ActiveApprovedFinancialGuarantee. The link to a current approved guarantee is source-confirmed. Whether all existing approval, release and supersession behaviour is still required is a service decision.
Back to journey ↑
02 · App specification
Current-system specificationApp specification
The reconstructed specification connects business capabilities, component relationships, information and flows across the application.
| Specification area | What the specification needs to capture |
|---|
| Dates and calendars | Separate rules by workflow, starting event, inclusion rules and calendar data. |
|---|
| Guarantee lifecycle | Permitted transitions, decision data, status history and movement eligibility. |
|---|
| Notification and shipment records | The relationships between notification, shipment records, documents and audit. |
|---|
Application finding
Different date rules are not automatically a conflict
The movement-date rule and the guarantee-decision rule use different triggers and calendars. The specification should preserve them as separate behaviours unless the organisation deliberately decides to change them.
Back to journey ↑
03 · Modernisation plan
Planning implicationsModernisation plan
The findings show where a modernisation plan must account for behaviour that crosses application boundaries: date calculation, financial-guarantee lifecycle and movement eligibility.
Those relationships can then be used to sequence changes without treating each component as an isolated technical replacement.
Back to journey ↑
