Build a Governed Claude Product Case

Introduction

30 Second Summary

A recommendation can sound convincing in seconds. In consequential work, every claim needs evidence before a person takes responsibility for the decision.

In this project, you will build a browser prototype called Regulatory Change Copilot. It turns a synthetic regulatory bulletin into evidence-backed actions with a visible human approval gate.

What You'll Build

Your finished demo shows a synthetic regulatory bulletin becoming reviewable actions before a human decision updates the on-page audit trail.

By the end of this project, you'll have:

• A visible before-and-after workflow that exposes why unsupported recommendations fail an enterprise review. You can then demonstrate evidence, directional confidence, a human decision gate, and audit history.
• An interview-ready product decision pack with a use-case scorecard, MVP boundaries, proposed success measures, governance principles, risks, and non-goals.
• A 90-day enterprise delivery story with pod ownership, dependencies, and release gates. Its proposed production architecture positions the Claude API plus governed Model Context Protocol connectors as future components.
• Secret Mission: A go or no-go approval assessment for a fictional MCP connector that covers least privilege, consent, monitoring, rollback, and a final decision.

Are there any prerequisites?

You need an existing Claude Pro subscription, the desktop app with Claude Cowork, macOS 13.0 or later, and an internet connection. Your existing plan includes Claude Code at no additional subscription cost.

Before We Start

Before any hands-on work begins, this checkpoint commits you to an interview-ready Regulatory Change Copilot built with synthetic data. Its consequential recommendations need reviewable evidence with directional confidence plus accountable human approval recorded in an audit trail.

Set Up the Claude Product Case Workspace

Your Regulatory Change Copilot needs a controlled local home before the prototype work begins. This boundary keeps the case focused on synthetic data.

Claude Code gives you an interactive workspace in Terminal. The CLAUDE.md file gives every later editing session the same capability boundaries.

That continuity keeps the enterprise story honest. It also makes the case repeatable.

In this step, get ready to:

• Confirm your Mac meets the supported operating-system requirement.
• Install Claude Code with the native installer.
• Create the controlled workspace and load its persistent project instructions.

Check your Mac and prepare Claude Code

Claude Code requires macOS 13.0 or later. Checking this first prevents an operating-system mismatch from interrupting the installation.

• Click the Apple menu in the top-left corner of your screen.
• Select About This Mac.
• Confirm the displayed macOS version is 13.0 or later.

Seeing a Version Below 13.0?

Your Mac needs a supported macOS release before Claude Code can run.

• Press Cmd+Space to open Spotlight.
• Type System Settings and press Return.
• Select General in the sidebar.
• Select Software Update.
• Install a supported macOS update before continuing.

Help me check whether my Mac can update to macOS 13.0 or later.

The native installer handles the Claude Code installation from Terminal. You will verify the result in a fresh Terminal window so the shell can find the new command.

• Press Cmd+Space to open Spotlight.
• Type Terminal and press Return to open it.
• Install Claude Code with Anthropic's native installer by running this command:

curl -fsSL https://claude.ai/install.sh | bash

• Open a fresh Terminal window after the installer completes.
• Check the installed Claude Code version by running this command:

claude --version

✔️ I see version 2.1.303 or higher

You should see a version number followed by (Claude Code). A result of 2.1.303 or later confirms the native installation is ready.

That is the first setup hurdle cleared. Claude Code can now run from a fresh Terminal session.

ⓧ I see an older version

An older result means your current Claude Code installation needs a refresh. The native installer can replace it with the current release.

• Install the current native release by running this command:

curl -fsSL https://claude.ai/install.sh | bash

• Open a fresh Terminal window after the installer completes.
• Check the version again by running this command:

claude --version

You should now see 2.1.303 or a later version followed by (Claude Code).

ⓧ Command not found

Terminal cannot find Claude Code yet. A fresh installation provides the command.

• Install Claude Code by running this command:

curl -fsSL https://claude.ai/install.sh | bash

• Close the current Terminal window after the installer completes.
• Open a fresh Terminal window through Spotlight.
• Check the installation by running this command:

claude --version

You should see a version number followed by (Claude Code).

Installer or Version Check Failing?

• Open a fresh Terminal window so the shell reloads its command paths.
• Run the native installer again if the earlier download was interrupted.
• Confirm your Mac still has an active internet connection.

Help me troubleshoot my Claude Code native installation.

Build the local workspace

A dedicated folder gives Claude Code a clear boundary for every file it can create in this case. The folder lives at ~/Documents/claude-enterprise-case so it stays separate from unrelated work.

• Create the claude-enterprise-case folder inside Documents by running this command:

mkdir ~/Documents/claude-enterprise-case

• Click Finder in the Dock.
• Select Documents in the Finder sidebar.

You should see the claude-enterprise-case folder in Documents. This confirms the workspace exists in the intended location.

Your existing Claude Pro subscription includes Claude Code. The first interactive launch uses a browser prompt to authenticate that account.

This sign-in uses the subscription you already have. It does not add another subscription cost.

• Move into the new workspace by running this command:

cd ~/Documents/claude-enterprise-case

• Start an interactive Claude Code session by running this command:

claude

• Complete the browser sign-in with your existing Claude Pro account.
• Return to Terminal after authentication finishes.

You should see the Claude Code interactive session open in the local workspace. The prompt is now ready to work with files inside claude-enterprise-case.

Claude Code Session Not Opening?

• Confirm the browser sign-in completed with the same Claude Pro account you intend to use.
• Check your internet connection if the browser authentication page is still waiting.
• Return to the Terminal window where you ran claude after authentication completes.

Help me troubleshoot why my authenticated Claude Code session is not opening.

Load persistent project instructions

Project instructions act as a standing product brief for Claude Code. They keep synthetic-data rules and honest capability boundaries active throughout the build.

Claude Code may show a file-write permission request after it prepares the change. The request lets you inspect the target file before anything is written.

• Ask Claude Code to create CLAUDE.md in the current workspace using this exact content:

# Regulatory Change Copilot Project Instructions

- Build an interview-ready product case for a fictional professional-services firm.
- Use synthetic data only. Never request or include client, employer, or personal confidential information.
- Keep the prototype dependency-free in one `index.html` file with embedded CSS and JavaScript.
- Do not call external APIs, connect external systems, or imply that a static interaction performed a real action.
- Make human approval, evidence, confidence, and auditability visible in the user experience.
- Label roadmap dates, metrics, scores, and architecture choices as proposed product decisions.
- Preserve accessible labels, keyboard-friendly controls, readable contrast, and responsive layouts.
- Before editing, summarize the requested change and the risk it addresses.
- After editing, verify every tab and interactive control in Safari.

Why These Instructions Matter

• The synthetic-data rule protects confidential information during prototype work.
• The dependency-free rule keeps the demonstration contained in one local file.
• The capability boundaries prevent the static prototype from implying a real external action.
• The review instructions make each change easier to explain during an interview.

• Review the proposed CLAUDE.md file change in Claude Code.
• Allow Claude Code to write CLAUDE.md inside claude-enterprise-case.

Before you check, which project instruction file do you expect to see under Memory files?

• Confirm the project instructions loaded by running this command inside Claude Code:

/context

You should see CLAUDE.md listed under Memory files. This proves Claude Code loaded the workspace instructions.

That is the control layer in place. Every later prototype edit now starts with the same boundaries.

CLAUDE.md Missing From Memory Files?

• Confirm the filename is exactly CLAUDE.md.
• Confirm the file sits directly inside ~/Documents/claude-enterprise-case.
• Run /context again after Claude Code finishes writing the file.

Help me find why CLAUDE.md is missing from Memory files.

✔️ Awesome, I've got everything!

Your persistent project instructions are loaded for this workspace.

ⓧ I'd like to double check the full code

• Compare your CLAUDE.md file with the complete reference below.

# Regulatory Change Copilot Project Instructions

- Build an interview-ready product case for a fictional professional-services firm.
- Use synthetic data only. Never request or include client, employer, or personal confidential information.
- Keep the prototype dependency-free in one `index.html` file with embedded CSS and JavaScript.
- Do not call external APIs, connect external systems, or imply that a static interaction performed a real action.
- Make human approval, evidence, confidence, and auditability visible in the user experience.
- Label roadmap dates, metrics, scores, and architecture choices as proposed product decisions.
- Preserve accessible labels, keyboard-friendly controls, readable contrast, and responsive layouts.
- Before editing, summarize the requested change and the risk it addresses.
- After editing, verify every tab and interactive control in Safari.

Your controlled workspace is ready for product work. Next up, you will build the fast first prototype that exposes the trust gap.

Build the Ungoverned Prototype

Your controlled Claude Code workspace is ready. Its project instructions now keep every change inside a synthetic local case.

Now you will create the fastest clickable slice of Regulatory Change Copilot. Its plausible recommendations let you test whether a fast result can support consequential work.

In this step, get ready to:

• Create a valid one-file prototype with three proposed actions.
• Run the sample analysis locally in Safari.
• Record the enterprise risks exposed by the first milestone.

Create the first prototype milestone

A dependency-free prototype keeps the feedback loop short. The index.html file holds the page structure plus its local interaction.

• Stay in the Claude Code session from earlier.
• Ask Claude to create a valid first milestone in index.html.
• Specify Regulatory Change Copilot as the page title.
• Specify one textarea labelled Synthetic regulatory bulletin.
• Specify one button labelled Analyze Bulletin.
• Specify a hidden results section with exactly three proposed-action cards.
• Specify that selecting the button reveals the results when the bulletin contains text.

Why start with one file?

A single local file gives you a quick workflow test. It also keeps the milestone within the synthetic-data boundary from CLAUDE.md.

The browser handles every interaction locally. No external service receives the bulletin.

Claude Code may request permission before writing the file. Its change summary gives you a chance to check the scope.

• Review Claude's change summary before it writes the file.
• Confirm the summary names index.html as the only new file.
• Allow the edit after that scope is clear.

Did Claude build too much?

• Ask Claude to remove any extra project files it created for this milestone.
• Ask Claude to return index.html to the requested page elements plus the three action cards.

Help me bring my Claude Code prototype back to the requested one-file milestone.

✔️ Awesome, I've got everything!

Great. Your one-file milestone is ready for its browser test.

ⓧ I'd like to double check the full code

• Compare Claude's output with this exact milestone.
• Ask Claude to replace index.html with this version if any line differs.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Regulatory Change Copilot</title>
</head>
<body>
  <main>
    <h1>Regulatory Change Copilot</h1>
    <p>Prototype using synthetic data only.</p>
    <label for="bulletin">Synthetic regulatory bulletin</label>
    <textarea id="bulletin">Fictional Bulletin RC-24-07: Beginning next quarter, covered business units must document the source, owner, and review date for every automated regulatory impact assessment. Material actions require approval from an accountable business owner before downstream systems are updated. Records must be available for internal review.</textarea>
    <button id="analyzeButton">Analyze Bulletin</button>
    <section id="results" hidden>
      <h2>Proposed actions</h2>
      <article><h3>Create an assessment evidence record</h3><p>Add source, owner, and review-date fields to the assessment workflow.</p></article>
      <article><h3>Add an accountable-owner approval step</h3><p>Require a named business owner to approve material actions before execution.</p></article>
      <article><h3>Define review access and retention requirements</h3><p>Confirm who can review records and how long the organization should retain them.</p></article>
    </section>
  </main>
  <script>
    const analyzeButton = document.getElementById("analyzeButton");
    const results = document.getElementById("results");
    const bulletin = document.getElementById("bulletin");
    analyzeButton.addEventListener("click", () => {
      if (!bulletin.value.trim()) {
        window.alert("Add a synthetic bulletin before running the analysis.");
        return;
      }
      results.hidden = false;
    });
  </script>
</body>
</html>

How does this milestone work?

• The results section starts hidden. The first screen focuses on the bulletin.
• The analyzeButton listener waits for a click. It reveals the three cards after the bulletin passes the empty-text check.
• The bulletin.value.trim() check blocks an empty analysis. This keeps the visible result tied to bulletin text.

Run the sample analysis in Safari

The local file gives you a browser demo without deployment. Opening it now confirms that the requested interaction works before you judge its product quality.

• Press Cmd+Space to open macOS search.
• Type Safari and press Enter.
• Press Command-O in Safari.
• Select ~/Documents/claude-enterprise-case/index.html in the file dialog.
• Press Enter to open the file.

Your first visible win is on screen. Safari now shows the Regulatory Change Copilot title above the synthetic bulletin and the Analyze Bulletin button.

Before you select Analyze Bulletin, do you think three polished recommendations can carry a consequential decision by themselves?

• Select Analyze Bulletin.

You'll see three proposed-action cards below the button. Each card presents a concrete recommendation based on the synthetic bulletin.

• Read each proposed action as if you were the accountable business owner.
• Look for support behind each claim.
• Look for a way to capture a human decision.
• Look for a record of what happened.

The cards show no evidence snippets or source labels. They also show no confidence labels.

The page provides no approve or reject control. It records no audit event.

What did the obstacle reveal?

• Unsupported claims arise because no evidence supports the recommendations.
• Accountability is unclear because the page has no human decision control.
• Decision history disappears because the page writes no audit record.

Your fast prototype now makes the enterprise trust gap concrete. Next, you will add the controls that turn its recommendations into a reviewable workflow.

Add Evidence, Approval, and Auditability

Your first prototype made the trust gap visible. Its plausible actions had no evidence, accountable decision owner, or record of human review.

You will use Claude Code to turn that weak output into a governed workflow. Safari will show whether each control works before the product case moves forward.

In this step, get ready to:

• Add evidence, source context, directional confidence, and honest capability boundaries.
• Add a human decision gate with mutually exclusive approval controls.
• Record the analysis and human decision in a visible audit trail.

Add evidence and boundary labels

A reviewable recommendation needs a visible link to its source. It also needs clear boundaries that prevent a static demonstration from appearing to offer professional advice or perform a real external action.

• In Claude Code, tell it to replace the paragraph beginning Prototype using synthetic data only. through the analyzeButton button with this exact HTML:

    <p>Static POC with synthetic data and no external system access.</p>
    <section>
      <h2>1. Review the synthetic bulletin</h2>
      <label for="bulletin">Synthetic regulatory bulletin</label>
      <textarea id="bulletin">Fictional Bulletin RC-24-07: Beginning next quarter, covered business units must document the source, owner, and review date for every automated regulatory impact assessment. Material actions require approval from an accountable business owner before downstream systems are updated. Records must be available for internal review.</textarea>
      <button id="analyzeButton">Analyze Bulletin</button>
      <p>This demonstration does not provide legal, tax, or regulatory advice.</p>
    </section>

What does this boundary establish?

• The opening label identifies the prototype as a static POC that uses synthetic data.
• The advice statement prevents the demonstration from presenting its output as professional guidance.
• The bulletin stays unchanged so each recommendation can point back to the same synthetic source.

• Switch back to Safari.
• Reload index.html.

You should see the new static POC boundary above the bulletin. You should also see the professional-advice disclaimer below the analysis button.

Still seeing the old prototype label?

Check that Claude Code replaced the original paragraph instead of adding a second copy. Confirm that the edited file is index.html inside ~/Documents/claude-enterprise-case.

Ask Claude Code to compare the current opening markup with the provided section. Help me find why Safari still shows the old prototype label after reloading index.html.

• Tell Claude Code to insert this human decision section immediately before <section id="results" hidden>:

    <section>
      <h2>2. Human decision gate</h2>
      <p>Current status: <span id="decisionStatus">Waiting for analysis</span></p>
      <p>The prototype cannot update any external system. These controls only demonstrate the intended review experience.</p>
      <button id="approveButton" disabled>Approve Recommendation</button>
      <button id="rejectButton" disabled>Reject for Review</button>
    </section>

How does the decision gate work?

• The decisionStatus element gives the reviewer a visible workflow state.
• The disabled attributes block approval before an analysis exists.
• The external-system statement makes the prototype boundary visible beside the controls.

• Reload index.html in Safari.

You should see a human decision gate above the proposed actions. Both decision buttons should appear disabled while the status reads Waiting for analysis.

Are the decision buttons active too early?

Confirm that both button elements contain the disabled attribute. Check that the IDs match approveButton and rejectButton exactly.

Use this prompt if the initial state still looks wrong. Help me check why my approval controls are enabled before analysis runs.

• Tell Claude Code to replace the existing results section with this evidence assessment and audit trail:

    <section id="results" hidden>
      <h2>3. Evidence-backed impact assessment</h2>
      <article>
        <h3>Create an assessment evidence record</h3>
        <p>Affected team: Regulatory Operations. Directional confidence: High.</p>
        <p>Proposed action: Add source, owner, and review-date fields to the assessment workflow.</p>
        <p><strong>Evidence:</strong> "must document the source, owner, and review date for every automated regulatory impact assessment"</p>
      </article>
      <article>
        <h3>Add an accountable-owner approval step</h3>
        <p>Affected team: Business Control. Directional confidence: High.</p>
        <p>Proposed action: Require a named business owner to approve material actions before execution.</p>
        <p><strong>Evidence:</strong> "Material actions require approval from an accountable business owner"</p>
      </article>
      <article>
        <h3>Define review access and retention requirements</h3>
        <p>Affected team: Platform and Governance. Directional confidence: Medium.</p>
        <p>Proposed action: Confirm who can review records and how long the organization should retain them.</p>
        <p><strong>Evidence:</strong> "Records must be available for internal review." The bulletin does not specify access roles or retention length, so clarification is required.</p>
      </article>
    </section>
    <section>
      <h2>4. Demonstration audit trail</h2>
      <ol id="auditList"><li>Prototype loaded with synthetic data. No analysis performed.</li></ol>
    </section>

What makes these actions reviewable?

• Each action names the affected team that would own or review the proposed work.
• Each evidence label quotes the synthetic bulletin so the reviewer can inspect the source context.
• Each directional confidence label communicates product judgment without claiming a calibrated probability.
• The final recommendation calls out missing detail because the source does not define access roles or retention length.

• Reload index.html in Safari.
• Select Analyze Bulletin.

You should see three recommendations with affected teams, directional confidence, and quoted evidence. You should also see an audit trail containing its initial synthetic-data event.

Do the old action cards still appear?

Claude Code may have added the new assessment below the original results section. Keep one section with id="results" because duplicate IDs make the interaction unreliable.

Ask for a focused comparison if the page contains duplicate cards. Help me remove the original results section while preserving the evidence-backed section and audit list.

Wire the decision and audit events

The interface now presents the right controls. JavaScript must enforce their sequence so analysis unlocks one human decision and every meaningful event leaves a visible record.

• Tell Claude Code to replace everything currently between the opening and closing script tags with this first JavaScript block:

    const analyzeButton = document.getElementById("analyzeButton");
    const approveButton = document.getElementById("approveButton");
    const rejectButton = document.getElementById("rejectButton");
    const results = document.getElementById("results");
    const decisionStatus = document.getElementById("decisionStatus");
    const auditList = document.getElementById("auditList");
    const bulletin = document.getElementById("bulletin");
    function addAuditEvent(message) {
      const item = document.createElement("li");
      item.textContent = `${new Date().toLocaleTimeString()}: ${message}`;
      auditList.appendChild(item);
    }
    analyzeButton.addEventListener("click", () => {
      if (!bulletin.value.trim()) {
        window.alert("Add a synthetic bulletin before running the analysis.");
        return;
      }
      results.hidden = false;
      approveButton.disabled = false;
      rejectButton.disabled = false;
      decisionStatus.textContent = "Awaiting human decision";
      addAuditEvent("Synthetic bulletin analyzed. Three proposed actions await human review.");
    });

What happens after analysis?

• The element references connect the script to the analysis controls, decision controls, status, and audit list.
• The addAuditEvent() function adds a timestamped list item for each governed workflow event.
• A valid analysis reveals the recommendations and enables both human-decision options.
• The status moves to Awaiting human decision before any outcome is recorded.

Before you run the analysis, what should change once the bulletin has been processed?

• Reload index.html in Safari.
• Select Analyze Bulletin.

You should see both decision buttons become available. The status should change to Awaiting human decision while the audit trail gains an analysis event.

Did analysis stop updating the page?

Check each JavaScript ID against the matching HTML ID. A mismatch in decisionStatus or auditList prevents the event handler from finishing.

Use this prompt to inspect the wiring. Help me trace why Analyze Bulletin no longer enables the decision buttons or adds an audit event.

• Tell Claude Code to add these decision handlers immediately after the analysis handler:

    approveButton.addEventListener("click", () => {
      decisionStatus.textContent = "Approved for controlled follow-up";
      approveButton.disabled = true;
      rejectButton.disabled = true;
      addAuditEvent("Human reviewer approved the recommendation for controlled follow-up. No external action was taken.");
    });
    rejectButton.addEventListener("click", () => {
      decisionStatus.textContent = "Rejected for further review";
      approveButton.disabled = true;
      rejectButton.disabled = true;
      addAuditEvent("Human reviewer rejected the recommendation and requested further review. No external action was taken.");
    });

Why are the controls mutually exclusive?

• Approval updates the workflow status and records the reviewer outcome.
• Rejection records a different outcome that sends the recommendation back for review.
• Either decision disables both buttons so one analysis cannot receive conflicting outcomes.
• Both audit messages confirm that the static prototype performed no external action.

• Reload index.html in Safari.
• Select Analyze Bulletin.
• Select Approve Recommendation.

You should see the status change to Approved for controlled follow-up. Both decision buttons should become disabled while the audit trail records that no external action was taken.

Does the approval click do nothing?

Confirm that both decision handlers sit inside the existing script element. Check that the approval button uses id="approveButton" exactly.

Use this prompt to check the event listener. Help me debug why Approve Recommendation does not update the status or audit trail.

Test both decision paths

Approval has proved one branch of the gate. A complete governance check also confirms that rejection creates its own accountable outcome without implying an external update.

Before you test the second path, which controls and audit events should change after rejection?

• Reload index.html in Safari.
• Select Analyze Bulletin.
• Select Reject for Review.

You should see the status change to Rejected for further review. Both controls should become disabled while the audit trail records the rejection and confirms that no external action was taken.

• Review the three recommendations for affected teams, quoted evidence, and directional confidence.
• Review the page boundaries for synthetic data, professional advice, external system access, and external actions.

You have closed the trust gap that the naive prototype exposed. The workflow now supports evidence review, one accountable human decision, and a visible history of what happened.

✔️ Awesome, I've got everything!

Your governed workflow is complete. Every change is saved in index.html.

ⓧ I'd like to double check the full code

The complete governed milestone is shown below for comparison.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Regulatory Change Copilot</title>
</head>
<body>
  <main>
    <h1>Regulatory Change Copilot</h1>
    <p>Static POC with synthetic data and no external system access.</p>
    <section>
      <h2>1. Review the synthetic bulletin</h2>
      <label for="bulletin">Synthetic regulatory bulletin</label>
      <textarea id="bulletin">Fictional Bulletin RC-24-07: Beginning next quarter, covered business units must document the source, owner, and review date for every automated regulatory impact assessment. Material actions require approval from an accountable business owner before downstream systems are updated. Records must be available for internal review.</textarea>
      <button id="analyzeButton">Analyze Bulletin</button>
      <p>This demonstration does not provide legal, tax, or regulatory advice.</p>
    </section>
    <section>
      <h2>2. Human decision gate</h2>
      <p>Current status: <span id="decisionStatus">Waiting for analysis</span></p>
      <p>The prototype cannot update any external system. These controls only demonstrate the intended review experience.</p>
      <button id="approveButton" disabled>Approve Recommendation</button>
      <button id="rejectButton" disabled>Reject for Review</button>
    </section>
    <section id="results" hidden>
      <h2>3. Evidence-backed impact assessment</h2>
      <article>
        <h3>Create an assessment evidence record</h3>
        <p>Affected team: Regulatory Operations. Directional confidence: High.</p>
        <p>Proposed action: Add source, owner, and review-date fields to the assessment workflow.</p>
        <p><strong>Evidence:</strong> "must document the source, owner, and review date for every automated regulatory impact assessment"</p>
      </article>
      <article>
        <h3>Add an accountable-owner approval step</h3>
        <p>Affected team: Business Control. Directional confidence: High.</p>
        <p>Proposed action: Require a named business owner to approve material actions before execution.</p>
        <p><strong>Evidence:</strong> "Material actions require approval from an accountable business owner"</p>
      </article>
      <article>
        <h3>Define review access and retention requirements</h3>
        <p>Affected team: Platform and Governance. Directional confidence: Medium.</p>
        <p>Proposed action: Confirm who can review records and how long the organization should retain them.</p>
        <p><strong>Evidence:</strong> "Records must be available for internal review." The bulletin does not specify access roles or retention length, so clarification is required.</p>
      </article>
    </section>
    <section>
      <h2>4. Demonstration audit trail</h2>
      <ol id="auditList"><li>Prototype loaded with synthetic data. No analysis performed.</li></ol>
    </section>
  </main>
  <script>
    const analyzeButton = document.getElementById("analyzeButton");
    const approveButton = document.getElementById("approveButton");
    const rejectButton = document.getElementById("rejectButton");
    const results = document.getElementById("results");
    const decisionStatus = document.getElementById("decisionStatus");
    const auditList = document.getElementById("auditList");
    const bulletin = document.getElementById("bulletin");
    function addAuditEvent(message) {
      const item = document.createElement("li");
      item.textContent = `${new Date().toLocaleTimeString()}: ${message}`;
      auditList.appendChild(item);
    }
    analyzeButton.addEventListener("click", () => {
      if (!bulletin.value.trim()) {
        window.alert("Add a synthetic bulletin before running the analysis.");
        return;
      }
      results.hidden = false;
      approveButton.disabled = false;
      rejectButton.disabled = false;
      decisionStatus.textContent = "Awaiting human decision";
      addAuditEvent("Synthetic bulletin analyzed. Three proposed actions await human review.");
    });
    approveButton.addEventListener("click", () => {
      decisionStatus.textContent = "Approved for controlled follow-up";
      approveButton.disabled = true;
      rejectButton.disabled = true;
      addAuditEvent("Human reviewer approved the recommendation for controlled follow-up. No external action was taken.");
    });
    rejectButton.addEventListener("click", () => {
      decisionStatus.textContent = "Rejected for further review";
      approveButton.disabled = true;
      rejectButton.disabled = true;
      addAuditEvent("Human reviewer rejected the recommendation and requested further review. No external action was taken.");
    });
  </script>
</body>
</html>

Your governed prototype now shows how consequential recommendations earn trust. Next, you will turn its product choices into a decision pack and leadership narrative.

Create the Product Decision Pack

Your governed prototype now makes evidence, confidence, human approval, and auditability visible. A working POC still cannot demonstrate Associate Director scope on its own.

This step uses Claude Cowork to turn the prototype into a product decision pack. The finished documents connect the workflow to prioritization, measurable outcomes, governance, and executive leadership.

In this step, get ready to:

• Restrict Cowork to the controlled project workspace.
• Create a product brief with priorities, boundaries, measures, governance, and risks.
• Create an executive-reviewed interview brief that preserves the prototype boundaries.

Constrain Cowork to the case workspace

Cowork can read or write only inside the folders you connect. A dedicated folder boundary keeps this task focused on the synthetic case files.

Reviewing the plan before Cowork writes anything gives you a human checkpoint. This applies the same approval principle demonstrated by the prototype.

• Switch back to the Claude desktop app from earlier.
• Start a new Cowork task.
• Attach only ~/Documents/claude-enterprise-case through Cowork's folder picker.
• Tell Cowork to use synthetic data only.
• Tell Cowork to avoid client, employer, or personal confidential information.
• Ask Cowork to show its plan before creating any files.
• Review the proposed plan.

You should see a plan that names product-brief.md and interview-brief.md as the only new files. No file should have been created at this point.

• Allow Cowork to proceed after the plan confirms those boundaries.

Why use a dedicated folder?

The folder boundary limits Cowork's local file access to this product case. The plan review gives you a clear chance to stop an unexpected action before it changes the workspace.

Create the governed product brief

The product brief turns the prototype into a set of defendable decisions. Its opening establishes the problem, the users, and a proposed scorecard for selecting the MVP use cases.

• Ask Cowork to create product-brief.md with this opening content:

# Regulatory Change Copilot Product Brief

## Decision statement

Build a governed POC that helps professionals triage synthetic regulatory updates into reviewable actions. Do not automate downstream changes in the MVP.

## User problem

Professionals must interpret policy changes, identify impacted teams, and coordinate action while preserving evidence, accountability, and review.

## Primary users

- Regulatory analyst who prepares the first impact assessment
- Business owner who accepts or rejects proposed actions
- Risk and compliance reviewer who validates evidence and controls
- Product and technology teams that operate the workflow

## Use-case scorecard

Scores are proposed on a 1 to 5 scale, where 5 is highest.

| Use case | User value | Feasibility | Risk readiness | Decision |
| --- | ---: | ---: | ---: | --- |
| Summarize a bulletin | 4 | 5 | 4 | Include |
| Map affected teams | 5 | 4 | 4 | Include |
| Draft action recommendations | 5 | 4 | 3 | Include with approval |
| Automatically update systems | 4 | 2 | 1 | Exclude from MVP |

What does this section establish?

• The decision statement limits the POC to reviewable actions.
• The primary users separate preparation, ownership, assurance, and operation responsibilities.
• The proposed scorecard compares value, feasibility, and risk readiness before setting the MVP boundary.

• Review Cowork's proposed write to product-brief.md.
• Allow Cowork to create the file.
• Ask Cowork to display the beginning of the saved file.

You should see the product brief title followed by the decision statement, user problem, primary users, and use-case scorecard.

• Ask Cowork to append the MVP and measurement sections using this exact content:

## MVP scope

- Accept one synthetic bulletin as text
- Display impacted teams and proposed actions
- Show evidence and a confidence label for each action
- Require a human approve or reject decision
- Record a local demonstration audit event

## Non-goals

- No legal, tax, or regulatory advice
- No live client or firm data
- No external system updates
- No production authentication, authorization, retention, or monitoring
- No claim that prototype confidence labels are calibrated model probabilities

## Proposed success measures

- Decision cycle time from bulletin intake to reviewed action
- Percentage of recommendations accepted without material rewrite
- Percentage of actions with reviewer-confirmed evidence
- Reviewer override and escalation rate
- Weekly active users in the pilot cohort
- User-reported trust and usefulness

Why define measures beside boundaries?

The MVP scope states what the pilot tests. The non-goals prevent a static prototype from being mistaken for production software.

The proposed measures track speed, quality, adoption, and trust. Together they make success broader than a technical demonstration.

• Review Cowork's proposed update to product-brief.md.
• Allow Cowork to update the file.
• Ask Cowork to display the newly added headings.

You should see MVP scope, Non-goals, and Proposed success measures beneath the scorecard.

• Ask Cowork to append the governance and production sections using this exact content:

## Governance principles

- Synthetic or approved data only during POC work
- Evidence visible before a decision
- Human approval before consequential action
- Least-privilege access for every future connector
- Audit events for analysis, decision, and downstream action
- Clear owner and rollback trigger for every release

## Proposed production path

1. Replace static sample analysis with a server-side Claude API workflow.
2. Add identity, authorization, retention, evaluation, observability, and cost controls.
3. Introduce MCP connectors one at a time through a connector approval gate.
4. Keep high-impact tools behind explicit human approval.
5. Pilot with a bounded user group before wider rollout.

## Key risks and mitigations

| Risk | Mitigation |
| --- | --- |
| Unsupported recommendation | Require evidence and reviewer confirmation |
| Over-trust in confidence label | Label confidence as directional and measure calibration separately |
| Connector overreach | Use least privilege, explicit consent, and connector review |
| Scope expansion | Maintain MVP non-goals and release gates |
| Low adoption | Co-design with users and track workflow completion plus trust |

How does this complete the decision pack?

The governance principles turn the prototype controls into reusable product rules. The production path separates the future Claude API and MCP architecture from the static POC.

The risk table links each known failure mode to a concrete mitigation. This gives the brief an executive decision structure.

• Review Cowork's final proposed update to product-brief.md.
• Allow Cowork to update the file.
• Ask Cowork to display the complete heading list.

You should see headings for governance principles, the proposed production path, and key risks and mitigations.

Is the product brief missing sections?

Confirm that Cowork is still connected to ~/Documents/claude-enterprise-case. A task connected to another folder cannot update this workspace.

Check whether Cowork is waiting for permission to write the file. Review the proposed action before allowing it.

Ask Cowork to compare the saved file with the supplied template. Help me compare my product brief with the required template.

✔️ Awesome, I've got everything!

Great. Confirm that Cowork has saved product-brief.md inside ~/Documents/claude-enterprise-case.

ⓧ I'd like to double check the full code

# Regulatory Change Copilot Product Brief

## Decision statement

Build a governed POC that helps professionals triage synthetic regulatory updates into reviewable actions. Do not automate downstream changes in the MVP.

## User problem

Professionals must interpret policy changes, identify impacted teams, and coordinate action while preserving evidence, accountability, and review.

## Primary users

- Regulatory analyst who prepares the first impact assessment
- Business owner who accepts or rejects proposed actions
- Risk and compliance reviewer who validates evidence and controls
- Product and technology teams that operate the workflow

## Use-case scorecard

Scores are proposed on a 1 to 5 scale, where 5 is highest.

| Use case | User value | Feasibility | Risk readiness | Decision |
| --- | ---: | ---: | ---: | --- |
| Summarize a bulletin | 4 | 5 | 4 | Include |
| Map affected teams | 5 | 4 | 4 | Include |
| Draft action recommendations | 5 | 4 | 3 | Include with approval |
| Automatically update systems | 4 | 2 | 1 | Exclude from MVP |

## MVP scope

- Accept one synthetic bulletin as text
- Display impacted teams and proposed actions
- Show evidence and a confidence label for each action
- Require a human approve or reject decision
- Record a local demonstration audit event

## Non-goals

- No legal, tax, or regulatory advice
- No live client or firm data
- No external system updates
- No production authentication, authorization, retention, or monitoring
- No claim that prototype confidence labels are calibrated model probabilities

## Proposed success measures

- Decision cycle time from bulletin intake to reviewed action
- Percentage of recommendations accepted without material rewrite
- Percentage of actions with reviewer-confirmed evidence
- Reviewer override and escalation rate
- Weekly active users in the pilot cohort
- User-reported trust and usefulness

## Governance principles

- Synthetic or approved data only during POC work
- Evidence visible before a decision
- Human approval before consequential action
- Least-privilege access for every future connector
- Audit events for analysis, decision, and downstream action
- Clear owner and rollback trigger for every release

## Proposed production path

1. Replace static sample analysis with a server-side Claude API workflow.
2. Add identity, authorization, retention, evaluation, observability, and cost controls.
3. Introduce MCP connectors one at a time through a connector approval gate.
4. Keep high-impact tools behind explicit human approval.
5. Pilot with a bounded user group before wider rollout.

## Key risks and mitigations

| Risk | Mitigation |
| --- | --- |
| Unsupported recommendation | Require evidence and reviewer confirmation |
| Over-trust in confidence label | Label confidence as directional and measure calibration separately |
| Connector overreach | Use least privilege, explicit consent, and connector review |
| Scope expansion | Maintain MVP non-goals and release gates |
| Low adoption | Co-design with users and track workflow completion plus trust |

Compare Cowork's saved product-brief.md with this complete reference. Every heading, score, boundary, measure, governance principle, production step, risk, and mitigation should match.

Create and review the interview brief

The interview brief condenses the case into an executive narrative. It connects the visible trust failure to the governed fix without overstating the static prototype.

• Ask Cowork to create interview-brief.md with this opening content:

# Interview Brief

## 90-second story

I chose regulatory-change triage because it combines visible business value with the controls expected in consequential professional work. I first built a deliberately naive prototype that generated actions without evidence, approval, or audit history. That created the problem before I introduced the solution.

I then added evidence, directional confidence, a human decision gate, and a local audit trail. I treated the POC as a product decision rather than a coding exercise, so I also defined MVP boundaries, excluded automatic system updates, proposed adoption and outcome measures, and mapped delivery across Experience, Intelligence, and Platform and Governance pods.

The prototype is intentionally static and uses synthetic data. My proposed production path moves model calls to a server-side Claude API workflow and introduces MCP connectors only after identity, least privilege, consent, evaluation, monitoring, and rollback controls are ready.

What makes this an executive story?

The narrative starts with business value. It then shows how the naive prototype exposed the trust gap.

The final paragraph preserves the static and synthetic boundaries. It presents the Claude API and MCP as a proposed production path.

• Review Cowork's proposed write to interview-brief.md.
• Allow Cowork to create the file.
• Ask Cowork to display the saved narrative.

You should see three paragraphs under 90-second story. The final paragraph should explicitly describe the prototype as static and synthetic.

• Ask Cowork to append the decision and leadership sections using this exact content:

## Decisions to defend

- Why this use case: high coordination cost, visible user value, and meaningful governance requirements
- Why a naive first version: it makes the trust gap observable rather than theoretical
- Why no automatic updates: the MVP must establish evidence quality and reviewer behavior first
- Why a static POC: it tests workflow and stakeholder alignment without pretending production controls exist
- Why phased connectors: each connector changes the data and action boundary and needs separate approval

## Leadership signals

- Translate business outcomes into a bounded product strategy
- Coordinate product, engineering, risk, security, legal, and operations
- Manage dependencies and release gates across multiple pods
- Use POCs to reduce decision uncertainty
- Measure adoption, value, quality, and risk together

Why make these decisions defendable?

Each decision names a likely interview challenge. The response links the choice to value, governance, or learning.

The leadership signals show coordination across business and control functions. They position the POC as a tool for reducing product uncertainty.

• Review Cowork's proposed update to interview-brief.md.
• Allow Cowork to update the file.
• Ask Cowork to display the newly added headings.

You should see Decisions to defend followed by Leadership signals.

• Ask Cowork to append the interview questions using this exact content:

## Questions for the interview team

1. Which user groups and workflows are the first priority for the Claude Enterprise roadmap?
2. How are product decisions shared across business, technology, security, legal, and risk guardians?
3. Which adoption and value measures matter most today, and where are the measurement gaps?
4. How are connector requests evaluated, approved, monitored, and retired?
5. Where does the role have direct decision authority, and where does it lead through influence?

What do these questions reveal?

The questions probe priorities, decision rights, measurement gaps, and connector governance. They also reveal where the role leads directly or through influence.

• Review Cowork's final proposed update to interview-brief.md.
• Allow Cowork to update the file.
• Ask Cowork to display the complete heading list.

You should see the story, defendable decisions, leadership signals, and five questions in one interview brief.

• Ask Cowork to challenge the 90-second story for executive clarity without editing the file.
• Ask Cowork to flag any sentence that overstates production maturity.
• Check the review against the static-prototype boundary.
• Check the review against the synthetic-data boundary.
• Check the review against the no-external-system boundary.

The review should preserve all three boundaries while testing whether the story makes the product choices easy to defend. Keep the saved template unchanged once those boundaries are confirmed.

Did the review change the prototype boundaries?

Compare the revised story with the supplied template. Restore any sentence that implies live data, calibrated confidence, an external API call, or a downstream system update.

Keep the production path framed as proposed. Help me find overstatements in my interview narrative.

✔️ Awesome, I've got everything!

Excellent. Confirm that Cowork has saved interview-brief.md beside product-brief.md in the controlled workspace.

ⓧ I'd like to double check the full code

# Interview Brief

## 90-second story

I chose regulatory-change triage because it combines visible business value with the controls expected in consequential professional work. I first built a deliberately naive prototype that generated actions without evidence, approval, or audit history. That created the problem before I introduced the solution.

I then added evidence, directional confidence, a human decision gate, and a local audit trail. I treated the POC as a product decision rather than a coding exercise, so I also defined MVP boundaries, excluded automatic system updates, proposed adoption and outcome measures, and mapped delivery across Experience, Intelligence, and Platform and Governance pods.

The prototype is intentionally static and uses synthetic data. My proposed production path moves model calls to a server-side Claude API workflow and introduces MCP connectors only after identity, least privilege, consent, evaluation, monitoring, and rollback controls are ready.

## Decisions to defend

- Why this use case: high coordination cost, visible user value, and meaningful governance requirements
- Why a naive first version: it makes the trust gap observable rather than theoretical
- Why no automatic updates: the MVP must establish evidence quality and reviewer behavior first
- Why a static POC: it tests workflow and stakeholder alignment without pretending production controls exist
- Why phased connectors: each connector changes the data and action boundary and needs separate approval

## Leadership signals

- Translate business outcomes into a bounded product strategy
- Coordinate product, engineering, risk, security, legal, and operations
- Manage dependencies and release gates across multiple pods
- Use POCs to reduce decision uncertainty
- Measure adoption, value, quality, and risk together

## Questions for the interview team

1. Which user groups and workflows are the first priority for the Claude Enterprise roadmap?
2. How are product decisions shared across business, technology, security, legal, and risk guardians?
3. Which adoption and value measures matter most today, and where are the measurement gaps?
4. How are connector requests evaluated, approved, monitored, and retired?
5. Where does the role have direct decision authority, and where does it lead through influence?

Compare Cowork's saved interview-brief.md with this complete reference. The wording should preserve the static prototype, synthetic data, and proposed production path boundaries.

The final check confirms that Cowork created both files in the existing workspace. Before you run it, which two filenames do you expect Terminal to print?

• Switch back to the Terminal window running Claude Code.
• Exit the interactive session by entering this command:

/exit

What does this command do?

This closes the current interactive Claude Code session without deleting files or signing you out. Terminal returns to the existing ~/Documents/claude-enterprise-case shell location.

• Confirm that both decision-pack files exist by running:

ls product-brief.md interview-brief.md

What should I see?

You should see interview-brief.md and product-brief.md in the output. This proves both documents were saved inside the controlled workspace.

Is one of the filenames missing?

Return to Cowork and confirm that the missing file was written to ~/Documents/claude-enterprise-case. A file saved outside that folder does not appear in this check.

Check whether Cowork is still waiting for permission to complete its write. Help me find a missing Cowork output file.

That is the product case elevated beyond a clickable demo. You now have a governed product brief and an executive narrative that preserve the prototype's honest boundaries.

Your decision pack now explains what to build, what to exclude, how to measure progress, and which risks require controls. Next, you'll connect those decisions to a multi-pod enterprise delivery story.

Build the Enterprise Delivery Story

The governed workflow now makes evidence visible. Your product pack explains the decisions behind its human approval gate.

The final gap is execution at scale. This step connects the POC to proposed metrics, delivery pods, release gates, dependencies, and a credible production architecture.

In this step, get ready to:

• Ground the final prototype in your product brief and interview narrative.
• Add Product Strategy and Delivery Plan views to the governed workflow.
• Rehearse the complete enterprise product story from problem to production path.

Ground the update in your decision pack

The two briefs are the approved source for the final case. Reading them first keeps the prototype aligned with the decisions you already documented.

• Switch back to the existing Claude Code session in ~/Documents/claude-enterprise-case.
• Ask Claude Code to read product-brief.md before changing the prototype.
• Ask Claude Code to read interview-brief.md before changing the prototype.
• Ask for a short summary of the requested change.
• Ask for the product risk addressed by the change.
• Review the summary before authorizing the update to index.html.

What Should the Summary Preserve?

• The workflow uses synthetic data only.
• The POC remains static.
• The POC remains dependency-free.
• The MVP excludes automatic external-system updates.
• The future production path adds identity controls.
• The future production path adds evaluation controls.
• The future production path adds monitoring controls.
• The future production path adds rollback controls.

Claude Code should describe the update as a product decision. Its summary should identify the risk of presenting a static demonstration as production software.

Expand the prototype into the final case

The final page supports three parts of one leadership story. The governed workflow proves the interaction.

The new views explain the product decisions. They also show how a controlled pilot could be delivered.

Final Prototype Acceptance Criteria

• The Governed Workflow tab preserves bulletin.
• The Governed Workflow tab preserves analyzeButton.
• The Governed Workflow tab preserves approveButton.
• The Governed Workflow tab preserves rejectButton.
• The Governed Workflow tab preserves decisionStatus.
• The Governed Workflow tab preserves auditList.
• The Product Strategy tab shows the proposed scorecard decisions.
• The Product Strategy tab shows the proposed success measures.
• The Product Strategy tab shows the MVP boundaries.
• The Product Strategy tab shows the explicit non-goals.
• The Delivery Plan tab shows the proposed 90-day roadmap.
• The Delivery Plan tab shows pod ownership.
• The Delivery Plan tab shows dependencies.
• The Delivery Plan tab shows release gates.
• The production blueprint includes a product service.
• The production blueprint includes a server-side Claude API workflow.
• The production blueprint places approved least-privilege MCP connectors behind governance controls.
• The page states that the local POC has no external API access.
• The page states that the local POC has no MCP server access.
• The page states that the local POC has no external-system access.

• Ask Claude Code to update index.html against the acceptance criteria.
• Require Claude Code to preserve the existing governed workflow behavior.
• Require Claude Code to use the documented briefs as the source for strategy content.
• Require Claude Code to use the documented briefs as the source for delivery content.
• Require Claude Code to match the final index.html shown in the full-code reference below.
• Review Claude Code's post-edit verification summary.
• Switch back to the existing local page in Safari.
• Reload the page to display the updated index.html.

You should see three tabs across the page header. The new strategy view makes the product decisions visible.

The new delivery view makes ownership visible. It also surfaces the dependencies behind the proposed pilot.

Missing a Tab or Workflow Control?

Return to Claude Code if either new tab is missing. Ask it to compare index.html with the acceptance criteria before making another edit.

If the governed workflow no longer responds, ask Claude Code to restore the existing IDs from the previous milestone. Ask it to restore the existing event listeners too.

Help me diagnose a missing tab or broken interaction in the final Regulatory Change Copilot prototype.

✔️ Awesome, I've got everything!

The final page is ready. Double-check that index.html is saved before rehearsing the case.

ⓧ I'd like to double check the full code

Compare your final index.html with this complete reference.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Regulatory Change Copilot</title>
  <style>
    :root {
      --ink: #172033;
      --muted: #5b6578;
      --panel: #ffffff;
      --page: #f3f6fb;
      --brand: #3548c8;
      --brand-dark: #24359e;
      --good: #176b45;
      --good-bg: #e8f7ef;
      --warn: #8a5200;
      --warn-bg: #fff4d6;
      --bad: #a12b2b;
      --bad-bg: #fdeaea;
      --line: #d8deea;
      --shadow: 0 14px 34px rgba(23, 32, 51, 0.09);
    }

    * { box-sizing: border-box; }

    body {
      margin: 0;
      background: var(--page);
      color: var(--ink);
      font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
      line-height: 1.5;
    }

    button, textarea { font: inherit; }

    header {
      color: white;
      background: linear-gradient(125deg, #1f2c74, #5366de);
      padding: 34px 20px 24px;
    }

    header .wrap, main { max-width: 1120px; margin: 0 auto; }
    h1 { margin: 0 0 8px; font-size: clamp(1.9rem, 4vw, 3rem); }
    h2 { margin-top: 0; }
    h3 { margin-bottom: 8px; }
    p { margin-top: 0; }
    .subtitle { max-width: 780px; margin: 0; color: #e4e8ff; }

    .prototype-label {
      display: inline-block;
      margin-top: 16px;
      padding: 5px 10px;
      border: 1px solid rgba(255,255,255,.45);
      border-radius: 999px;
      font-size: .85rem;
    }

    nav {
      display: flex;
      gap: 8px;
      flex-wrap: wrap;
      margin-top: 22px;
    }

    .tab-button {
      border: 1px solid rgba(255,255,255,.5);
      background: rgba(255,255,255,.12);
      color: white;
      border-radius: 9px;
      padding: 10px 14px;
      cursor: pointer;
    }

    .tab-button.active {
      background: white;
      color: var(--brand-dark);
    }

    main { padding: 24px 20px 50px; }
    .tab-panel[hidden] { display: none; }

    .grid {
      display: grid;
      grid-template-columns: repeat(12, 1fr);
      gap: 16px;
    }

    .card {
      grid-column: span 12;
      background: var(--panel);
      border: 1px solid var(--line);
      border-radius: 14px;
      padding: 20px;
      box-shadow: var(--shadow);
    }

    .half { grid-column: span 6; }
    .third { grid-column: span 4; }

    @media (max-width: 800px) {
      .half, .third { grid-column: span 12; }
    }

    label { display: block; font-weight: 700; margin-bottom: 8px; }

    textarea {
      width: 100%;
      min-height: 160px;
      resize: vertical;
      padding: 12px;
      border: 1px solid #aeb8ca;
      border-radius: 9px;
      color: var(--ink);
      background: #fbfcff;
    }

    .button-row { display: flex; flex-wrap: wrap; gap: 10px; margin-top: 14px; }

    .primary, .approve, .reject {
      border: 0;
      border-radius: 9px;
      padding: 11px 15px;
      cursor: pointer;
      font-weight: 700;
    }

    .primary { background: var(--brand); color: white; }
    .primary:hover { background: var(--brand-dark); }
    .approve { background: var(--good); color: white; }
    .reject { background: var(--bad); color: white; }
    button:disabled { opacity: .45; cursor: not-allowed; }

    .notice {
      border-left: 5px solid var(--warn);
      background: var(--warn-bg);
      padding: 14px;
      border-radius: 8px;
      margin-bottom: 16px;
    }

    .status {
      display: inline-block;
      padding: 5px 10px;
      border-radius: 999px;
      font-weight: 700;
      background: #e9edff;
      color: var(--brand-dark);
    }

    .recommendation {
      border: 1px solid var(--line);
      border-radius: 10px;
      padding: 14px;
      margin-top: 12px;
    }

    .meta { display: flex; gap: 8px; flex-wrap: wrap; margin: 9px 0; }
    .chip { border-radius: 999px; padding: 4px 9px; font-size: .82rem; background: #edf0f7; }
    .evidence { background: #f6f8fc; border-left: 4px solid var(--brand); padding: 10px; }
    .muted { color: var(--muted); }

    table { width: 100%; border-collapse: collapse; }
    th, td { padding: 11px; border-bottom: 1px solid var(--line); text-align: left; vertical-align: top; }
    th { background: #f4f6fb; }

    .metric { font-size: 1.6rem; font-weight: 800; color: var(--brand-dark); }
    .metric-label { color: var(--muted); }

    .phase {
      border-top: 5px solid var(--brand);
      min-height: 190px;
    }

    .architecture {
      display: flex;
      align-items: stretch;
      gap: 10px;
      flex-wrap: wrap;
    }

    .architecture-box {
      flex: 1 1 180px;
      border: 1px solid var(--line);
      border-radius: 10px;
      padding: 13px;
      background: #f9faff;
    }

    .arrow { align-self: center; font-weight: 800; color: var(--brand); }
    .audit-list { padding-left: 22px; }
    .audit-list li { margin-bottom: 7px; }
    .good { color: var(--good); }
    .bad { color: var(--bad); }
  </style>
</head>
<body>
  <header>
    <div class="wrap">
      <h1>Regulatory Change Copilot</h1>
      <p class="subtitle">A governed product concept for turning synthetic regulatory updates into evidence-backed, human-reviewed actions.</p>
      <span class="prototype-label">Static POC with synthetic data and no external system access</span>
      <nav aria-label="Product case sections">
        <button class="tab-button active" data-tab="workflow">Governed Workflow</button>
        <button class="tab-button" data-tab="strategy">Product Strategy</button>
        <button class="tab-button" data-tab="delivery">Delivery Plan</button>
      </nav>
    </div>
  </header>

  <main>
    <section id="workflow" class="tab-panel">
      <div class="notice">
        <strong>Designed obstacle:</strong> The first prototype produced plausible actions with no evidence, confidence, approval, or audit history. This final workflow makes those controls visible.
      </div>

      <div class="grid">
        <article class="card half">
          <h2>1. Review the synthetic bulletin</h2>
          <label for="bulletin">Synthetic regulatory bulletin</label>
          <textarea id="bulletin">Fictional Bulletin RC-24-07: Beginning next quarter, covered business units must document the source, owner, and review date for every automated regulatory impact assessment. Material actions require approval from an accountable business owner before downstream systems are updated. Records must be available for internal review.</textarea>
          <div class="button-row">
            <button id="analyzeButton" class="primary">Analyze Bulletin</button>
          </div>
          <p class="muted">This demonstration does not provide legal, tax, or regulatory advice.</p>
        </article>

        <article class="card half">
          <h2>2. Human decision gate</h2>
          <p>Current status: <span id="decisionStatus" class="status">Waiting for analysis</span></p>
          <p>The prototype cannot update any external system. These controls only demonstrate the intended review experience.</p>
          <div class="button-row">
            <button id="approveButton" class="approve" disabled>Approve Recommendation</button>
            <button id="rejectButton" class="reject" disabled>Reject for Review</button>
          </div>
        </article>

        <article id="results" class="card" hidden>
          <h2>3. Evidence-backed impact assessment</h2>

          <div class="recommendation">
            <h3>Create an assessment evidence record</h3>
            <div class="meta">
              <span class="chip">Affected team: Regulatory Operations</span>
              <span class="chip">Directional confidence: High</span>
            </div>
            <p>Proposed action: Add source, owner, and review-date fields to the assessment workflow.</p>
            <p class="evidence"><strong>Evidence:</strong> "must document the source, owner, and review date for every automated regulatory impact assessment"</p>
          </div>

          <div class="recommendation">
            <h3>Add an accountable-owner approval step</h3>
            <div class="meta">
              <span class="chip">Affected team: Business Control</span>
              <span class="chip">Directional confidence: High</span>
            </div>
            <p>Proposed action: Require a named business owner to approve material actions before execution.</p>
            <p class="evidence"><strong>Evidence:</strong> "Material actions require approval from an accountable business owner"</p>
          </div>

          <div class="recommendation">
            <h3>Define review access and retention requirements</h3>
            <div class="meta">
              <span class="chip">Affected team: Platform and Governance</span>
              <span class="chip">Directional confidence: Medium</span>
            </div>
            <p>Proposed action: Confirm who can review records and how long the organization should retain them.</p>
            <p class="evidence"><strong>Evidence:</strong> "Records must be available for internal review." The bulletin does not specify access roles or retention length, so clarification is required.</p>
          </div>
        </article>

        <article class="card">
          <h2>4. Demonstration audit trail</h2>
          <ol id="auditList" class="audit-list">
            <li>Prototype loaded with synthetic data. No analysis performed.</li>
          </ol>
        </article>
      </div>
    </section>

    <section id="strategy" class="tab-panel" hidden>
      <div class="grid">
        <article class="card">
          <h2>Product decision</h2>
          <p>Build a governed POC that helps professionals triage synthetic regulatory updates into reviewable actions. Do not automate downstream changes in the MVP.</p>
        </article>

        <article class="card">
          <h2>Proposed use-case scorecard</h2>
          <table>
            <thead>
              <tr><th>Use case</th><th>Value</th><th>Feasibility</th><th>Risk readiness</th><th>Decision</th></tr>
            </thead>
            <tbody>
              <tr><td>Summarize a bulletin</td><td>4</td><td>5</td><td>4</td><td>Include</td></tr>
              <tr><td>Map affected teams</td><td>5</td><td>4</td><td>4</td><td>Include</td></tr>
              <tr><td>Draft actions</td><td>5</td><td>4</td><td>3</td><td>Include with approval</td></tr>
              <tr><td>Update systems automatically</td><td>4</td><td>2</td><td>1</td><td>Exclude from MVP</td></tr>
            </tbody>
          </table>
          <p class="muted">All scores are proposed product assumptions for interview discussion.</p>
        </article>

        <article class="card third">
          <div class="metric">Cycle time</div>
          <div class="metric-label">Measure intake to reviewed action</div>
        </article>
        <article class="card third">
          <div class="metric">Acceptance</div>
          <div class="metric-label">Track material rewrites and overrides</div>
        </article>
        <article class="card third">
          <div class="metric">Trust</div>
          <div class="metric-label">Measure evidence confirmation and user confidence</div>
        </article>

        <article class="card half">
          <h2>MVP boundaries</h2>
          <ul>
            <li>One synthetic bulletin as text</li>
            <li>Evidence and directional confidence</li>
            <li>Human approve or reject decision</li>
            <li>Local demonstration audit history</li>
          </ul>
        </article>

        <article class="card half">
          <h2>Explicit non-goals</h2>
          <ul>
            <li>No professional advice</li>
            <li>No confidential or live enterprise data</li>
            <li>No external system updates</li>
            <li>No claim of production security or calibrated probability</li>
          </ul>
        </article>
      </div>
    </section>

    <section id="delivery" class="tab-panel" hidden>
      <div class="grid">
        <article class="card third phase">
          <h2>Days 0 to 30</h2>
          <h3>Prove the workflow</h3>
          <ul>
            <li>Interview pilot users</li>
            <li>Validate evidence display</li>
            <li>Baseline cycle time</li>
            <li>Agree on MVP non-goals</li>
          </ul>
        </article>

        <article class="card third phase">
          <h2>Days 31 to 60</h2>
          <h3>Build the controlled pilot</h3>
          <ul>
            <li>Add server-side Claude API workflow</li>
            <li>Implement identity and audit events</li>
            <li>Run quality and risk evaluations</li>
            <li>Train a bounded pilot cohort</li>
          </ul>
        </article>

        <article class="card third phase">
          <h2>Days 61 to 90</h2>
          <h3>Measure and decide</h3>
          <ul>
            <li>Review value, adoption, and risk</li>
            <li>Resolve the highest-severity gaps</li>
            <li>Assess the first MCP connector</li>
            <li>Make scale, iterate, or stop decision</li>
          </ul>
        </article>

        <article class="card">
          <h2>Pod ownership and dependencies</h2>
          <table>
            <thead><tr><th>Pod</th><th>Primary outcome</th><th>Key dependency</th></tr></thead>
            <tbody>
              <tr><td>Experience</td><td>Reviewable workflow and adoption journey</td><td>User research and policy-owner availability</td></tr>
              <tr><td>Intelligence</td><td>Prompt, evidence, quality evaluation, and failure handling</td><td>Approved test set and decision rubric</td></tr>
              <tr><td>Platform and Governance</td><td>Identity, auditability, data controls, monitoring, and connector gate</td><td>Security, legal, risk, and architecture decisions</td></tr>
            </tbody>
          </table>
        </article>

        <article class="card">
          <h2>Proposed production architecture</h2>
          <div class="architecture" aria-label="Proposed architecture flow">
            <div class="architecture-box"><strong>User experience</strong><br>Intake, evidence review, decision</div>
            <div class="arrow">to</div>
            <div class="architecture-box"><strong>Product service</strong><br>Identity, policy, orchestration, audit</div>
            <div class="arrow">to</div>
            <div class="architecture-box"><strong>Claude API</strong><br>Server-side analysis and structured response</div>
            <div class="arrow">to</div>
            <div class="architecture-box"><strong>Approved MCP connectors</strong><br>Least-privilege resources and tools</div>
          </div>
          <p class="muted">This is a proposed production blueprint. The local POC does not call the Claude API or connect to an MCP server.</p>
        </article>

        <article class="card half">
          <h2>Release gates</h2>
          <ul>
            <li>Evidence quality meets the agreed review rubric</li>
            <li>High-impact actions require explicit approval</li>
            <li>Security and risk owners accept the control design</li>
            <li>Rollback owner and trigger are documented</li>
          </ul>
        </article>

        <article class="card half">
          <h2>Executive decision</h2>
          <p>Scale only when user value, workflow quality, adoption, and control effectiveness improve together. A successful technical demo alone is not a release decision.</p>
        </article>
      </div>
    </section>
  </main>

  <script>
    const tabButtons = document.querySelectorAll(".tab-button");
    const tabPanels = document.querySelectorAll(".tab-panel");
    const analyzeButton = document.getElementById("analyzeButton");
    const approveButton = document.getElementById("approveButton");
    const rejectButton = document.getElementById("rejectButton");
    const results = document.getElementById("results");
    const decisionStatus = document.getElementById("decisionStatus");
    const auditList = document.getElementById("auditList");
    const bulletin = document.getElementById("bulletin");

    function activateTab(tabId) {
      tabButtons.forEach((button) => {
        button.classList.toggle("active", button.dataset.tab === tabId);
      });

      tabPanels.forEach((panel) => {
        panel.hidden = panel.id !== tabId;
      });
    }

    function addAuditEvent(message) {
      const item = document.createElement("li");
      item.textContent = `${new Date().toLocaleTimeString()}: ${message}`;
      auditList.appendChild(item);
    }

    tabButtons.forEach((button) => {
      button.addEventListener("click", () => activateTab(button.dataset.tab));
    });

    analyzeButton.addEventListener("click", () => {
      if (!bulletin.value.trim()) {
        window.alert("Add a synthetic bulletin before running the analysis.");
        return;
      }

      results.hidden = false;
      approveButton.disabled = false;
      rejectButton.disabled = false;
      decisionStatus.textContent = "Awaiting human decision";
      decisionStatus.className = "status";
      addAuditEvent("Synthetic bulletin analyzed. Three proposed actions await human review.");
      results.scrollIntoView({ behavior: "smooth", block: "start" });
    });

    approveButton.addEventListener("click", () => {
      decisionStatus.textContent = "Approved for controlled follow-up";
      decisionStatus.className = "status good";
      approveButton.disabled = true;
      rejectButton.disabled = true;
      addAuditEvent("Human reviewer approved the recommendation for controlled follow-up. No external action was taken.");
    });

    rejectButton.addEventListener("click", () => {
      decisionStatus.textContent = "Rejected for further review";
      decisionStatus.className = "status bad";
      approveButton.disabled = true;
      rejectButton.disabled = true;
      addAuditEvent("Human reviewer rejected the recommendation and requested further review. No external action was taken.");
    });
  </script>
</body>
</html>

This reference preserves the governed interaction from the previous milestone. It adds the strategy and delivery views without introducing an external integration.

Rehearse the complete enterprise story

A strong demonstration links each screen to a product decision. Your rehearsal starts with the visible trust gap.

It continues through the governed workflow. It finishes with the controlled production path.

Before you test the complete case, which parts of the page do you expect to prove product value, governance, and delivery readiness?

• Reload the local page in Safari.
• Select Governed Workflow.
• Select Analyze Bulletin.
• Review the evidence on all three recommendations.
• Review the directional confidence on all three recommendations.
• Select Approve Recommendation.
• Confirm that the decision status records controlled follow-up.
• Confirm that the audit trail states no external action was taken.

You should see three recommendations with evidence. Each recommendation should include a directional confidence label.

Both decision controls should become disabled after approval. A local audit event should record the human decision.

• Select Product Strategy.
• Explain why automatic system updates are excluded from the MVP.
• Explain how cycle time measures product value.
• Explain how acceptance measures recommendation quality.
• Explain how trust measures reviewer confidence.
• Select Delivery Plan.
• Explain the outcome owned by the Experience pod.
• Explain the outcome owned by the Intelligence pod.

• Explain the outcome owned by the Platform and Governance pod.
• Review the dependencies for each pod.
• Review the three roadmap phases.
• Review the release gates.
• Close with the proposed production architecture.

You should see all three roadmap phases. You should also see the pod dependency table.

The architecture should move from the user experience to approved least-privilege MCP connectors. The release gates should keep high-impact actions behind explicit approval.

Keep the Production Boundary Clear

The local prototype demonstrates workflow behavior with synthetic data. It has no API key.

It has no cloud deployment. It has no external connector.

The Claude API and MCP connectors belong to the proposed production architecture. Those future components require identity, consent, evaluation, monitoring, and rollback controls.

Strong finish. Your browser case now connects the governed workflow to product strategy and delivery leadership.

You can now explain the production path without overstating the local POC. Next up, an optional Secret Mission lets you apply that governance thinking to a connector decision.

Secret mission

Design the MCP Connector Approval Gate

Turn the proposed connector gate into a defensible product decision. You will assess a fictional Regulatory Evidence Repository MCP Connector, use Cowork to challenge its highest-risk capability, and finish with a Conditional Go decision for a bounded synthetic-data pilot.

Clean Up Your Resources

Clean Up Your Resources

Everything in this project runs locally on your Mac. There are no ongoing cloud costs or billable resources to clean up.

Choose whether to keep the case ready for interview rehearsal, pause your active tools, or remove the local workspace.

Resources you used:

• The local ~/Documents/claude-enterprise-case folder stores CLAUDE.md, index.html, product-brief.md, interview-brief.md, and connector-approval.md.
• The working-folder reference in Claude Cowork points to ~/Documents/claude-enterprise-case.

Keep everything running

Keep the case intact if you plan to rehearse your interview story or refine the product decisions. No cleanup action is required.

• Leave ~/Documents/claude-enterprise-case in your Documents folder.
• Retain the connected folder in Claude Cowork for future critical reviews.
• Keep Claude Code installed for future projects.

Pause - I'll come back to this later

Pause the active tools when you want to free up your screen without removing the case. Your files and Cowork working-folder reference remain available.

• Inside the Claude Code session from earlier, end the interactive session by entering:

/exit

What does this command do?

The command closes the interactive Claude Code session while preserving every project file.

• Close Safari.

Delete - I don't want to use this again

Remove the local case if you want a clean slate. This is the only destructive option.

Your existing Claude Pro subscription stays active. No real MCP connector exists to revoke.

• End any active Claude Code session by entering:

/exit

What does this command do?

The command closes Claude Code before you remove its local workspace.

• Close Safari.
• In the Claude Cowork task from earlier, disconnect ~/Documents/claude-enterprise-case from the task's working folders.
• Confirm the folder path no longer appears in the Cowork task.
• Use the file browser on your Mac to open ~/Documents.
• Control-click the claude-enterprise-case folder.
• Select Move to Trash.
• Confirm ~/Documents/claude-enterprise-case no longer appears in your Documents folder.

Nice Work!

Nice Work!

You did it! Your Regulatory Change Copilot is now an interview-ready enterprise product case with visible evidence plus human accountability.

What you learned:

• Made the trust gap visible through a deliberately naive prototype. Evidence-backed actions now pass through a human decision gate with local audit history.
• Created a product decision pack with scored use cases plus clear MVP boundaries. The pack links product priorities to proposed measures plus explicit non-goals.
• Connected a 90-day multi-pod roadmap to a proposed production blueprint using the Claude API plus governed Model Context Protocol connectors.
• Completed the Secret Mission with a Conditional Go decision for the Regulatory Evidence Repository MCP Connector. The assessment supports least privilege through explicit consent plus a monitored rollback gate.

Ready to quiz yourself?