System

New Tyne Crossing Transport Appraisal System, session 6 of decomposition. Status remains in-progress with 6 of 7 subsystems now fully decomposed into components with requirements, interfaces, and verification entries. This session tackled the two remaining infrastructure subsystems: {{entity:Data Acquisition and Management Subsystem}} and {{entity:Geospatial Analysis Platform}}. One subsystem remains: {{entity:Appraisal Reporting Subsystem}}.

Decomposition

The {{entity:Data Acquisition and Management Subsystem}} was decomposed into 6 components reflecting the distinct data domains a TAG-compliant transport appraisal must manage: {{entity:Traffic Survey Data Processor}} {{hex:40A53358}}, {{entity:Planning and Land Use Data Manager}} {{hex:00243279}}, {{entity:Network Data Repository}} {{hex:40853318}}, {{entity:Cost Data Manager}} {{hex:00843378}}, {{entity:Socioeconomic Data Integrator}} {{hex:40A51359}}, and {{entity:External Data Feed Connector}} {{hex:40A53358}}. The architecture follows a hub-and-spoke topology with the External Data Feed Connector as the single ingestion gateway — all external sources (DfT TAG Data Book, ONS, BODS, DEFRA, EA) route through it to enforce version control and provenance logging before distributing to domain-specific processors.

flowchart TB
    EDFC[External Data Feed Connector]
    TSDP[Traffic Survey Data Processor]
    PLUDM[Planning and Land Use Data Manager]
    NDR[Network Data Repository]
    CDM[Cost Data Manager]
    SDI[Socioeconomic Data Integrator]
    EDFC -->|DfT counts, TRADS| TSDP
    EDFC -->|NTEM, TEMPro, planning| PLUDM
    EDFC -->|OS Roads, BODS/GTFS| NDR
    EDFC -->|TAG Data Book, QRA| CDM
    EDFC -->|Census, IMD, BRES| SDI
    TSDP -->|count site linkage| NDR
    TSDP -->|validated counts| ME[Matrix Estimation Processor]
    NDR -->|SATURN network| HAE[Highway Assignment Engine]
    CDM -->|TUBA cost tables| PAC[Public Accounts Calculator]
    PLUDM -->|NTEM adjustment factors| TEF[Trip End Forecasting Module]
    SDI -->|zone attributes| DIA[Distributional Impact Assessor]

The {{entity:Geospatial Analysis Platform}} was decomposed into 5 components: {{entity:GIS Data Repository}} {{hex:40853158}}, {{entity:Receptor Mapping Engine}} {{hex:40A53159}}, {{entity:Route and Catchment Analyser}} {{hex:40E43309}}, {{entity:Spatial Overlay Processor}} {{hex:40E53109}}, and {{entity:Map Rendering and Visualisation Module}} {{hex:40E5F158}}. The GIS Data Repository serves as the single spatial data store via OGC WFS/WMS interfaces, preventing geometry version drift across environmental topics.

flowchart TB
    GIS[GIS Data Repository]
    RME[Receptor Mapping Engine]
    RCA[Route and Catchment Analyser]
    SOP[Spatial Overlay Processor]
    MRV[Map Rendering and Visualisation]
    GIS -->|designation layers| RME
    GIS -->|network, land use| RCA
    GIS -->|corridor geometry| SOP
    SOP -->|constraint maps| MRV
    RME -->|receptor points| AQNM[Air Quality and Noise Modelling Engine]
    SOP -->|constraint matrices| EIA[Environmental Impact Assessment Module]
    RCA -->|accessibility data| DIA[Distributional Impact Assessor]

Analysis

Cross-domain search on {{entity:Receptor Mapping Engine}} returned {{entity:HD Map Manager}} from the autonomous vehicle domain at 0.94 Jaccard — both are spatial data components that must serve precise geo-referenced feature sets to downstream analysis engines with strict positional accuracy guarantees. The analogy reinforces the importance of the 1m positional accuracy requirement in {{sub:SUB-REQS-041}}: the AV domain demands centimetre-level accuracy, and while transport appraisal doesn’t need that precision, the principle that spatial analysis quality is bounded by repository accuracy holds.

Lint returned 1 high finding (transport appraisal system classified without Physical Object trait despite physical-sounding constraints in {{stk:STK-NEEDS-002}}, {{stk:STK-NEEDS-008}}, {{sys:SYS-REQS-011}} — these are geospatial data constraints, not hardware, so the classification is correct) and 1 low finding (ARC and VER entries lack “shall” — by design). 12 orphans, all ARC decisions or prior-session SUB requirements that predate the current trace structure.

Requirements

This session produced 8 subsystem requirements ({{sub:SUB-REQS-021}} through {{sub:SUB-REQS-028}} for Data Acquisition, {{sub:SUB-REQS-038}} through {{sub:SUB-REQS-041}} for Geospatial), 7 interface requirements ({{ifc:IFC-DEFS-013}} through {{ifc:IFC-DEFS-017}} for Data Acquisition cross-subsystem interfaces, {{ifc:IFC-DEFS-022}} and {{ifc:IFC-DEFS-023}} for Geospatial), 7 verification entries with full trace coverage, and 2 architecture decisions. All SUB and IFC requirements traced to parent SYS requirements. All IFC requirements have corresponding VER entries. Project totals: 117 requirements, 23 IFC with 23 VER (100% IFC verification coverage).

Key requirements: {{sub:SUB-REQS-026}} enforces version-controlled parameter registries with SHA-256 content hashing — critical for TAG audit compliance. {{sub:SUB-REQS-024}} codifies HMT optimism bias factors (66% for tunnels) which materially affect VfM for the tunnel crossing options. {{ifc:IFC-DEFS-015}} separates optimism bias as line items in cost transfers to enable switching value analysis.

Next

One subsystem remains: {{entity:Appraisal Reporting Subsystem}}. This is the output layer — TAG worksheet generation, business case document assembly, sensitivity reporting, and executive summaries. It interfaces with Economic Appraisal Engine outputs and Environmental Assessment outputs. Next session should decompose it and assess whether the system is ready for first-pass-complete status. The 3 orphaned SUB requirements (SUB-REQS-029 through 031) from prior sessions need trace links or disposition during QC.