AI Dependency Register Prompts: Keep Projects From Surprising You

A project dependency is anything that has to be true before something else can move. A vendor has to deliver access. Engineering has to expose an endpoint. Legal has to approve language. Support needs a migration script. Someone has to remember that the “temporary” spreadsheet is now a load-bearing part of the business.

Most projects do not fail because nobody made a plan. They fail because the plan described the happy path and quietly omitted the web of things around it.

An AI dependency register can help. It can turn scattered notes into rows, group related risks, ask annoying questions, and make a draft reviewable. It cannot see your undocumented architecture, verify an owner, inspect production, or accept blame when the launch catches fire. That remains a human job. Tragically, humans still have to attend the meeting.

This guide gives you ten AI dependency register prompts, an input format, a review workflow, and guardrails for using them without producing a beautiful spreadsheet of fiction.

What an AI dependency register is actually for

A dependency register is a living list of relationships that can affect delivery. A useful row usually includes:

• the item that depends on something else;
• the upstream dependency;
• the owner for each side;
• the expected date or condition;
• the evidence or source;
• the current status;
• the consequence if it slips;
• confidence in the information;
• the next review or escalation action.

AI is good at extracting these fields from messy material. Give it meeting notes, a project brief, a release plan, or a set of approved tickets and it can propose a first pass. It is also good at comparing two lists and spotting that “customer import,” “data migration,” and “historical records” might be the same conversation wearing different hats.

It is bad at knowing whether the person named in a six-month-old document still owns the system. It cannot infer that a vendor’s “two business days” excludes weekends, procurement, security review, and the one person who is on holiday. Treat the output as a hypothesis, not a control plane.

For a broader blast-radius review, pair this process with AI change impact analysis prompts. If the project is still vague, start with AI project kickoff prompts before asking a model to map it.

The input table: give the model something real

The quality of the register depends less on clever wording than on the evidence you provide. Before prompting, collect a small, sanitized input table.

Do not paste raw customer records, credentials, access tokens, private tickets, confidential strategy, legal disputes, HR records, regulated data, or production logs into an unapproved tool. Replace names and identifiers with role labels. Keep source links or document IDs in your own system so a human can verify each row later.

A reusable prompt formula

Use this structure when you need a new prompt:

You are helping prepare a dependency register for [project]. Use only the supplied evidence. Extract [specific relationship]. Return [exact columns]. For every inference, label it as a hypothesis and explain what a human must verify. Do not invent owners, dates, systems, or approvals. Separate confirmed facts from assumptions and open questions.

That final instruction matters. Without it, a model will happily turn “someone from security should review this” into “Security owner: Alex, approval due Friday.” Polished nonsense is still nonsense.

10 AI dependency register prompts you can copy

Prompt 1: Extract dependencies from a project brief

Read the project brief below. Extract every explicit dependency and every dependency that is strongly implied by the stated outcome. Return a table with: dependent work item, upstream dependency, owner if explicitly named, required condition, date if explicitly stated, source quote, confidence, and verification question. Do not invent missing details. Put implied items in a separate section labeled “hypotheses.”

Project brief: [paste sanitized brief]

This creates the first pass. The source quote is important because it lets a reviewer challenge the row instead of arguing with an AI summary.

Prompt 2: Map upstream and downstream effects

Build a two-direction dependency map for [change or deliverable]. List what must happen before it can proceed and what may be affected after it ships. For each item, include the likely owner, evidence, failure mode, and a question that would confirm or reject the relationship. Use three labels: confirmed, plausible, and unverified. Only call an item confirmed when the input explicitly supports it.

Inputs: [sanitized plans, tickets, decisions, and system notes]

This is useful when a team has mapped prerequisites but forgotten consequences. “We can deploy” is not the same as “customers can use it safely.”

Prompt 3: Find missing owners and handoffs

Review this dependency list for missing ownership and handoff ambiguity. Return: dependency, current owner text, ambiguity, suggested role to verify, handoff question, and escalation threshold. Do not assign a person unless the source names one. Flag rows where one team is expected to provide an input but no acceptance criteria or receiving owner exists.

Dependency list: [paste sanitized register]

Ownership is not a decorative column. “Team” is often a polite way of saying nobody has agreed to do it.

Prompt 4: Check dates, sequencing, and critical assumptions

Examine the dates and sequence below. Identify dependencies that appear impossible, circular, under-specified, or reliant on an unstated assumption. Show the claimed sequence, the concern, the evidence needed, and a question for the project owner. Do not declare a schedule impossible without explaining what fact would change that conclusion.

Schedule and assumptions: [paste sanitized plan]

This catches the classic project trick: a task is marked complete because it started, while three downstream tasks assume it is finished.

Prompt 5: Map vendor and external dependencies

Extract all dependencies on vendors, contractors, platforms, regulators, customers, or external teams. Return: external party, promised input, contract or source evidence, lead time, internal prerequisite, failure scenario, fallback, and owner who must confirm it. Flag anything based only on an email, verbal promise, or generic documentation.

External dependency notes: [paste sanitized notes]

External dependencies deserve their own view because “we are waiting on them” is not a mitigation plan. Add a fallback or explicitly accept the exposure.

Prompt 6: Trace data and system dependencies

Using only the sanitized system notes below, draft a data and system dependency register. Include source system, destination, data or event, interface, owner, sensitivity classification if stated, expected timing, failure impact, and verification task. Separate documented relationships from guesses. Never infer that two systems are connected merely because their names appear near each other.

System notes: [paste sanitized architecture summary]

A human engineer, architect, or security reviewer must validate this output. The model has not inspected your network, permissions, queues, schemas, or logs. It has read words about them.

Prompt 7: Turn dependencies into review questions

Convert this dependency register into a review agenda. Group questions by product, engineering, operations, security, legal/compliance, support, and customer impact. Prioritize questions by consequence and uncertainty. For each question, name the evidence or owner needed to close it. Do not repeat a row as a question unless the question would change a decision.

Register: [paste sanitized register]

This is where AI earns its lunch: not by pretending to approve the plan, but by making the next human conversation less vague.

Prompt 8: Draft an escalation-ready register

Reformat the register for escalation. Include dependency, impact if missed, earliest warning signal, current status, owner, decision needed, deadline for action, and escalation path. Preserve the original evidence and mark every inferred field as “to verify.” Keep the tone factual and remove blame, speculation, and invented certainty.

Register and project context: [paste sanitized materials]

An escalation document should make a decision easier. It should not be a courtroom brief assembled by a frightened spreadsheet.

Prompt 9: Compare two register versions

Compare version A and version B of this dependency register. Report added, removed, changed, and unchanged dependencies. For each change, include the old value, new value, source evidence, likely impact, and a human verification task. Pay special attention to owner changes, date changes, status changes, scope changes, and rows that disappeared without an explanation.

Version A: [paste sanitized register]

Version B: [paste sanitized register]

Version comparison is useful after scope changes, vendor updates, or a decision that seemed small at the time. Deleted rows deserve questions too.

Prompt 10: Create the next review checklist

Based on this dependency register, create a review checklist for [date or milestone]. Include only actions that can be verified. For each action, provide owner role, evidence required, pass condition, failure consequence, and follow-up if incomplete. Separate “must complete before milestone” from “monitor after milestone.” Do not mark anything complete based on the register alone.

Register: [paste sanitized register]

Milestone: [describe milestone]

This turns the register from a museum of concerns into a working control loop. Update it when decisions change reality.

A small example: the export that depended on everything

Imagine a team building a customer export. The project brief says the feature needs an API endpoint, a permission check, a CSV format, a support article, and a launch email.

A shallow map says: “Engineering builds API; Product launches.” A better register surfaces questions:

• Does the permission model cover legacy accounts?
• Is the export rate-limited, and who owns the limit?
• Does the CSV contain fields that require privacy review?
• Can support explain partial exports and failed downloads?
• Does the analytics event avoid recording sensitive customer values?
• Does the launch email promise availability before the rollout is complete?

AI can extract those questions from the brief and arrange them by owner. It cannot confirm the answers. The team must inspect the permission rules, approve the data fields, test failure cases, and sign off on customer language. That is the point: expose the work before the calendar exposes you.

A simple review cadence

Use the register at four moments:

1. At kickoff: identify dependencies and unknown owners.
2. Before a major decision: update assumptions, evidence, and blast radius.
3. Before launch or handoff: verify must-have dependencies and explicit sign-offs.
4. After a change: compare the old and new register, then record what reality taught you.

For risk-heavy work, use AI risk assessment prompts to score uncertainty separately from impact. Before release, AI operational readiness prompts can turn open dependencies into a go/no-go checklist. If acceptance is fuzzy, use AI acceptance criteria prompts before anyone claims the work is done.

What AI can and cannot do here

AI can:

• extract candidate relationships from supplied text;
• normalize inconsistent labels;
• compare versions and highlight changes;
• group questions by owner or risk;
• draft a review agenda and checklist;
• make missing evidence easier to notice.

AI cannot:

• verify that a system actually behaves as described;
• know whether an owner has capacity or authority;
• approve security, legal, compliance, financial, or customer-impacting decisions;
• replace architecture, operations, or subject-matter review;
• take accountability for a wrong dependency map.

The useful posture is simple: let the model make the register easier to read and harder to ignore. Keep verification, judgment, and sign-off with people who can access the truth.

Frequently asked questions

Can ChatGPT create a dependency register from meeting notes?

It can draft one from sanitized notes, but every row still needs a source, an owner check, and a confidence label. Meeting notes contain omissions, shorthand, and opinions. Treat the output as a starting hypothesis.

What columns should a dependency register include?

At minimum: dependent item, upstream dependency, owner, condition or date, status, impact, evidence, confidence, and next action. Add sensitivity, fallback, or approval fields when the work warrants them.

How do I stop AI from inventing dependencies?

Tell it to use only supplied evidence, separate confirmed facts from hypotheses, preserve source quotes, and never invent owners or dates. Then sample-check the rows against the source material.

Should dependencies be tracked in a spreadsheet or project tool?

Use the tool where the team already reviews work. A spreadsheet is fine for an initial map; a project or risk system is better when owners, dates, notifications, and audit history matter. The format matters less than keeping it current.

Is a dependency register the same as a risk register?

No. A dependency describes a relationship or prerequisite. A risk describes uncertainty and potential harm. They overlap: a late vendor dependency can create a schedule risk. Track the relationship and the consequence instead of forcing one row to do both jobs.

Can an AI-generated register replace a project manager?

No. It can reduce clerical work and improve questions. It cannot negotiate ownership, resolve conflict, understand political context, or decide what the organization is willing to accept. Those are still human responsibilities.

The takeaway

Use AI to turn scattered project evidence into a dependency register people can inspect. Ask it to show its sources, label its guesses, and generate the questions your plan is avoiding. Then have the actual owners verify the rows and accept the consequences.

A dependency map is not a prediction machine. It is a shared memory with enough structure to catch surprises earlier. That is already useful. You do not need to pretend the robot knows your architecture to get value from a better checklist.

For more practical guidance on using AI without outsourcing your brain, Don't Replace Me is the longer field guide.