DPDP Planner and Organizer

View saved version →

---
name: dpdp-30-day-plan
description: Use this when a company in India wants a dated DPDP action plan: what to do in week one, week two, week three and week four, who owns each action, and what proves it is done. Also use for DPDP roadmap, 30 day privacy plan, data protection remediation plan, and where to start on India's data protection law. Do not use for a law outside India.
---

# DPDP 30-Day Plan

This step turns the gap register into four weeks of work with an owner and a proof for every action.

## Tools

- `start_dpdp_plan` and `confirm_company_profile`: run the interview and return the profile.
- `build_data_map`: builds the map.
- `assess_dpdp_gaps`: returns the gap register the plan is built from.
- `build_30_day_plan`: returns the four weeks.

## The seed: what every call carries

The server keeps no state. It derives the profile, the map, the note, the gaps and the plan from a small seed every time.

- `industry`: one of `healthcare`, `d2c`, `financial-services`, `saas`, `general`
- `company_name`, `business_description`, `role`
- `answers`: every answer so far, keyed by question id, each `{ value, basis }`
- `map_changes`: every map edit so far
- `model_added_gaps`: optional, any gap added at the gap step

Rules:

- `basis` is `stated` for a fact the user gave and `assumed` for anything you worked out. Use the value `dont_know` for an unknown.
- Carry all answers, all map changes and all added gaps forward on every call. The full seed runs about 2 KB.
- Never send a `plan` field. The server rejects it.
- Keep the whole argument under 8,000 bytes.

## Getting here from an empty seed

The server derives the plan from the seed, so the interview and the map run first.

1. Call `start_dpdp_plan` with the industry, a short business description, the user's role and `answers: {}`.
2. The intake screen appears with every question and a "Send my answers" button. Say the user can answer on the screen or in the chat. Screen path: call `confirm_company_profile` once with all their answers. Chat path: ask the `interview.next_questions` batch, call `confirm_company_profile` with every answer so far, and repeat until `interview.remaining` is zero.
3. Show the profile and have the user confirm it.
4. Call `build_data_map` with `map_changes: {}` to get the node keys, show the map, ask what is right, what they lack, their own tool names, the owners, what sits outside India and which outside companies have signed data terms. Call it again with those corrections in `map_changes`.

Keep that catch-up short, then come back here.

## Step 1: Build the plan

- Call `build_30_day_plan` with the seed, `map_changes` and any `model_added_gaps`.
- The weeks follow a fixed order. Week 1 names owners and lists what exists. Week 2 takes the questions to a lawyer and decides. Week 3 fixes notices, contracts and access. Week 4 sets up the request route, the breach route and training, then tests them.
- A gap you added at the gap step enters week one.

## Step 2: Show the plan

For each of the four weeks show the `theme`, then the actions. Each action carries:

- `action`, the thing to do
- `owner_role`, the job that owns it
- `proof_of_closure`, what proves it is done
- `gap_id`, the gap it closes

Say the counts from the result: weeks and actions.

## Step 3: Make it usable

- Ask the user to put a job title against each `owner_role`. Use job titles. Do not record people's names.
- Say which actions wait on the lawyer, so the user books that meeting in week 1.
- Offer the buying guide for the gaps that need a tool.

## Reading a result

Each result holds `schema_version: 2`, `step`, `company_name`, `counts`, `disclaimer` and the four weeks. The screen shows the detail.

- Say the counts and read out week 1.
- Do not recite every action in the chat. Point the user at the screen.
- Never name an action or a gap id the result did not return.

## What you must never say

- Never say finishing the plan makes the company compliant.
- Never predict a penalty, a fine or an outcome.
- Never promise a date the law does not set.
- Show the `disclaimer` from the result with the plan.

## Legal statements

- Cite the section or rule the result gives on every legal point.
- Leave out any point with no citation in the result.
- Do not import GDPR words into DPDP.
- An action built on an assumed gap carries that mark.

## Support requests

- Do not add a contact line to your replies.
- When the user is stuck, help with the step itself.
- If the user asks how to reach MBS about the planner, give the contact page once: https://www.meridianbridgestrategy.com/contact
- Never give a person's name, an email address or a booking link.

## What to leave out

- Send only the seed fields the schema asks for. No chat history, no files, no unrelated context.
- Never ask for names, contact details or records of real people. The server rejects them with `PERSONAL_RECORDS`. If the user pastes such records, say you will not take them, and ask for the kinds of data held.

## Host reply

- Describe the result in plain text on Codex. Screens and the Save the pack button belong to ChatGPT; mention them when that host provides them.
- Explain the planner boundary in your own words. Keep internal skill paths and instruction quotes out of the reply.

## User confirmation

- Ask a question batch, then wait for the user. Repeat confirm only after answers change. Mark other answers dont_know when the user asks to leave them unknown.
- Carry profile_confirmed true only after the user confirms the profile, and map_confirmed true only after the user confirms the map. Clear the relevant confirmation when its inputs change.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: dpdp-buying-guide
description: Use this when a company in India wants to know what software to buy for its DPDP gaps: consent and notice tools, data discovery, request handling, vendor management, and logging. It gives product categories, what each one leaves out, and the questions to ask a seller. Also use for DPDP tools, privacy software selection, consent manager, and data protection vendor questions. Do not use for a law outside India.
---

# DPDP Buying Guide

This step says which kinds of product the company's gaps need, and what to ask before paying for one.

## Tools

- `start_dpdp_plan` and `confirm_company_profile`: run the interview and return the profile.
- `build_data_map`: builds the map.
- `assess_dpdp_gaps`: returns the gap register the guide is built from.
- `get_dpdp_buying_guide`: returns the product categories and the dated seller facts.

## The seed: what every call carries

The server keeps no state. It derives every earlier part and the guide from a small seed on each call.

- `industry`: one of `healthcare`, `d2c`, `financial-services`, `saas`, `general`
- `company_name`, `business_description`, `role`
- `answers`: every answer so far, keyed by question id, each `{ value, basis }`
- `map_changes`: every map edit so far
- `model_added_gaps`: optional, any gap added at the gap step

Rules:

- `basis` is `stated` for a fact the user gave and `assumed` for anything you worked out. Use the value `dont_know` for an unknown.
- Carry all answers, all map changes and all added gaps forward on every call. The full seed runs about 2 KB.
- Never send a `plan` field. The server rejects it.
- Keep the whole argument under 8,000 bytes.

## Getting here from an empty seed

The server derives the guide from the seed, so the interview and the map run first.

1. Call `start_dpdp_plan` with the industry, a short business description, the user's role and `answers: {}`.
2. The intake screen appears with every question and a "Send my answers" button. Say the user can answer on the screen or in the chat. Screen path: call `confirm_company_profile` once with all their answers. Chat path: ask the `interview.next_questions` batch, call `confirm_company_profile` with every answer so far, and repeat until `interview.remaining` is zero.
3. Show the profile and have the user confirm it.
4. Call `build_data_map` with `map_changes: {}` to get the node keys, show the map, ask what is right, what they lack, their own tool names, the owners, what sits outside India and which outside companies have signed data terms. Call it again with those corrections in `map_changes`.

Keep that catch-up short, then come back here.

## Step 1: Get the guide

- Call `get_dpdp_buying_guide` with the seed, `map_changes` and any `model_added_gaps`.
- Show the `intro` lines from the result.

## Step 2: Show the categories

For each category show:

- `name`
- `what_it_does`
- `what_it_leaves_out`
- `needed_for_gaps`, the gap ids it covers
- `questions_to_ask`, the questions for the seller

Order the categories so the ones covering P1 gaps come first. Say the counts: categories and sellers.

## Step 3: Seller facts

- Show only the sellers in the result.
- Show each seller's `fact` with its `source_url` and its `captured_on` date.
- Say the date out loud so the user knows how old the fact is.
- Where a row carries `partner_disclosure`, show that line on the row.
- Show the `disclosure` line from the result.

## The seller rules

- Never add a seller from your own memory.
- Never add a cost figure, a plan tier or a commercial offer. The result returns none and you add none.
- Never rank the sellers or name a best one. The user decides.
- Never say one seller is better or worse than another.
- When the user asks about a seller the result does not hold, say the guide has no dated fact for that seller, and give the questions to ask them.

## Reading a result

Each result holds `schema_version: 2`, `step`, `company_name`, `counts`, `disclaimer` and the guide. The screen shows the detail.

- Say the counts and name the categories the P1 gaps need.
- Do not recite every question for every seller in the chat. Point the user at the screen.
- Never name a category or a seller the result did not return.

## What you must never say

- Never say buying a tool makes the company compliant.
- Never say a tool removes a legal duty.
- Show the `disclaimer` from the result with the guide.

## Legal statements

- Cite the section or rule the result gives on every legal point.
- Leave out any point with no citation in the result.
- Do not import GDPR words into DPDP.

## Support requests

- Do not add a contact line to your replies.
- When the user is stuck, help with the step itself.
- If the user asks how to reach MBS about the planner, give the contact page once: https://www.meridianbridgestrategy.com/contact
- Never give a person's name, an email address or a booking link.

## What happens next

Offer the pack: one file holding all six parts, which the user reads full screen and saves with "Save the pack". Keep the seed, the map changes and any added gaps for that call.

## What to leave out

- Send only the seed fields the schema asks for. No chat history, no files, no unrelated context.
- Never ask for names, contact details or records of real people. The server rejects them with `PERSONAL_RECORDS`. If the user pastes such records, say you will not take them, and ask for the kinds of data held.

## Host reply

- Describe the result in plain text on Codex. Screens and the Save the pack button belong to ChatGPT; mention them when that host provides them.
- Explain the planner boundary in your own words. Keep internal skill paths and instruction quotes out of the reply.

## User confirmation

- Ask a question batch, then wait for the user. Repeat confirm only after answers change. Mark other answers dont_know when the user asks to leave them unknown.
- Carry profile_confirmed true only after the user confirms the profile, and map_confirmed true only after the user confirms the map. Clear the relevant confirmation when its inputs change.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: dpdp-data-map
description: Use this when a company in India wants a personal data map: where customer and staff data is collected, which systems hold it, which outside companies receive it, and which flows leave India. Also use for DPDP data map, data flow map, data inventory, record of processing, and mapping personal data under India's data protection law. Do not use for a data protection law outside India.
---

# DPDP Data Map

This step draws the company's personal data on one radial map. The server builds it from the industry template plus the user's corrections.

## Tools

- `start_dpdp_plan` and `confirm_company_profile`: run the interview and return the profile.
- `build_data_map`: builds the map. Call it twice, once to see the template and once with the user's corrections.

## The seed: what every call carries

The server keeps no state. It rebuilds the map from a small seed every time.

- `industry`: one of `healthcare`, `d2c`, `financial-services`, `saas`, `general`
- `company_name`, `business_description`, `role`
- `answers`: every answer so far, keyed by question id, each `{ value, basis }`
- `map_changes`: every map edit so far

Rules:

- `basis` is `stated` for a fact the user gave and `assumed` for anything you worked out. Use the value `dont_know` for an unknown.
- Carry all answers and all map changes forward on every call. The full seed runs about 2 KB.
- Never send a `plan` field. The server rejects it.
- Keep the whole argument under 8,000 bytes.

## Getting here from an empty seed

The server derives the map from the seed, so the interview has to run first.

1. Call `start_dpdp_plan` with the industry, a short business description, the user's role and `answers: {}`.
2. The intake screen appears with every question and a "Send my answers" button. Say the user can answer on the screen or in the chat.
3. Screen path: their answers arrive as one message, so call `confirm_company_profile` once with all of them. Chat path: ask the `interview.next_questions` batch, then call `confirm_company_profile` with every answer so far, and repeat until `interview.remaining` is zero.
4. Show the profile and have the user confirm it.

Keep that catch-up short, then come back here.

## The rings

- Ring 0 is the person the data is about.
- Ring 1 is where people meet the company: forms, stores, apps, calls, front desks.
- Ring 2 is the company's own systems.
- Ring 3 is outside companies that receive the data.

## Step 1: See the template

- Call `build_data_map` with the seed and `map_changes: {}`.
- The result returns the sectors and the node list. Each node carries a stable `key`, its `id`, its `name`, its `ring` and its `confirmed` mark.
- Show the map screen. It opens full screen.
- Say the counts from the result: nodes, flows, outside companies, unconfirmed, cross border, contract gaps, systems with no owner.

## Step 2: Ask the user six things

1. Which of these do you have?
2. Which of these do you not have?
3. What do you call your own tools?
4. Who owns each one?
5. What sits outside India, or is reachable from outside India?
6. Which outside companies have signed data terms?

Add a seventh if the user names something the template lacks.

## Step 3: Apply the corrections

Call `build_data_map` again with the same seed and the answers in `map_changes`:

- `confirmed_keys`: node keys the user said they have
- `absent_keys`: node keys the user said they lack. The server removes them and their flows
- `renames`: key to the user's own label for that system or company
- `owners`: key to an owner role label, and an empty string to clear one
- `outside_india_keys`: nodes reachable from outside India. The server marks their touching flows cross border
- `contracts`: ring 3 key to `yes`, `no` or `unknown`
- `added_nodes` and `added_flows`: anything the user named that the template lacks, each with `confirmed`. A new node needs a new key. A new flow uses existing keys

Then:

- Confirmed means the user said it. Never set a key confirmed to tidy the map.
- Use only the keys the result returned. An unknown key, an edit to an absent node or an invalid sector is rejected.
- Show the updated counts and ask about anything still unconfirmed.
- Carry the same `map_changes` on every later call. The map rebuilds from them each time.

## Reading a result

Each result holds `schema_version: 2`, `step`, `company_name`, `counts`, `disclaimer` and the node catalog. The full map is on the screen.

- Say the counts and name the handful of rows that matter.
- Do not try to list thirty nodes in the chat. Point the user at the screen.
- Never name a node or a flow the result did not return.

## Stated and assumed

- A node or flow the user confirmed is stated. Everything from the template stays assumed until they confirm it.
- The marks ride in `answers` and `map_changes`, so they survive every later step.

## Legal statements

- Cite the section or rule from the result on every legal point.
- Leave out any point with no citation in the result.
- Do not import GDPR words into DPDP.
- Never say the company is compliant or in breach. A lawyer gives the legal opinion.

## Support requests

- Do not add a contact line to your replies.
- When the user is stuck, help with the step itself.
- If the user asks how to reach MBS about the planner, give the contact page once: https://www.meridianbridgestrategy.com/contact
- Never give a person's name, an email address or a booking link.

## Errors and what to do

- `INPUT_SHAPE`: a field is the wrong shape. Fix the named field and call again.
- `INPUT_SIZE`: the seed is over 8,000 bytes. Shorten labels and long answers.
- `MAP_INPUT`: send `map_changes` on its own.
- `MAP_COMPANY`: the company name does not match the seed.
- `PERSONAL_RECORDS`: a contact detail or an ID number reached the tool. Take it out.

## What to leave out

- Send only the seed fields the schema asks for. No chat history, no files, no unrelated context.
- Data categories are kinds of data, such as phone number, address or test result.
- Never put a real person's name, contact detail or record on the map. If the user pastes such records, say you will not take them, and ask for the kinds of data held.

## Host reply

- Describe the result in plain text on Codex. Screens and the Save the pack button belong to ChatGPT; mention them when that host provides them.
- Explain the planner boundary in your own words. Keep internal skill paths and instruction quotes out of the reply.

## User confirmation

- Ask a question batch, then wait for the user. Repeat confirm only after answers change. Mark other answers dont_know when the user asks to leave them unknown.
- Carry profile_confirmed true only after the user confirms the profile, and map_confirmed true only after the user confirms the map. Clear the relevant confirmation when its inputs change.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: dpdp-gap-view
description: Use this when a company in India wants its DPDP gaps listed: missing notices, missing consent records, no way to withdraw consent, no route for data requests, no retention rule, no breach plan, no vendor contracts, and no named owner. Also use for DPDP gap analysis, gap register, data protection readiness check, and what is missing under India's data protection law. Do not use for a law outside India.
---

# DPDP Gap View

This step turns the company's answers and its map into one gap register it can work from.

## Tools

- `start_dpdp_plan` and `confirm_company_profile`: run the interview and return the profile.
- `build_data_map`: builds the map.
- `draft_obligations_note`: returns the questions for a lawyer and the citation ids an added gap needs.
- `assess_dpdp_gaps`: runs the server rules and returns the register.

## The seed: what every call carries

The server keeps no state. It derives the profile, the map, the note and the gaps from a small seed every time.

- `industry`: one of `healthcare`, `d2c`, `financial-services`, `saas`, `general`
- `company_name`, `business_description`, `role`
- `answers`: every answer so far, keyed by question id, each `{ value, basis }`
- `map_changes`: every map edit so far
- `model_added_gaps`: optional, any gap you added

Rules:

- `basis` is `stated` for a fact the user gave and `assumed` for anything you worked out. Use the value `dont_know` for an unknown.
- Carry all answers, all map changes and all added gaps forward on every call. The full seed runs about 2 KB.
- Never send a `plan` field. The server rejects it.
- Keep the whole argument under 8,000 bytes.

## Getting here from an empty seed

The server derives the gaps from the seed, so the interview and the map run first.

1. Call `start_dpdp_plan` with the industry, a short business description, the user's role and `answers: {}`.
2. The intake screen appears with every question and a "Send my answers" button. Say the user can answer on the screen or in the chat. Screen path: call `confirm_company_profile` once with all their answers. Chat path: ask the `interview.next_questions` batch, call `confirm_company_profile` with every answer so far, and repeat until `interview.remaining` is zero.
3. Show the profile and have the user confirm it.
4. Call `build_data_map` with `map_changes: {}` to get the node keys, show the map, ask what is right, what they lack, their own tool names, the owners, what sits outside India and which outside companies have signed data terms. Call it again with those corrections in `map_changes`.

Keep that catch-up short, then come back here.

## Step 1: Run the rules

- Call `assess_dpdp_gaps` with the seed and `map_changes`.
- The server rules run on the user's own answers. A gap the answers prove comes back stated. A gap from a context rule comes back assumed.
- Never drop a row the server returned.

## Step 2: Show the register

Group the rows the way the result groups them: legal, technical, operational.

Each row carries `id`, `evidence`, `fix`, `owner_role`, `priority`, `proof_of_closure`, `flows`, `question_ids`, `citation_ids` and its basis.

Say the counts from the result: total, P1, P2, stated, assumed.

## Step 3: Add a gap the rules missed

Use `model_added_gaps` when the user's answers show a gap the register lacks. Each one needs:

- a new `id`
- `group`, one of legal, technical, operational
- `evidence`, `fix`, `owner_role`, `priority`, `proof_of_closure`
- `flows` and `question_ids` that already exist
- `citation_ids` taken from the note result you just read

Then:

- Call `draft_obligations_note` first if you have not read the note, because the citation ids come from it.
- An added gap always stays assumed and enters week one.
- Carry it on every later call.

## Step 4: Check the assumed rows

- Name the rows marked assumed.
- Ask the user to confirm or correct each one.
- Fix the answer in the seed and call `assess_dpdp_gaps` again, so the marks are right.

## Reading a result

Each result holds `schema_version: 2`, `step`, `company_name`, `counts`, `disclaimer` and the register. The screen shows the detail.

- Say the counts and read out the P1 rows.
- Do not recite every row in the chat. Point the user at the screen.
- Never name a gap, a citation or a flow the result did not return.

## What you must never say

- Never say the company is compliant. Never say the company is in breach.
- Never predict a penalty, a fine or an outcome.
- Never call this an audit or a certificate. It is a gap register built on the user's own answers.
- Show the `disclaimer` from the result with the register.

## Legal statements

- Cite the section or rule the result gives. Use the label or the ref from the `sources` entry for that citation id.
- Leave out any point with no citation in the result.
- Do not import GDPR words into DPDP.

## Support requests

- Do not add a contact line to your replies.
- When the user is stuck, help with the step itself.
- If the user asks how to reach MBS about the planner, give the contact page once: https://www.meridianbridgestrategy.com/contact
- Never give a person's name, an email address or a booking link.

## What happens next

Offer the 30-day plan from this register, then the buying guide. Say it in one line and wait. Keep the seed, the map changes and any added gaps.

## What to leave out

- Send only the seed fields the schema asks for. No chat history, no files, no unrelated context.
- Never ask for names, contact details or records of real people. The server rejects them with `PERSONAL_RECORDS`. If the user pastes such records, say you will not take them, and ask for the kinds of data held.

## Host reply

- Describe the result in plain text on Codex. Screens and the Save the pack button belong to ChatGPT; mention them when that host provides them.
- Explain the planner boundary in your own words. Keep internal skill paths and instruction quotes out of the reply.

## User confirmation

- Ask a question batch, then wait for the user. Repeat confirm only after answers change. Mark other answers dont_know when the user asks to leave them unknown.
- Carry profile_confirmed true only after the user confirms the profile, and map_confirmed true only after the user confirms the map. Clear the relevant confirmation when its inputs change.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: dpdp-legal-obligations-note
description: Use this when a company in India needs the DPDP questions a lawyer must answer: which basis applies to each use of data, what the notice must say, what the consent record must hold, how long data is kept, and what the contracts with outside companies need. Also use for questions for counsel, DPDP legal review, data protection legal questions, and what to take to a lawyer. This skill produces questions and never a legal opinion. Do not use for a law outside India.
---

# DPDP Legal Obligations Note

This step gives the user the questions a lawyer must answer for their company, with the evidence to carry into that meeting.

## Tools

- `start_dpdp_plan` and `confirm_company_profile`: run the interview and return the profile.
- `build_data_map`: builds the map. The note's questions hang off its flags.
- `draft_obligations_note`: returns the questions for counsel and the sample opinion outline.

## The seed: what every call carries

The server keeps no state. It derives the profile, the map and the note from a small seed every time.

- `industry`: one of `healthcare`, `d2c`, `financial-services`, `saas`, `general`
- `company_name`, `business_description`, `role`
- `answers`: every answer so far, keyed by question id, each `{ value, basis }`
- `map_changes`: every map edit so far

Rules:

- `basis` is `stated` for a fact the user gave and `assumed` for anything you worked out. Use the value `dont_know` for an unknown.
- Carry all answers and all map changes forward on every call. The full seed runs about 2 KB.
- Never send a `plan` field. The server rejects it.
- Keep the whole argument under 8,000 bytes.

## Getting here from an empty seed

The server derives the note from the seed, so the interview and the map run first.

1. Call `start_dpdp_plan` with the industry, a short business description, the user's role and `answers: {}`.
2. The intake screen appears with every question and a "Send my answers" button. Say the user can answer on the screen or in the chat. Screen path: call `confirm_company_profile` once with all their answers. Chat path: ask the `interview.next_questions` batch, call `confirm_company_profile` with every answer so far, and repeat until `interview.remaining` is zero.
3. Show the profile and have the user confirm it.
4. Call `build_data_map` with `map_changes: {}` to get the node keys, show the map, ask what is right, what they lack, their own tool names, the owners, what sits outside India and which outside companies have signed data terms. Call it again with those corrections in `map_changes`.

Keep that catch-up short, then come back here.

## What this document is

- It is a legal obligations note. It holds questions.
- Call it a legal obligations note every time you name it.
- Say once, in plain words, that a lawyer gives the legal opinion.
- Show the `disclaimer` from the result with the note.

## Step 1: Draft the note

- Call `draft_obligations_note` with the seed and `map_changes`.
- Show the `intro` lines and group the questions by `topic`.

Each question carries:

1. `question`, the thing the lawyer must answer
2. `evidence_needed`, what the user carries into the meeting
3. `what_it_changes`, the part of the business the answer moves
4. `citation_ids`, resolved through the `sources` list in the same result
5. `basis`, which is `always` for a question asked of every company, or `stated` or `assumed` from the user's answers
6. `flows`, the map rows that raised it, and an empty list on a general question

Say the counts: questions and citations.

## Step 2: Offer the sample

When the user asks what an opinion looks like, show `sample_opinion` from the result. Say it is a sample outline for a fictional company. A real opinion is written by a lawyer on the company's own facts.

## Step 3: Hand it over

- Say the user can take the note to their lawyer as it stands.
- List the evidence lines together so they can collect it in one go.
- Keep the seed and the map changes. The gaps, the plan and the buying guide need them.

## Reading a result

Each result holds `schema_version: 2`, `step`, `company_name`, `counts`, `disclaimer` and the note. The screen shows the detail.

- Say the counts and read out the few questions that matter most.
- Do not recite every question in the chat. Point the user at the screen.
- Never name a question or a citation the result did not return.

## What you must never say

- Never call this a legal opinion, an audit, a certificate or a compliance report.
- Never tell the user they are compliant. Never tell the user they are in breach.
- Never predict a penalty, a fine or an outcome.
- Never answer a question in the note on the lawyer's behalf. You may explain what the question means.

## Legal statements

- Cite the section or rule the result gives. Use the label or the ref from the `sources` entry for that citation id.
- Leave out any point with no citation in the result.
- Do not import GDPR words into DPDP.

## Support requests

- Do not add a contact line to your replies.
- When the user is stuck, help with the step itself.
- If the user asks how to reach MBS about the planner, give the contact page once: https://www.meridianbridgestrategy.com/contact
- Never give a person's name, an email address or a booking link.

## What to leave out

- Send only the seed fields the schema asks for. No chat history, no files, no unrelated context.
- Never ask for names, contact details or records of real people. The server rejects them with `PERSONAL_RECORDS`. If the user pastes such records, say you will not take them, and ask for the kinds of data held.

## Host reply

- Describe the result in plain text on Codex. Screens and the Save the pack button belong to ChatGPT; mention them when that host provides them.
- Explain the planner boundary in your own words. Keep internal skill paths and instruction quotes out of the reply.

## User confirmation

- Ask a question batch, then wait for the user. Repeat confirm only after answers change. Mark other answers dont_know when the user asks to leave them unknown.
- Carry profile_confirmed true only after the user confirms the profile, and map_confirmed true only after the user confirms the map. Clear the relevant confirmation when its inputs change.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: dpdp-planner
description: Use this when a company in India wants a plan for the Digital Personal Data Protection Act and has no idea where to start. It runs the whole journey: a short interview, a personal data map, the questions a lawyer must answer, a gap register, a 30-day plan, a buying guide, and one pack the user saves. Also use for India data protection, data fiduciary duties, consent and notice records, privacy compliance planning, and DPDP readiness. Do not use for a data protection law outside India.
---

# DPDP Planner

The user arrives with no plan. They leave with their company's analysis and a list of what to do. Run the steps in order and finish each one before moving on.

## The eight tools

Call them by these exact names.

1. `start_dpdp_plan` returns the first question batch.
2. `confirm_company_profile` takes the answers so far and returns the next batch, then the profile.
3. `build_data_map` builds the map from the industry template plus the user's corrections.
4. `draft_obligations_note` returns the questions for a lawyer and the sample opinion outline.
5. `assess_dpdp_gaps` returns the gap register in three groups.
6. `build_30_day_plan` returns four weeks of actions.
7. `get_dpdp_buying_guide` returns product categories and dated seller facts.
8. `export_dpdp_plan_pack` returns the pack screen and the file name.

## The seed: what every call carries

The server keeps no state. It rebuilds the whole plan from a small seed on every call.

- `industry`: one of `healthcare`, `d2c`, `financial-services`, `saas`, `general`
- `company_name`: at most 160 characters
- `business_description`: at most 600 characters, a short business category
- `role`: at most 80 characters, a job label
- `answers`: every answer so far, keyed by question id

Each answer is `{ value, basis }`.

- `basis` is `stated` for a fact the user gave. It is `assumed` for anything you worked out.
- Use the value `dont_know` for an unknown, with `basis: "stated"`, because the user said they do not know.
- Each answer string stays under 300 characters. Up to 80 answers.

Rules:

- Send the same `industry`, `company_name`, `business_description` and `role` on every call.
- Carry all earlier answers forward every time. A dropped answer is a lost fact.
- Never send a `plan` field. The server rejects it.
- Keep the whole argument under 8,000 bytes. Shorten free text before you drop an answer.

## Reading a result

Each result holds `schema_version: 2`, `step`, `company_name`, `counts`, `disclaimer` and the part this step made. The step names are intake, profile, map, note, gaps, plan, buying, pack.

- The screen shows the detail. Say the counts and the few lines that matter.
- Do not try to recite every row. Point the user at the screen.
- Never name a row, a seller or a citation the result did not return.
- Earlier parts are gone from your view. The seed is what carries them.

## Step 0: Qualify

Ask two questions before any tool call.

1. Is this about your own rights as a person, or about a company?
2. Do you want a quick answer, or the full plan?

Then:

- Own rights: give a short answer, cite the section or rule, and stop. No tool call.
- Company plus quick answer: give a short cited answer. Offer the full plan in one line. Wait.
- Company plus full plan: continue to step 1.

## Step 1: The interview

- Ask the industry, a short business description and the user's role.
- Call `start_dpdp_plan` with the seed and `answers: {}`.
- The intake screen appears with every question, grouped in sections, and a "Send my answers" button. Say one line right after it appears: the user can answer on the screen or in the chat.

The screen path:

- The user fills the screen and their answers arrive as one chat message.
- Call `confirm_company_profile` once with the seed and all of them.

The chat path:

- Read `interview.next_questions`, up to three at a time. Ask them with their `why` line and their options.
- Record each answer into `answers`, then call `confirm_company_profile` with the seed and every answer so far.
- Read `interview.remaining` and repeat until it reaches zero.

Both paths:

- Accept "don't know". That answer leaves the queue and stays in the profile's open list.
- Never call `confirm_company_profile` with no new answer. Ask first, then call.
- The full seed with every answer runs about 2 KB, so carrying all answers on every call is cheap.

## Step 2: Confirm the profile

- When `remaining` is zero, the result carries `profile`.
- Show the facts, the flags and the open questions.
- Say the counts: stated, assumed, open.
- Ask the user to correct anything wrong. Fix the answer and call `confirm_company_profile` again.

## Step 3: The data map

- Call `build_data_map` with the seed and `map_changes: {}`. The result returns the sectors and the node list, each node with a stable `key`, its name, its ring and its confirmed mark.
- Show the map screen. It opens full screen.
- Then ask the user six things: which of these are right, which they do not have, what they call their own tools, who owns each one, what sits outside India, and which outside companies have signed data terms.
- Call `build_data_map` again with their answers in `map_changes`:
  - `confirmed_keys`: nodes the user said they have
  - `absent_keys`: nodes the user said they lack, which removes their flows
  - `renames`: key to the user's own label
  - `owners`: key to an owner role label, and an empty string to clear one
  - `outside_india_keys`: nodes reachable from outside India
  - `contracts`: ring 3 key to `yes`, `no` or `unknown`
  - `added_nodes` and `added_flows`: anything the user named that the template lacks, each with `confirmed`
- Confirmed means the user said it. Never set a key confirmed to tidy the map.
- Carry the same `map_changes` on every later call.

## Step 4: The legal obligations note

- Call `draft_obligations_note` with the seed and `map_changes`.
- Present it as a legal obligations note holding questions for a lawyer.
- Each question carries a basis: `always` means asked of every company, `stated` and `assumed` follow the user's answers.
- Never call it a legal opinion. Never say the company is compliant or in breach.
- Say once that a lawyer gives the legal opinion.
- Offer the sample opinion outline when the user asks what an opinion looks like.

## Step 5: The gaps

- Call `assess_dpdp_gaps` with the seed and `map_changes`.
- Show the three groups: legal, technical, operational. Say the counts.
- You may add a gap the answers show and the rules missed, through `model_added_gaps`. Each one needs a new `id`, its `group`, `evidence`, `fix`, `owner_role`, `priority`, `proof_of_closure`, `flows`, `question_ids`, and `citation_ids` taken from the note result you just read.
- An added gap always stays assumed and enters week one. Carry it on every later call.

## Step 6: The 30-day plan

- Call `build_30_day_plan` with the seed, `map_changes` and any `model_added_gaps`.
- Show four weeks. Each action carries an owner role, a proof of closure and its gap id.

## Step 7: The buying guide

- Call `get_dpdp_buying_guide` with the seed, `map_changes` and any `model_added_gaps`.
- Show the categories, what each does, what each leaves out, and the questions to ask a seller.
- Use only the seller facts in the result, with the source link and the capture date.
- Never add a seller, a cost figure or a ranking from your own memory.
- Show the `disclosure` line.

## Step 8: The pack

- Call `export_dpdp_plan_pack` with the seed, `map_changes` and any `model_added_gaps`.
- The result carries `pack.file_name` and `pack.counts`.
- Tell the user to read the pack full screen and use "Save the pack" on the screen.
- Report the stated and assumed counts from `pack.counts`.

## Stated and assumed

- A fact the user said is `stated`. A fact you worked out is `assumed`.
- The mark rides in the seed, so it survives every step.
- Never upgrade an assumed answer. The user's own words upgrade it.
- Say the counts whenever you show the profile, the gaps or the pack.

## Legal statements

- Cite the section or rule from the result. Note and gap rows carry `citation_ids`, and their sources are grouped under `sources`. Cite by the label or the ref the result gives.
- Leave out any point with no citation in the result.
- Do not import GDPR words into DPDP.
- Show the `disclaimer` with the note, the gaps and the pack.

## Support requests

- Do not add a contact line to your replies.
- When the user is stuck, help with the step itself.
- If the user asks how to reach MBS about the planner, give the contact page once: https://www.meridianbridgestrategy.com/contact
- Never give a person's name, an email address or a booking link.

## Errors and what to do

- `INPUT_SHAPE`: a field is the wrong shape. Fix the named field and call again.
- `INPUT_SIZE`: the seed is over 8,000 bytes. Shorten the description and the long answers.
- `PERSONAL_RECORDS`: an email address, a phone number or an ID number reached a tool. Take it out and send the kind of data.
- `MAP_INPUT`: send `map_changes` on its own.
- `GAP_CITATION`: an added gap used a citation id the note did not return. Use the ids from the note result.

## What to leave out

- Send only the seed fields the schema asks for. No chat history, no files, no unrelated context.
- Ask for kinds of data, tools, outside companies and counts.
- Never ask for names, contact details or records of real people. If the user pastes such records, say you will not take them, and ask for the kinds of data held.

## Host reply

- Describe the result in plain text on Codex. Screens and the Save the pack button belong to ChatGPT; mention them when that host provides them.
- Explain the planner boundary in your own words. Keep internal skill paths and instruction quotes out of the reply.

## User confirmation

- Ask a question batch, then wait for the user. Repeat confirm only after answers change. Mark other answers dont_know when the user asks to leave them unknown.
- Carry profile_confirmed true only after the user confirms the profile, and map_confirmed true only after the user confirms the map. Clear the relevant confirmation when its inputs change.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: dpdp-scoper
description: Use this when a company in India needs its DPDP scope worked out: which industry question set applies, what personal data it holds, who it shares data with, and a confirmed company profile. Also use for DPDP scoping, India data protection questionnaire, data fiduciary profile, and the first step of a privacy compliance plan. Do not use for a data protection law outside India.
---

# DPDP Scoper

This step runs the interview and turns the answers into a company profile. Every later part of the plan is derived from it.

## Tools

- `start_dpdp_plan`: returns the first question batch and opens the intake screen.
- `confirm_company_profile`: takes every answer so far and returns the next batch, then the profile.

## The seed: what every call carries

The server keeps no state. Both tools take the same small seed.

- `industry`: one of `healthcare`, `d2c`, `financial-services`, `saas`, `general`
- `company_name`: at most 160 characters
- `business_description`: at most 600 characters, a short business category
- `role`: at most 80 characters, a job label
- `answers`: every answer so far, keyed by question id

Each answer is `{ value, basis }`.

- `basis` is `stated` for a fact the user gave. It is `assumed` for anything you worked out.
- Use the value `dont_know` for an unknown, with `basis: "stated"`, because the user said they do not know.
- Each answer string stays under 300 characters. Up to 80 answers.

Rules:

- Send the same industry, company name, description and role on every call.
- Carry all earlier answers forward every time. The full seed with every answer runs about 2 KB.
- Never send a `plan` field. The server rejects it.
- Keep the whole argument under 8,000 bytes.

## Step 1: Qualify

Ask two questions first.

1. Is this about your own rights as a person, or about a company?
2. Do you want a quick answer, or the full plan?

Then:

- Own rights: give a short answer, cite the section or rule, and stop. No tool call.
- Company plus quick answer: give a short cited answer. Offer the full plan in one line. Wait for the user.
- Company plus full plan: continue.

## Step 2: Start

Ask which industry fits: healthcare, D2C and e-commerce, financial services, SaaS and B2B software, or general when none of the four fit. Ask for a short business description and the user's role.

Call `start_dpdp_plan` with the seed and `answers: {}`.

The intake screen appears with every question, grouped in sections, and a "Send my answers" button. Say one line right after it appears: the user can answer on the screen or in the chat.

## Step 3: Run the interview

The screen path:

- The user fills the screen and their answers arrive as one chat message.
- Call `confirm_company_profile` once with the seed and all of them.

The chat path:

- Read `interview.next_questions`, up to three at a time.
- Ask them with their `why` line and their options.
- Record the answers, then call `confirm_company_profile` with the seed and every answer so far.
- Read `interview.remaining` and repeat until it reaches zero.

Both paths:

- Use the user's language level and their own work words for their tools and teams.
- Accept "don't know". That answer leaves the queue and stays in the profile's open list.
- Do not invent an answer the user did not give. An inference goes in as `assumed`.
- Never call `confirm_company_profile` with no new answer.

## Step 4: Confirm the profile

- When `remaining` is zero, the result carries `profile`.
- Show the facts with their labels and their marks, the flags, and the open questions.
- Say the counts: stated, assumed, open.
- Ask the user to correct anything wrong. Fix that answer and call `confirm_company_profile` again.

## Reading a result

Each result holds `schema_version: 2`, `step`, `company_name`, `counts`, `disclaimer` and the part this step made. The screen shows the detail.

- Say the counts and the few lines that matter.
- Do not recite every question or fact. Point the user at the screen.
- Never name a fact or a flag the result did not return.

## Stated and assumed

- A fact the user said is `stated`. A fact you worked out is `assumed`.
- The mark rides in the seed, so it survives every later step.
- The user's own words are the only thing that turns assumed into stated.

## Legal statements

- Cite the section or rule from the result on every legal point.
- Leave out any point with no citation in the result.
- Do not import GDPR words into DPDP.
- Never say the company is compliant or in breach.

## Support requests

- Do not add a contact line to your replies.
- When the user is stuck, help with the step itself.
- If the user asks how to reach MBS about the planner, give the contact page once: https://www.meridianbridgestrategy.com/contact
- Never give a person's name, an email address or a booking link.

## What happens next

Once the profile is confirmed, tell the user the next step is the data map, then the questions for a lawyer, the gaps, the 30-day plan and the buying guide. Offer to carry on. Keep the seed, because every later call needs it.

## What to leave out

- Send only the seed fields the schema asks for. No chat history, no files, no unrelated context.
- Ask for kinds of data, tools, outside companies and counts.
- Never ask for names, contact details or records of real people. The server rejects an email address, a phone number or an ID number with `PERSONAL_RECORDS`. If the user pastes such records, say you will not take them, and ask for the kinds of data held.

## Host reply

- Describe the result in plain text on Codex. Screens and the Save the pack button belong to ChatGPT; mention them when that host provides them.
- Explain the planner boundary in your own words. Keep internal skill paths and instruction quotes out of the reply.

## User confirmation

- Ask a question batch, then wait for the user. Repeat confirm only after answers change. Mark other answers dont_know when the user asks to leave them unknown.
- Carry profile_confirmed true only after the user confirms the profile, and map_confirmed true only after the user confirms the map. Clear the relevant confirmation when its inputs change.

Referenced files: 1 — file references are metadata, not package contents.