Enterprise systems that handle material data fail in a predictable pattern: not from a single catastrophic bug, but from the slow accumulation of small undetected issues that compound until the system can no longer be trusted to produce accurate outputs. Each issue is individually trivial. The aggregate is fatal.
The pattern is not "use AI to write code faster." The pattern is: register the threat vectors at specification time, then build with discipline that matches the threat profile. The pre-engineering issue register is the artifact that makes the discipline operational.
Threat vectors organize into eleven categories. Each enterprise system will have its own distribution; the categories themselves are stable.
Each registered issue gets a severity classification. The taxonomy is three-tier:
| Severity | Definition | Sprint behavior |
|---|---|---|
| BLOCKER | If this issue is not resolved before sprint one starts, the system cannot be safely operated regardless of feature completeness. | Resolved first. No feature work begins until all blockers clear. |
| CRITICAL | If this issue is not resolved before launch, the system will degrade in production in a way that erodes trust. | Sprint priority above features. Tracked to launch gate. |
| STANDARD | Known issue with a defined remediation path. Acceptable to ship and remediate post-launch with explicit tracking. | Backlog ordered by dependency. Visible in roadmap. |
Sprint ordering is determined by dependency graph, not by feature priority. The register identifies which issues block which features, and the resolution sequence honors the graph.
- All blockers, in dependency order. If blocker A enables blocker B, A is resolved first.
- Foundational schema / auth / permissions critical issues. These are the backbone that subsequent work assumes.
- Business logic critical issues. Once the foundation is sound, the value-creating logic can be built against it.
- Feature work, in priority order. Standard-severity issues are interleaved with feature work, with explicit tracking.
- Performance / observability hardening. Late-sprint, once feature surface is stable.
The methodology applies to any enterprise system that handles material data — financial systems, sales platforms, clinical systems, compliance tooling, decision-support engines. The categories may need adaptation (e.g., a healthcare system adds Privacy as its own category), but the structure is portable.
The threat-vector count is not fixed. A small system might have 30. A large system might have 250. The right count is whatever produces a register that the engineering team trusts as a complete enumeration of what could go wrong.
- Before the first sprint: enumerate threat vectors by category.
- Classify each by severity (Blocker / Critical / Standard).
- Build dependency graph linking issues to features.
- Clear all blockers first, before feature work begins.
- Order remaining work by dependency, not by feature priority alone.
- Track resolution against the register; the register is the source of truth, not the project board.
- Add newly discovered issues to the register with the same discipline; never let unstructured "small fixes" accumulate.
The cost is the up-front work. The return is the absence of the v5 failure pattern.