| 1 | as-is-archaeology | Current structure, historical residue, inconsistencies, and undocumented implementation reality | What actually exists, and where does it conflict with the documented or intended design? |
| 2 | business-journey | End-to-end user, customer, and operational journeys across the captured scope | Which steps, systems, hand-offs, and outcomes make up a business journey? |
| 3 | business-rules | Decision logic, calculations, validation, eligibility, routing, and policy constraints | Which rules control behaviour, and where are they implemented or contradicted? |
| 4 | call-chain | Execution paths between functions, jobs, services, modules, and external calls | If this entry point runs or changes, which code paths and downstream calls follow? |
| 5 | capability-map | Business and technical capabilities and the components that realise them | Which system parts provide a capability, and where is capability ownership fragmented? |
| 6 | compliance-footprint | Regulatory obligations, controls, audit evidence, and regulated-data handling | Which captured behaviours or data touch a compliance obligation or control? |
| 7 | contract-surface | APIs, events, files, schemas, commands, and other declared integration contracts | Which consumers depend on a contract, and what could break if it changes? |
| 8 | data-lineage | Data origin, movement, transformation, persistence, and downstream use | Where does this data come from, how is it transformed, and where does it go? |
| 9 | data-relation | Entities, records, keys, schemas, joins, and semantic relationships | Which data structures relate, and what integrity assumptions connect them? |
| 10 | dead-code | Implementation that appears unused, unreachable, superseded, or orphaned | What may be removable, and what evidence is still missing before deletion is safe? |
| 11 | dependency-blast-radius | Upstream and downstream dependencies that may transmit a change | What code, contracts, data, jobs, controls, or consumers could a proposed change affect? |
| 12 | domain-model | Domain concepts, vocabulary, entities, responsibilities, and bounded contexts | What concepts organise the system, and where are boundaries or meanings inconsistent? |
| 13 | infra-inventory | Runtime, compute, network, storage, middleware, platform, and deployment components | What infrastructure must exist for the captured system to run? |
| 14 | integration-topology | Connected systems, routes, protocols, directionality, and integration hubs | How do systems connect, and which routes or hubs create coupling? |
| 15 | interface-mappings | Field, message, protocol, code, and semantic mappings between interfaces | How is information translated across a boundary, and where can mappings drift? |
| 16 | legacy-estate-map | Legacy technologies, programs, data stores, operational constraints, and ownership | Which legacy components remain, what depends on them, and what constrains change? |
| 17 | migration-seams | Candidate boundaries for strangling, extraction, replacement, coexistence, or phased migration | Where can change be isolated with the least coupling and clearest evidence? |
| 18 | ops-inventory | Batch jobs, schedules, runbooks, controls, operational utilities, and support procedures | What keeps the system operating, and which activities are manual or time-bound? |
| 19 | reliability-map | Failure modes, retries, timeouts, recovery, observability, resilience, and operational risk | How can the system fail, how is failure detected, and how does it recover? |
| 20 | security-posture | Authentication, authorisation, secrets, trust boundaries, exposure, and security controls | Where are the captured attack surfaces, privileges, trust boundaries, and control gaps? |
| 21 | ui-flow | Screens, states, navigation, user actions, validation, and interface journeys | How does a user move through the interface, and which backend behaviours support each step? |