DVE — Premortem Framework

GVE Premortem Framework How to Build Failure Prediction Directly Into Guided Vibe Engineering

A premortem in GVE should not be treated as a side conversation or optional “risk discussion.” It should become a formal operating layer inside the Guided Vibe Engineering architecture.

The purpose is simple:

Before the AI writes code, changes code, debugs code, or deploys code, it should briefly imagine how that decision could fail.

This turns the AI from a reactive code generator into a proactive failure detector.

In normal vibe coding, the AI often thinks like this:

“What should I build next?”

In GVE with premortems, the AI thinks like this:

“If I build this next, how could it fail, and what should we clarify, test, or document before moving forward?”

That one shift makes the entire GVE system stronger.

1. Where the Premortem Fits Inside GVE

The premortem should become a required layer across the full GVE lifecycle.

The current GVE flow is:

Intent Capture Requirements Architecture Implementation Testing Debugging Deployment Iteration and Maintenance

The premortem layer should be inserted like this:

Intent Capture → Run a Project Failure Premortem Requirements → Run a Requirement Gap Premortem Architecture → Run an Architecture Failure Premortem Implementation → Run a Module-Level Premortem Testing → Run a Test Coverage Premortem Debugging → Run a Fix Failure Premortem Deployment → Run a Launch Failure Premortem Iteration → Run an Iteration Drift Premortem

So instead of one big premortem at the beginning, GVE should use small, phase-specific premortems throughout the entire build.

This keeps the system conversational and lightweight while still giving it real engineering discipline.

2. The Main GVE Premortem Rule

The core rule should be:

Before every major project decision, the AI must ask: “If this fails later, what will probably be the reason?”

That question becomes a checkpoint.

Not a long meeting. Not a 20-page risk report. Just a structured pause.

The AI should then convert the answer into:

Risks Assumptions Preventive actions Tests Architecture notes Debugging warnings Deployment considerations

This gives the project memory before the problem happens.

3. The Premortem Artifact

GVE should add a new required living document:

Premortem Register

This becomes part of the project artifact system.

Existing GVE artifacts include:

Project Intent Brief Living Requirements Document Architecture Map State Flow Diagram Dependency Graph Failure Mode Analysis Module Contract Registry Test Specification Debug History Log Iteration Change Log Observability Plan Deployment and Rollback Plan

Add this:

13. Premortem Register

The Premortem Register tracks predicted failures before they happen.

Each entry should include:

Field Purpose Premortem ID Unique identifier Phase Planning, architecture, implementation, testing, deployment, etc. Decision or feature What is being evaluated Imagined failure What went wrong in the future Likely cause Why it failed Warning signs How we would know this risk is becoming real Prevention step What we should do now Required test What test proves we reduced the risk Architecture impact Whether the architecture map must change Owner/module Which part of the system is responsible Status Open, mitigated, accepted, deferred Linked debug record If this risk later becomes a real bug

This becomes extremely powerful because predicted risks can later be compared against real bugs.

That lets GVE learn:

“Did we predict this failure? Did we ignore it? Did our prevention step work?”

4. The Core GVE Premortem Loop

Every premortem should follow the same simple loop:

Step 1: Imagine Failure

The AI asks:

“Imagine this part of the project failed later. What probably caused it?”

Step 2: Identify Causes

The AI lists likely causes:

Missing requirement Wrong assumption Bad architecture choice Unclear user flow State management issue Security gap Bad dependency Weak test coverage Deployment mismatch Poor error handling Step 3: Rank the Risks

Each risk gets a simple score:

Likelihood: Low / Medium / High Impact: Low / Medium / High Detectability: Easy / Medium / Hard

The most dangerous risks are:

High impact + hard to detect

Those should get immediate attention.

Step 4: Create Prevention Actions

For each major risk, the AI creates an action:

Ask a clarification question Add a test Update the architecture map Create a fallback behavior Add logging Add validation Add a rollback plan Split a module Create a module contract Define an edge case Step 5: Update GVE Artifacts

The premortem should update the relevant project documents:

Requirements document Architecture map Test spec Failure mode analysis Observability plan Deployment plan Change log Step 6: Continue Building

Only after the risks are acknowledged does the AI continue.

The goal is not to eliminate every risk.

The goal is to make risk visible before it becomes expensive.

5. The Eight GVE Premortem Types

GVE should use different premortems at different phases.

1. Project Failure Premortem When it happens

Immediately after intent capture, before requirements are locked.

Purpose

Identify why the entire project could fail.

AI prompt

“Imagine this project is finished, but it failed. Users did not adopt it, the client is unhappy, or the system does not solve the problem. What are the most likely reasons?”

Common failure reasons We built the wrong thing The user problem was misunderstood The scope was too large The MVP was not defined The success metric was vague The real user was not identified The workflow did not match how people actually work The project depended on unavailable data The AI assumed requirements that were never confirmed Outputs Top 5 project-level risks Prevention actions Clarifying questions Updated intent brief Updated success criteria Example

User says:

“Build a client dashboard.”

Premortem says:

“This dashboard could fail because we do not know who uses it, what decision it supports, how fresh the data needs to be, or what counts as success.”

Prevention:

Define user roles Define data sources Define refresh rate Define success metric Define MVP dashboard views 2. Requirement Gap Premortem When it happens

After initial requirements are written, before architecture.

Purpose

Find missing requirements before the AI designs around assumptions.

AI prompt

“Imagine we built exactly these requirements and the user still says it is wrong. What did we fail to ask?”

Common failure reasons Missing user role Missing permission rule Missing error behavior Missing edge case Missing data validation Missing workflow step Missing notification rule Missing reporting/export requirement Missing admin function Outputs Requirement gaps New clarification questions Updated requirements document Edge case list Example

Requirement:

“Users can upload files.”

Premortem asks:

What file types? Max file size? Virus scanning? Who can see uploaded files? Can files be deleted? Are uploads private? What happens if upload fails?

This prevents a vague feature from becoming a security problem.

3. Architecture Failure Premortem When it happens

After architecture draft, before coding.

Purpose

Find design choices that could create future rewrites.

AI prompt

“Imagine this architecture fails after three months of real usage. What part of the design probably broke first?”

Common failure reasons Bad state management No single source of truth Database schema does not support future needs APIs are too tightly coupled Real-time requirements were underestimated Authentication model is weak Authorization rules are unclear External dependency becomes a bottleneck System cannot scale No rollback path No observability Outputs Architecture risk list Updated architecture map Updated state flow diagram Updated dependency graph Required architecture changes Critical GVE question

“Where does truth live?”

If the AI cannot answer that, coding should not begin.

Example

Feature:

“Real-time collaboration.”

Premortem risks:

Two users edit the same record at the same time Offline edits overwrite newer data Frontend state conflicts with backend state WebSocket disconnects are not handled No conflict resolution strategy exists

Prevention:

Define source of truth Define conflict behavior Choose polling, WebSockets, CRDT, operational transform, or simpler MVP behavior Add reconnect logic Add tests for simultaneous edits 4. Module-Level Premortem When it happens

Before coding each major module.

Purpose

Prevent the AI from creating fragile modules with hidden assumptions.

AI prompt

“Imagine this module causes bugs later. What will most likely be wrong with it?”

Common failure reasons Module does too much Inputs are unclear Outputs are inconsistent Error states are undefined Dependencies are hidden Interface contract is unstable Business logic is mixed with UI logic Security checks are missing State mutation happens in the wrong place Outputs Module risk list Module contract Input/output expectations Required tests Architecture map update Example

Module:

“Authentication module.”

Premortem risks:

Password reset not handled Session expiration unclear User roles missing Tokens stored insecurely Failed login rate limiting missing Logout does not clear session state

Prevention:

Define auth contract Add role model Add token storage decision Add session expiration tests Add failed login handling 5. Test Coverage Premortem When it happens

Before finalizing a feature or merging a module.

Purpose

Find what the current tests are failing to prove.

AI prompt

“Imagine all tests pass, but this feature still breaks in production. What did our tests miss?”

Common failure reasons Only happy path tested Edge cases missing Integration not tested Permissions not tested Empty states not tested Invalid input not tested Network failure not tested Race condition not tested Migration not tested Performance not tested Outputs Missing test list Updated test specification Regression test plan Risk acceptance notes Example

Feature:

“User can submit a form.”

Existing test:

Valid form submits successfully

Premortem asks:

What if required fields are missing? What if the server times out? What if the user double-clicks submit? What if the user lacks permission? What if the payload is too large? What if the database write succeeds but notification fails?

This turns one weak test into a real safety net.

6. Debug Fix Premortem When it happens

Before applying a bug fix.

Purpose

Prevent the AI from fixing the symptom and creating new bugs.

AI prompt

“Imagine this fix appears to work but causes a new problem. What is the most likely side effect?”

Common failure reasons Fix treats symptom, not root cause Fix breaks another module Fix changes contract unexpectedly Fix hides error instead of solving it Fix creates data inconsistency Fix bypasses security checks Fix removes needed validation Fix creates regression Outputs Side effect list Root cause confirmation Affected dependency list Regression tests Debug history update Architecture map update if needed Example

Bug:

“Dashboard total is wrong.”

Bad AI fix:

Adjust the frontend calculation.

Premortem asks:

Is the backend sending wrong data? Is the frontend double-counting? Are filters applied inconsistently? Is cached data stale? Are timezone boundaries wrong? Will changing this break exports?

This prevents shallow debugging.

7. Launch Failure Premortem When it happens

Before deployment.

Purpose

Prevent “works locally, fails live.”

AI prompt

“Imagine launch failed or had to be rolled back. What probably caused it?”

Common failure reasons Environment variables missing Database migration fails Secrets misconfigured Build process different from local Third-party API unavailable Logging not configured No rollback plan Users hit a permission error DNS/config issue Performance problem under real load Outputs Deployment risk list Rollback plan Monitoring checklist Launch checklist Required smoke tests Post-launch observation plan Example

Before launch, AI says:

“The biggest deployment risk is database migration. We need a backup, migration test, rollback path, and verification query before shipping.”

That is exactly the kind of thinking that keeps GVE from being toy-code.

8. Iteration Drift Premortem When it happens

Before adding a new feature or changing direction.

Purpose

Prevent the project from slowly drifting away from its original purpose.

AI prompt

“Imagine this iteration made the system worse even though the feature worked. Why?”

Common failure reasons Feature does not support original goal Adds complexity without value Breaks existing workflow Changes module contracts Creates inconsistent UX Adds technical debt Duplicates existing logic Conflicts with architecture map Increases maintenance burden Outputs Drift risk list Updated intent alignment check Change log entry Architecture impact review Accept/reject/defer recommendation Example

New request:

“Add AI chat to the dashboard.”

Premortem asks:

Does this support the dashboard’s core purpose? What data can the chat access? How are permissions enforced? What logs are needed? What happens if the AI gives wrong output? Is this MVP or scope creep?

This protects the product from shiny-object development.

6. How the Premortem Connects to Existing GVE Artifacts

The premortem should not live alone. It should feed the rest of the system.

Premortem → Requirements Document

If a risk reveals a missing requirement, update requirements.

Example:

Risk: Users may upload unsupported files. Requirement added: System must only accept PDF, CSV, and PNG files under 10 MB.

Premortem → Architecture Map

If a risk reveals a design weakness, update architecture.

Example:

Risk: Multiple frontend components update user state independently. Architecture update: User state must be owned by central session store.

Premortem → State Flow Diagram

If the risk is about data movement, update state flow.

Example:

Risk: Dashboard may show stale metrics. State flow update: Add cache invalidation rule and refresh interval.

Premortem → Dependency Graph

If the risk involves module coupling, update dependency graph.

Example:

Risk: Billing module directly depends on notification module. Dependency update: Add event bus or queue boundary.

Premortem → Test Specification

If the risk can be tested, create a test.

Example:

Risk: User double-submits payment form. Test added: Duplicate submission should not create duplicate charge.

Premortem → Observability Plan

If the risk needs monitoring, add logging or metrics.

Example:

Risk: API timeout causes silent failure. Observability update: Log timeout events and alert if rate exceeds threshold.

Premortem → Deployment Plan

If the risk affects launch, update deployment plan.

Example:

Risk: Migration could corrupt production data. Deployment update: Backup before migration and run validation query after migration.

Premortem → Debug History

If a predicted risk becomes a real bug, link it.

Example:

Premortem predicted stale cache errors. Bug occurred in dashboard metrics. Debug record links back to original premortem risk.

This creates a feedback loop that makes the AI smarter over time.

7. The Premortem Scoring System

GVE should include a lightweight scoring system.

Each risk gets three scores:

Likelihood

How likely is this to happen?

1 = Unlikely 2 = Possible 3 = Likely Impact

How bad would it be?

1 = Minor inconvenience 2 = Meaningful problem 3 = Serious failure Detectability

How easy would it be to notice?

1 = Easy to detect 2 = Somewhat detectable 3 = Hard to detect Risk Priority Score

Use:

Risk Score = Likelihood × Impact × Detectability

Maximum score is 27.

Risk levels 1–6: Low risk 7–14: Medium risk 15–27: High risk

High-risk items should not be ignored.

They must be:

Mitigated Tested Accepted explicitly Or deferred with explanation 8. Premortem Status Types

Each premortem risk should have a status.

Open

Risk identified but not handled yet.

Mitigated

Risk has a prevention step, test, or architecture change.

Accepted

Team knowingly accepts the risk.

Deferred

Risk is real but will be handled later.

Converted to Requirement

Risk became a formal requirement.

Converted to Test

Risk became a test case.

Converted to Architecture Change

Risk forced a design change.

Became Bug

Risk actually happened and is linked to debug history.

This lets the team track whether GVE is actually preventing problems.

9. Premortem Prompt Templates for GVE

These can be built directly into the orchestration layer.

Project Premortem Prompt

“Before we move forward, let’s run a quick GVE premortem. Imagine this project failed after launch. Users did not adopt it, the system was hard to maintain, or it solved the wrong problem. List the five most likely reasons this could happen, then identify what we should clarify or change now to prevent those failures.”

Requirements Premortem Prompt

“Imagine we built exactly these requirements, but the user still says the product is wrong. What did we fail to ask? Identify missing roles, workflows, edge cases, failure states, data assumptions, and success criteria.”

Architecture Premortem Prompt

“Imagine this architecture fails after real users start using it. What breaks first? Analyze state management, data flow, dependencies, scaling, security, observability, and rollback risks. Recommend changes before coding begins.”

Module Premortem Prompt

“Before coding this module, imagine it becomes the source of future bugs. What are the likely causes? Define the module’s responsibilities, inputs, outputs, dependencies, error states, and tests needed to prevent those bugs.”

Testing Premortem Prompt

“Imagine all current tests pass, but the feature still fails in production. What scenarios did the tests miss? Add edge cases, integration cases, permission cases, invalid input cases, and failure scenarios.”

Debug Premortem Prompt

“Before applying this fix, imagine the fix causes a regression or hides the real problem. What side effects are likely? Identify affected modules, contracts, tests, and architecture updates needed before we patch.”

Deployment Premortem Prompt

“Imagine deployment failed or had to be rolled back. What caused it? Review environment variables, secrets, migrations, build process, permissions, monitoring, rollback strategy, and post-launch verification.”

Iteration Premortem Prompt

“Before adding this feature, imagine the feature technically works but makes the product worse. How could it increase complexity, drift from the original goal, break contracts, confuse users, or create maintenance burden?”

10. How to Implement This in the GVE Orchestration Layer

The orchestration layer should treat premortems as automated phase checkpoints.

A. Add a Premortem Engine

The Premortem Engine is a component that runs at key points.

It should:

Detect the current phase Generate phase-specific premortem questions Capture risks Score risks Convert risks into actions Update project artifacts Track risk status Link risks to bugs and changes later B. Add Premortem Triggers

Premortems should run automatically when:

A new project starts Requirements are finalized Architecture is proposed A new module is about to be coded A test plan is generated A bug fix is proposed Deployment is prepared A new iteration begins A module contract changes A dependency is added A database schema changes Authentication or permissions change External APIs are introduced C. Add a Risk Registry File

In the repo, create:

/gve/premortem_register.md

or structured format:

/gve/premortem_register.json

The JSON version is better for automation.

Example structure:

{ “premortem_id”: “PM-0042”, “phase”: “architecture”, “feature”: “real-time dashboard updates”, “imagined_failure”: “Dashboard shows conflicting data between users”, “likely_cause”: “No single source of truth for live metrics”, “likelihood”: 3, “impact”: 3, “detectability”: 2, “risk_score”: 18, “warning_signs”: [ “Different users see different totals”, “Frontend state updates without backend confirmation”, “Cache invalidation is unclear” ], “prevention_actions”: [ “Define backend metrics service as source of truth”, “Add cache invalidation rules”, “Add integration test for refresh behavior” ], “linked_artifacts”: [ “architecture_map.md”, “state_flow_diagram.md”, “test_specification.md” ], “status”: “mitigated” } D. Add Premortem-Based Build Blocking

Not every risk should block progress.

But some should.

A high-risk unresolved item should trigger a warning:

“This feature has an unresolved high-risk premortem item. Proceeding may create rework. Do you want to mitigate, accept, or defer this risk?”

The user can still move forward, but the decision is logged.

That protects speed while preserving accountability.

E. Add Premortem-to-Test Conversion

The AI should automatically convert risks into tests.

Example:

Premortem risk:

“User may double-submit checkout form and create duplicate orders.”

Converted test:

“Submitting the checkout form twice rapidly should create only one order.”

This is one of the most valuable parts of the system because it turns fear into verification.

F. Add Premortem-to-Observability Conversion

Some risks cannot be fully prevented, so they should be monitored.

Example:

Premortem risk:

“Third-party API may time out.”

Observability action:

Log timeout rate Track average response time Alert if failures exceed threshold Show user retry message

This makes the system production-aware from the beginning.

11. The Premortem Dashboard

Eventually, GVE should have a dashboard that shows project risk health.

Dashboard sections:

Risk Summary Total risks Open risks Mitigated risks Accepted risks High-risk unresolved items Risk by Phase Planning risks Requirement risks Architecture risks Module risks Testing risks Deployment risks Iteration risks Risk Conversion Risks converted to requirements Risks converted to tests Risks converted to architecture changes Risks converted to monitoring Risks that became bugs Predicted vs Actual Failures

This is especially valuable.

Track:

Which bugs were predicted Which bugs were not predicted Which mitigations worked Which risks were ignored Which accepted risks became real problems

This turns GVE into a learning system.

12. How Premortems Improve Debugging

This is one of the strongest connections to your existing idea.

Without premortems, debugging starts after failure.

With premortems, debugging starts with context.

When a bug appears, the AI should check:

Was this failure predicted? Is there a premortem entry for it? Was there a prevention step? Was the prevention step skipped? Was a test missing? Did the architecture map warn us? Did we accept this risk knowingly? What should be updated now?

This makes debugging much more intelligent.

Example:

Bug:

“Users sometimes see stale dashboard totals.”

AI checks premortem register:

“This was predicted in PM-0042. The prevention action was to define cache invalidation rules, but that task was deferred.”

Now the AI is not guessing.

It has historical project memory.

13. The Premortem as a Teaching Tool

Another important part of GVE is that the AI should teach the human why its questions matter.

Bad AI:

“Define cache invalidation.”

Good GVE AI:

“If we do not define cache invalidation, users may see old data and lose trust in the dashboard. For this MVP, should the dashboard refresh every 30 seconds, refresh manually, or update instantly?”

That is the GVE style.

It teaches through conversation.

The premortem is not just risk management. It is how the AI helps the human think like an engineer.

14. Lightweight Version for Fast Projects

For small projects, do not run a huge premortem.

Use a 3-question premortem:

What are the three most likely ways this could fail? Which one would be most expensive to fix later? What should we clarify, test, or change now?

That is enough for lightweight vibe coding.

15. Full Version for Serious Projects

For production or client projects, use the full framework:

Project Premortem Requirement Gap Premortem Architecture Failure Premortem Module-Level Premortem Test Coverage Premortem Debug Fix Premortem Launch Failure Premortem Iteration Drift Premortem Premortem Register Risk scoring Artifact updates Risk-to-test conversion Predicted-vs-actual tracking

This is what makes GVE credible for real software teams.

16. How This Changes the Definition of Done

In GVE, a feature is not done just because the code works.

A feature is done when:

The requirement is clear The architecture map is updated The module contract is defined The premortem risks are handled The tests cover likely failures Observability exists where needed Debug risks are logged Deployment impact is known The change log is updated

New definition:

Done means the feature works, is understood, is tested, is traceable, and has known risks documented.

17. Final Integrated GVE Architecture With Premortem Layer

The updated GVE architecture becomes:

Conversation Layer Natural user/AI interaction Intent Layer Captures goals, users, success metrics Premortem Layer Predicts likely failures before each phase Requirements Layer Converts intent and risks into requirements Architecture Layer Maps system design, state, dependencies, contracts Implementation Layer Builds modular code Testing Layer Converts risks and requirements into tests Debugging Layer Uses premortem history and architecture maps to fix root causes Deployment Layer Ships with rollback, monitoring, and verification Memory Layer Stores architecture maps, change logs, debug history, premortem register, and decisions

This is the key:

The premortem layer feeds every other layer.

It improves requirements. It strengthens architecture. It creates better tests. It improves debugging. It makes deployment safer. It gives the project memory.

18. Simple Summary

A premortem inside GVE is not just asking, “What could go wrong?”

It is a system for turning possible failure into:

Better questions Better requirements Better architecture Better tests Better debugging Better deployment Better iteration

The final GVE rule should be:

Every major AI coding action should be preceded by a small imagined-failure check.

That is how GVE keeps the speed of vibe coding without letting the project become fragile.

Final one-line version:

GVE uses premortems to make the AI predict failure before it writes code, so the team can prevent expensive mistakes before they exist.