Build a Controlled Customer-Specific Demo With Codex: Authorized Call Notes, Email Context, Spreadsheets, HTML Prototypes, and Engineering Handoff

What this tutorial builds—and what it deliberately does not build

This tutorial shows a controlled way to convert authorized discovery material into a customer-specific HTML demo prototype with Codex support. The workflow is inspired by OpenAI’s Proaction customer story, where OpenAI reports that Proaction uses Codex to turn authorized customer context—such as a Granola call recording, prospect email threads, and customer-shared spreadsheets—into a customized HTML demo environment reflecting a prospect’s vehicles and workflows. In this tutorial, the output is a local, non-production prototype package and an engineering-owned handoff, not a live customer system, not a production integration, and not an automated sales machine.

OpenAI’s Proaction story attributes several operating metrics to Colin Knudsen and Proaction: four to six customized demos per month, a 30–45-minute build estimate per demo, an estimated 40–60 engineering hours avoided monthly, and an estimated 50%–60% increase in deals moving from initial contact to solution development rather than nurture. Treat those as source-reported customer-story figures, not benchmarks, guarantees, or expected results for your organization. Your results will depend on the quality of your discovery process, the sensitivity of your data, the maturity of your product surface, the review discipline of your team, and the workspace, account, app, and approval settings available to you.

The method below is intentionally conservative. It assumes that customer-specific context can create real business value, but also real privacy, security, legal, and trust risks if handled casually. The core rule is simple: use only material you are authorized to use, reduce it to the minimum necessary, redact or synthesize whenever possible, isolate the prototype from production systems, require human review before anyone sees the demo, and make engineering—not a model—the owner of what becomes a product requirement.

This guide covers security and privacy considerations for ChatGPT Sites, including access controls, secrets, data residency, and safe publishing boundaries for interactive AI-generated web outputs. The ChatGPT Sites Security and Privacy Guide: Access Controls, Secrets, Data Residency, and Safe Publishing article is a focused companion for Privacy Safe Customer Discovery because a customer-specific Codex demo that uses call notes, email context, spreadsheets, and HTML prototypes needs closely related privacy and publishing guardrails; this target is more directly useful than broader privacy or customer-service posts.

The documented inspiration: Proaction’s Codex demo workflow

OpenAI describes Proaction as using Codex in a sales and product workflow where prospect-specific context is transformed into customized demo environments. The source example is concrete: customer context can include a Granola call recording, prospect email threads, and customer-shared spreadsheets, and the resulting demo can reflect a prospect’s vehicles and workflows. This matters because it grounds the tutorial in a documented pattern: a team is not merely asking a model to “make a demo,” but is assembling a structured context packet from specific authorized sources and using that packet to create an artifact that helps a buyer understand a workflow.

The same OpenAI story reports that Proaction creates four to six customized demos per month and that each demo takes about 30–45 minutes to build in the described workflow. OpenAI further attributes to Proaction an estimate of 40–60 engineering hours avoided monthly and a 50%–60% increase in deals moving from initial contact to solution development rather than nurture. These figures are useful as a reference point for why teams are interested in customer-specific prototypes, but they should not be copied into your internal business case as assumed ROI. They are reported outcomes from one customer story, and they do not establish causation, statistical significance, or transferability.

The operational lesson is narrower and more practical: if your sales, solutions, or product team repeatedly creates bespoke demos, Codex can help assemble interface prototypes, mock data, workflow screens, and handoff notes from a controlled context packet. The safe version of this process does not grant Codex broad access to your customer systems, does not let it send emails or update CRM records automatically, and does not let a demo artifact become production code without review. It creates a controlled bridge between discovery and engineering, with approval gates at each step.

Who should use this workflow

This tutorial is designed for teams that already have a legitimate customer-discovery motion and want to make demos more specific without compromising trust. A founder might use it to turn a prospect call into a credible workflow mockup before a second meeting. A solutions engineer might use it to model a customer’s spreadsheet-driven process inside a prototype screen. A product manager might use it to convert repeated sales findings into engineering-ready requirements. A security administrator might use it to define the permissions, isolation, and review controls that prevent a prototype process from becoming an unmanaged data pipeline.

The workflow also applies to enterprise knowledge workers who use ChatGPT, Codex, or connected apps inside a governed workspace. OpenAI’s plugin documentation says plugins can package skills, connected apps, and templates, but installing a plugin does not bypass provider authorization or workspace permissions. That boundary is essential: a connected app should not be treated as a permission shortcut, and a model should not be treated as an account owner. Access remains subject to the relevant provider account, role, supported actions, approval requirements, domains, sync behavior, source restrictions, and workspace policy.

Advanced Codex users should treat the prototype as a generated artifact inside a controlled software-development process. OpenAI’s Codex security documentation distinguishes sandbox mode and approval policy as separate layers, and notes that local workspace-write mode defaults to no network access. This tutorial uses that separation as an operating principle: file access, network access, command execution, and human approval should be configured deliberately rather than assumed safe because the task is “only a demo.”

This article explains how to configure Codex auto-review mode and sandbox rules for secure AI-assisted development, including sandboxing, network policies, and identity management. The How to Configure Codex Auto-Review Mode and Sandbox Rules for Secure AI-Assisted Development article is a focused companion for Codex Sandbox Permissions because the marker is specifically about Codex sandbox permissions, and this post directly addresses Codex sandbox rules and secure configuration rather than general Codex release or entitlement troubleshooting.

The non-negotiable safety contract

Before you collect a single call note or spreadsheet, define a written safety contract for the demo build. The contract does not need to be lengthy, but it must be explicit enough that a sales teammate, engineer, administrator, and reviewer can tell what is allowed. At minimum, the contract should name the customer or prospect, the authorized source materials, the demo objective, the excluded data categories, the allowed output format, the review owner, and the rule that no external communication, production write, deployment, CRM update, payment, purchase, booking, legal commitment, or permission change may occur without an authorized human.

The strongest default is to work from redacted or synthetic material rather than raw customer data. If the prospect shared a spreadsheet with 2,000 rows of vehicle records, you usually do not need all 2,000 rows to build a demo. You may need the column structure, three representative examples, a few realistic workflow states, and a note explaining which values were synthesized. If a call transcript includes names, phone numbers, exact addresses, payment details, health information, employment details, or other personal or regulated information, remove it unless there is a documented, necessary, authorized reason to keep it—and even then, consider substituting synthetic values.

Do not include secrets, production credentials, private keys, API tokens, session cookies, regulated data, unapproved recordings, privileged material, or confidential customer material that you are not authorized to process. If a customer shared sensitive material for one purpose, do not silently repurpose it for a demo. If the authorization is unclear, pause the build and obtain written confirmation through your normal business process. A useful demo never justifies violating customer expectations or workspace policy.

Operational rule: A customer-specific demo should be specific in workflow, terminology, and business context—not in unnecessary exposure of real people, secrets, regulated records, or production systems.

The controlled-demo architecture in plain terms

The recommended architecture is a one-way path from authorized context to an isolated prototype and then to an engineering handoff. Context flows in only after permission and minimization. Codex helps generate local HTML, CSS, JavaScript, copy, tables, mock data, and developer notes. Reviewers inspect the output against a source ledger and a safety checklist. The customer-facing session uses a reviewed static or isolated demo artifact. Engineering later decides what, if anything, becomes a real backlog item, implementation spike, integration, or production feature.

The architecture deliberately avoids production writes. The prototype should not connect to live customer systems, internal billing systems, production databases, messaging systems, fleet telematics accounts, CRM automation, or deployment pipelines. If you need to show how an integration would work, represent it with mocked payloads, static JSON, screenshots approved for use, or synthetic records. If you need to demonstrate a workflow state change, implement it locally in the prototype rather than writing to a real system.

For many teams, the simplest implementation is a local project folder containing a source ledger, a redacted-context folder, a static prototype, and a handoff document. Codex can help draft and revise these files, but your team controls what enters the folder and what leaves it. If your organization uses stricter development environments, adapt the same pattern to your approved workspace, repository policy, and review process.

Inputs: call notes, email context, and spreadsheets without over-collection

The Proaction story mentions a Granola call recording, prospect email threads, and customer-shared spreadsheets as examples of customer context. In your version, those categories should be treated as possible inputs, not automatic entitlements. A call note may be enough if it captures the workflow and pain points. An email thread may be useful if it contains written requirements or constraints. A spreadsheet may be useful if it describes entities, statuses, calculations, or operational categories. None of those sources should be copied wholesale into a model or workspace just because they exist.

For call material, prefer a concise authorized summary over a raw recording or full transcript. Include the customer’s stated objective, the current workflow, the relevant roles, key terminology, objections, success criteria, and explicit permission boundaries. Remove names of individuals unless necessary for role simulation, and replace them with role labels such as “dispatcher,” “fleet manager,” or “maintenance coordinator.” If a recording was not approved for this use, do not use it; instead, rely on authorized notes or ask for permission through the appropriate channel.

For email context, extract only the requirements and constraints needed for the demo. A safe email digest might include “Prospect wants to see exception alerts for vehicles overdue for inspection,” “Spreadsheet contains vehicle ID, depot, last inspection date, and status,” and “Customer asked not to include driver names in demo materials.” It should not include the entire thread, signature blocks, direct contact details, contractual terms unrelated to the prototype, or confidential negotiation content unless explicitly authorized and necessary.

For spreadsheets, separate structure from sensitive contents. Often, the column names, data types, and a handful of synthetic rows are sufficient. If the demo needs to show a dashboard for vehicles, create fictitious vehicle IDs and locations. If the spreadsheet includes financial amounts, driver details, accident records, health-related information, or other sensitive categories, either remove them or obtain formal approval and apply stronger controls. When in doubt, synthesize.

Output: a prototype plus a source-led handoff

The primary output is a small HTML prototype that demonstrates the customer’s workflow. It may include screens such as a dashboard, detail view, exception queue, upload preview, workflow checklist, or manager summary. The prototype should be clearly labeled as a non-production mockup, and its data should be either synthetic or redacted. If it uses customer terminology, preserve the meaning but avoid unnecessary identifiers. If it includes metrics, calculations, statuses, or recommendations, mark them as illustrative unless they are verified against authorized source material.

The second output is more important for long-term value: an engineering handoff that explains what the prototype represents. The handoff should include the source ledger, assumptions, redactions, synthetic-data notes, open questions, customer success criteria, implementation risks, integration dependencies, and decisions that require engineering review. This keeps the demo from becoming a misleading artifact. Engineers should be able to distinguish “customer explicitly asked for this,” “sales inferred this,” “Codex generated this as a design suggestion,” and “reviewer validated this against source context.”

The handoff should also document what was intentionally excluded. Exclusions are not bureaucracy; they protect scope and trust. Examples include “No production telematics integration,” “No driver personal data,” “No automatic email notifications,” “No claims about regulatory compliance,” and “No pricing, contractual, or service-level commitments.” If the customer asks for one of those during the demo, the presenter should capture it as a follow-up question rather than improvise a commitment.

Roles and approval gates

A controlled demo workflow works best when roles are explicit. The account owner or customer-facing lead confirms authorization and demo goals. The context preparer redacts, summarizes, and synthesizes input material. The Codex operator builds the prototype inside the approved workspace. The reviewer checks privacy, security, accuracy, and customer readiness. Engineering owns the final interpretation of requirements and decides whether the prototype becomes a backlog item, a spike, a design exploration, or no action.

The same person may perform more than one role in a small startup, but the approval gates should still exist. A founder can prepare context and operate Codex, but should still perform a separate review pass before showing the artifact. A solutions engineer can build the prototype, but should not represent generated behavior as a committed feature without product and engineering approval. An administrator can approve connected-app access, but should not approve customer data use unless that falls within their actual authority and company policy.

The operating posture for Codex in this tutorial

OpenAI’s Codex CLI documentation identifies Codex as a coding agent developers can use from the command line, while OpenAI’s Codex approvals and security guidance emphasizes sandboxing and approval policies as controls around agent activity. For this tutorial, the practical posture is to keep Codex close to the local prototype files and far away from production systems. The model may help create HTML, CSS, JavaScript, mock JSON, test notes, and requirements summaries. It should not receive credentials, perform deployments, merge pull requests, update customer records, or communicate externally.

OpenAI’s safety best-practices guidance supports conservative patterns such as constraining inputs, applying human-in-the-loop review for high-stakes work, and designing systems so consequential outputs are checked before action. A customer-specific demo is not always “high stakes” in the same way as legal, medical, or financial decision-making, but it can still create consequential commercial, privacy, and trust effects. A polished prototype can imply product maturity, integration availability, or implementation commitments that do not exist. Human review is therefore not optional.

The recommended Codex task boundary is narrow: “Create a local static prototype from this redacted context packet and produce a handoff document listing assumptions, source references, exclusions, and engineering questions.” That boundary keeps the agent focused on artifact generation rather than business action. If the workflow requires connected apps or plugins, treat them as governed access mechanisms, not as blanket permission. OpenAI’s plugin documentation states that plugins can package skills, connected apps, and templates, and that provider authorization and workspace permissions still apply.

Sample project structure for the opening build

A disciplined folder structure makes the workflow easier to audit. The structure below is an example, not a requirement. Adapt it to your organization’s approved repository, document-management, and retention policies. The important point is separation: raw or sensitive material should not be mixed with generated prototype code, and the final handoff should clearly identify what sources were used.

customer-demo-prototype/
  README.md
  context/
    source-ledger.md
    redacted-call-summary.md
    email-requirements-digest.md
    spreadsheet-schema.md
    synthetic-demo-data.json
    redaction-log.md
  prototype/
    index.html
    styles.css
    app.js
    demo-data.json
  review/
    privacy-security-checklist.md
    accuracy-review-notes.md
    customer-session-script.md
  handoff/
    engineering-brief.md
    assumptions-register.md
    open-questions.md
    excluded-items.md

The context folder should contain only approved, minimized material. The prototype folder should contain the static demo and synthetic or redacted data. The review folder should capture human review findings and the presenter’s session plan. The handoff folder should explain what engineering needs to know after the demo, including which parts were validated, which parts were generated suggestions, and which parts are intentionally out of scope.

If your team uses a repository, do not assume this entire folder should be committed. Some context files may be inappropriate for version control even after redaction, depending on your policies and customer obligations. If you do commit prototype files, verify that no source material, credentials, private customer identifiers, or unnecessary sensitive details are included. A static demo can be useful without preserving every piece of discovery material in a long-lived repository.

The first decision: prototype fidelity versus data exposure

The opening decision in every build is not “How realistic can we make this?” but “How much realism is necessary to test the customer’s workflow?” Higher fidelity can improve the demo conversation, but it can also increase the risk of exposing confidential details, implying unsupported capabilities, or anchoring engineering on premature design choices. The safest prototype is just realistic enough to support a decision: whether the customer recognizes the workflow, whether the problem is worth solving, and whether engineering should investigate a real implementation.

Use a three-level fidelity scale. Level 1 is a terminology demo: screens use the customer’s vocabulary but all records are synthetic. Level 2 is a workflow demo: the prototype shows the customer’s sequence of steps using synthetic or heavily redacted examples. Level 3 is a data-shape demo: the prototype reflects the customer’s spreadsheet columns, statuses, or categories, but still avoids unnecessary real records. A level beyond that—live customer data or production integration—is outside this tutorial and should require a separate security, legal, product, and engineering process.

Opening checklist before you proceed to the build steps

Before moving into the detailed build process, confirm that the demo has a legitimate business purpose and a written scope. The customer or prospect should understand, explicitly or through an approved business process, that their provided context may be used to prepare a demo for them. Your internal team should know who approved the use, what sources are allowed, which data categories are excluded, and who must review the artifact before the session.

Confirm that the prototype will run in an isolated environment. For a static HTML demo, that can mean a local folder or an approved internal preview environment with no production credentials and no write access to customer systems. If any tool asks for broader access than the task requires, stop and narrow the permission path. If you cannot complete the demo without using raw sensitive data or production access, the workflow should be escalated rather than improvised.

Confirm that a human will review every customer-visible artifact. This includes the prototype screens, mock data, labels, disclaimers, session script, follow-up email draft, and engineering handoff. Do not let Codex or any connected workflow automatically send the demo, update the customer, create CRM notes, move deal stages, open external tickets, merge code, publish a page, or deploy an environment. Generated drafts can accelerate preparation, but consequential action remains a human responsibility.

Finally, confirm that engineering owns the handoff. A demo can reveal a strong product opportunity, but generated prototype code is not a substitute for architecture, security review, data modeling, testing, accessibility review, integration planning, or maintainability work. The purpose of this tutorial is to help teams learn faster from authorized customer context while preserving the controls that make the learning trustworthy.

Input and scope control: turn discovery material into a permissioned demo packet

A controlled customer-specific demo starts before Codex sees a file, a prompt, a screenshot, or a spreadsheet. The working unit should be a permissioned demo packet: a small, reviewed collection of authorized source material, redaction notes, synthetic substitutes, scope limits, and approval records. OpenAI’s Proaction story describes a workflow where authorized customer context, including a Granola call recording, prospect email threads, and customer-shared spreadsheets, helped create customized HTML demo environments. That story is useful as an inspiration pattern, not as permission to ingest every artifact from a sales cycle or connect every app by default.

The practical decision rule is simple: if a piece of information is not needed to make the demo believable, remove it, summarize it, mask it, or replace it with synthetic data. A vehicle type, route category, maintenance workflow, approval step, exception state, or dashboard layout may be necessary for a fleet-management demo. A driver’s personal phone number, customer account credential, payroll field, health detail, government identifier, payment instrument, confidential pricing term, or unrelated internal email chain is not necessary and should not be included. The demo packet should preserve workflow truth while reducing exposure.

For teams using connected apps or plugins, the same control principle applies at the integration layer. OpenAI’s plugin documentation says plugins can package skills, connected apps, and templates, but installing a plugin does not bypass provider authorization or workspace permissions. Access remains constrained by the provider account, role, supported actions, approval requirements, domains, sync behavior, and source restrictions. Treat that as a design boundary: a sales user’s connected mailbox, note-taking app, CRM, or file store should not become a general-purpose evidence lake for Codex.

This playbook covers multi-account plugin governance in ChatGPT, including source attribution, account selection, action approvals, and auditability across personal and work accounts. The Multi-Account Plugin Governance in ChatGPT: Source Attribution, Account Selection, Action Approvals, and Auditability article is a focused companion for Plugin Authorization Governance because the current article’s authorized email and customer-context workflow depends on plugin/account authorization boundaries, making a governance article on account selection and approvals the strongest semantic match.

Build a permission inventory before collecting content

A permission inventory is a structured record of what the customer or prospect authorized, who approved internal use, what systems contain the information, what the demo team may extract, and what must stay out. The inventory is not a ceremonial compliance artifact; it is the map that prevents prompt sprawl, accidental uploads, unapproved recordings, and confusing handoffs. The person assembling the demo packet should be able to point to a row in the inventory for every item included in the Codex workspace.

The table below is a recommended structure. It is a policy proposal for operating this workflow safely, not a statement that OpenAI requires this exact form. Adapt the fields to your organization’s security program, procurement commitments, customer agreements, and workspace administration model.

The inventory should be created before any automated transformation. Do not ask Codex to “go through the mailbox,” “summarize every call,” or “find anything useful in this folder” unless the workspace, connected account, source restrictions, and customer authorization have already narrowed the corpus to permitted material. Broad discovery instructions are where customer-specific demo projects most often drift from scoped prototyping into ungoverned data mining.

Define “minimum necessary” for each source type

Minimum necessary does not mean “as little as possible” in the abstract; it means the smallest amount of information that still supports the agreed demo outcome. If the goal is to show a dispatch dashboard, the model may need vehicle categories, route statuses, maintenance flags, and exception counts. It probably does not need actual driver names, exact pickup addresses, private notes about a customer’s internal politics, or the full text of every discovery email. Minimum necessary is a design constraint that protects both the buyer and the builder.

Use this three-question test for each proposed input. First, which demo screen or user story does this input support? Second, can the same screen be built from a summary, schema, aggregate, or synthetic substitute? Third, would inclusion create a privacy, security, legal, contractual, or trust risk if the demo workspace were later audited? If the answer to the second question is yes, use the lower-risk representation. If the answer to the third question is yes, escalate before including the data or exclude it entirely.

For call notes, the minimum necessary unit is usually a curated discovery brief, not the raw recording or transcript. A safe brief might state that the prospect needs to review maintenance exceptions by region, escalate overdue inspections to a supervisor, and compare weekly completion rates across fleet segments. It should omit small talk, personnel issues, unapproved customer names, and any statement not needed to shape the demo. When a direct customer phrase is important for authenticity, paraphrase it unless the customer has approved direct use.

For email threads, the minimum necessary unit is usually a requirement line item. Instead of copying a full thread into a prompt, create a list such as “Customer requested a manager approval step before closing a damage claim” and cite the message date or subject internally. Do not include hidden recipients, forwarded confidential material, negotiation commentary, legal terms, or attachments unless they are specifically authorized and necessary. Email is a high-risk source because it often contains more context than the sender intended to be reused for prototyping.

For spreadsheets, the minimum necessary unit is often the schema rather than the cells. Column names, data types, allowed statuses, and representative ranges can support an excellent demo without exposing production rows. If a spreadsheet contains vehicles, loads, tickets, inspections, claims, or inventory records, create a synthetic CSV that preserves column structure and realistic relationships while replacing customer-specific values. If the spreadsheet contains regulated data, account credentials, payment data, personal identifiers, or sensitive commercial terms, do not include it in the demo packet unless counsel, security, and the customer have approved the exact processing plan.

For screenshots, the minimum necessary unit is a cropped, annotated region or a recreated wireframe. Full-screen captures can expose browser tabs, account names, notifications, tenant URLs, support conversations, extension icons, or production identifiers. Before a screenshot enters the workspace, crop irrelevant regions, blur identifiers, remove URLs, and convert the image into a design reference. If the screenshot comes from the customer’s product, internal system, or vendor console, confirm that the customer has authorized its use for demo preparation.

For workflow diagrams, the minimum necessary unit is a role-and-state map. The prototype needs to know that a driver submits an issue, an operations manager triages it, a supervisor approves a follow-up, and a report is generated. It rarely needs full security boundaries, vendor-specific integration details, internal escalation names, or contractually sensitive service-level commitments. Keep diagrams abstract enough to guide the user experience without exposing operational blueprints.

Create a source manifest that Codex and reviewers can follow

A source manifest is the demo packet’s table of contents and audit trail. It should identify each file, its origin, authorization status, redaction status, intended use, and retention decision. The manifest should be stored alongside the prototype project so that sales, product, engineering, security, and legal reviewers can see what the demo was built from. Codex can use the manifest as structured context, but the manifest should not contain secrets or unnecessary personal data.

The example below is a safe structure. Replace all placeholder content with your own approved metadata, and avoid storing credentials, access tokens, private URLs, account numbers, or sensitive personal data in the manifest.

{
  "demo_packet_id": "DEMO-PACKET-2026-09-ALPHA-FLEET",
  "customer_display_name": "Alpha Fleet prospect",
  "prepared_by_role": "Solutions engineer",
  "review_status": "pending_security_and_account_owner_review",
  "scope_summary": "HTML-only prototype showing maintenance exception triage and manager approval workflow.",
  "sources": [
    {
      "source_id": "SRC-001",
      "source_type": "call_notes_summary",
      "origin_system": "approved meeting notes export",
      "source_date": "2026-09-18",
      "authorization_basis": "customer-approved discovery use confirmed by account owner",
      "included_fields": [
        "workflow steps",
        "role labels",
        "pain points",
        "approved terminology"
      ],
      "excluded_fields": [
        "attendee personal phone numbers",
        "unrelated contract discussion",
        "unapproved transcript text"
      ],
      "redaction_status": "raw transcript not included; summary reviewed",
      "demo_use": "scenario copy and workflow labels",
      "retention_decision": "delete from demo workspace after handoff review"
    },
    {
      "source_id": "SRC-002",
      "source_type": "synthetic_spreadsheet",
      "origin_system": "derived from customer-shared column schema",
      "source_date": "2026-09-20",
      "authorization_basis": "schema use approved; production rows excluded",
      "included_fields": [
        "vehicle_category",
        "region",
        "inspection_status",
        "days_overdue"
      ],
      "excluded_fields": [
        "driver_name",
        "vehicle_identifier",
        "exact route address",
        "customer account number"
      ],
      "redaction_status": "synthetic rows generated by demo team",
      "demo_use": "table views, filters, and chart labels",
      "retention_decision": "retain synthetic file with prototype; delete schema notes after engineering handoff"
    }
  ],
  "approval_gates": [
    "account_owner_review",
    "security_review_if_connected_apps_used",
    "customer_demo_owner_confirmation_before presentation",
    "engineering_owner_acceptance_before backlog creation"
  ]
}

The manifest should be updated when a file is added, removed, transformed, or rejected. A stale manifest is worse than no manifest because it gives reviewers false confidence. If the demo team later decides to add a product screenshot, CRM note, support ticket, or spreadsheet tab, create a new source row and repeat the permission check. Do not rely on memory or chat history as the approval record.

Capture customer consent without overpromising legal coverage

Customer consent for demo preparation should be explicit enough that a reasonable reviewer can understand what was allowed. It should identify the materials, purpose, audience, duration, and exclusions. Consent can be part of a statement of work, proof-of-concept agreement, email confirmation, account-team approval record, or procurement-approved demo plan, depending on your organization’s process. This tutorial does not provide legal advice and does not determine whether any particular consent language satisfies a contract, privacy law, sector rule, or procurement policy.

A practical consent record should answer five questions. What customer-provided material may be used? What will it be used to build? Who may access the demo workspace? How long will the material be retained? What categories are excluded even if they appear in the source systems? The answer should be recorded before collection begins, not reconstructed after the prototype is successful.

Sample consent note for internal workflow only: “Customer approved use of the September discovery notes, the shared maintenance-status column schema, and the workflow diagram labeled ‘inspection escalation v2’ to prepare a non-production HTML prototype for the scheduled demo. Production records, personal contact details, credentials, pricing terms, regulated data, and unapproved recordings are excluded. Prototype access is limited to the account team, assigned solutions engineer, security reviewer if needed, and engineering reviewer. Customer-specific source material will be removed from the demo workspace after the handoff review unless a separate retention approval is recorded.”

That sample is a drafting aid, not a legal template. Your legal, privacy, and procurement teams may require different wording, data-processing terms, jurisdiction-specific notices, or customer-side approvals. If there is uncertainty about whether the customer authorized an input, do not include it. A less personalized demo is preferable to a demo built on disputed or excessive data.

Redaction and synthetic substitutes: preserve workflow, remove exposure

Redaction is useful only when it is deliberate and reviewed. Simply replacing a few visible names while leaving unique identifiers, rare route names, exact addresses, or unusual combinations of fields can still expose sensitive information. For customer-specific demos, redaction should remove direct identifiers, indirect identifiers, secrets, confidential business terms, unrelated personal information, and operational details not required by the scope contract.

Synthetic substitutes are often better than redacted real records. A synthetic spreadsheet can preserve the number of columns, allowed statuses, realistic distributions, exception states, and dashboard behaviors without exposing actual customer rows. A synthetic email summary can preserve the requirement “regional manager must approve overdue inspection closure” without copying the customer’s internal language. A synthetic vehicle list can show categories and maintenance conditions without using real vehicle identifiers.

When using synthetic data, label it clearly inside the repository and in the demo script. Do not imply that synthetic rows are customer records. A safe demo can say, “The workflow and statuses are based on your approved discovery summary, and the table rows are synthetic.” That statement preserves trust and prevents the audience from mistaking mock data for a production migration or integration.

Retention rules: decide deletion before the first file lands

Retention is part of scope control. If the team cannot say when customer-specific source material will be removed, where it will be stored, and who can approve exceptions, the demo is not controlled. The default should be short-lived retention for customer-specific inputs and longer retention only for sanitized artifacts, synthetic data, and engineering-approved requirements. The specific schedule must align with your contracts, security policies, workspace controls, and legal obligations.

A practical retention plan separates four classes of material. Raw customer source material is the highest-risk class and should usually be excluded or deleted soon after transformation and review. Redacted summaries may be retained through the demo and handoff if they remain necessary. Synthetic demo assets may be retained with the prototype because they do not contain customer records. Engineering requirements may be retained in the product backlog only after an engineering owner confirms that the requirement is appropriately generalized or authorized for customer-specific work.

Deletion should be verified, not assumed. If files are copied from connected apps into a local workspace, exported into a repository, attached to an issue, or pasted into a document, each copy needs the same retention decision. Avoid spreading the same source material across chat transcripts, code comments, design docs, and tickets. The more copies you create, the harder it becomes to honor deletion commitments or explain what the demo used.

Plugin authorization and connected-source boundaries

Connected apps can improve speed, but they expand the permission surface. OpenAI’s plugin documentation says installation does not bypass the app provider’s authorization or workspace permissions, and access depends on role, provider account, supported actions, approval requirements, domains, sync, and source restrictions. For a controlled demo, treat connected-source access as a privileged operation that requires a specific reason, not a convenience default.

Before connecting any app, define the intended read path. For a call-notes provider, the allowed path might be one approved meeting summary exported by the account owner. For email, it might be one customer-approved thread summarized outside the Codex workspace. For a spreadsheet provider, it might be one customer-shared workbook with only approved tabs and columns. For a CRM or project tool, it might be no direct access at all; the account owner can provide a sanitized requirements summary instead.

Do not use a plugin or connected account to bypass a customer’s sharing choice. If the customer sent a single spreadsheet attachment, that does not imply permission to inspect their entire shared drive, all previous calls, or every account email. If a workspace administrator has limited app access, do not work around that control by exporting data through another user, a personal account, or a copy-paste path. Provider authorization, workspace policy, and customer consent all need to align.

Recommended connected-source policy: start with manual export of reviewed, sanitized inputs. Escalate to direct plugin access only when manual export is impractical, the source scope can be narrowed, the workspace policy allows the connection, and a human owner approves the action. Disable or disconnect sources that are not needed for the current demo packet. Record the source, account role, and permitted action in the manifest.

Workspace controls: isolate the prototype from production systems

The controlled demo workspace should be isolated from production systems and from repositories that contain production secrets. OpenAI’s Codex security documentation distinguishes sandbox mode and approval policy as separate layers, and notes that Codex defaults to no network access in local workspace-write mode. That default is a useful starting point for a demo project because most HTML prototypes can be built from local sanitized files without network access. Do not treat sandboxing as a substitute for careful source selection; it is an additional layer, not permission to include sensitive data.

A safe workspace contains only the files needed to build and review the prototype: a source manifest, synthetic dataset, sanitized scenario brief, static assets cleared for demo use, HTML, CSS, JavaScript, and a handoff document. It should not contain production credentials, environment files with secrets, API keys, private customer exports, unrelated repositories, personal notes, browser session files, or customer records. If the prototype needs to imitate an integration, stub it with local JSON rather than connecting to production.

The recommended operating posture is local-first, read-limited, and review-gated. Local-first means the prototype runs as static files or a local development server without production writes. Read-limited means Codex sees only the curated packet, not the broader mailbox, drive, CRM, or codebase. Review-gated means a human approves any step that would contact an external service, change permissions, publish files, send a message, create an issue, or update a system of record.

Use a separate directory or repository for the demo. Do not place the demo inside the production application unless engineering has accepted that structure and reviewed the data boundaries. A separate workspace makes it easier to inspect files, delete customer-specific inputs, archive the prototype, and prevent accidental commits to product code. If version control is used, review diffs for sensitive strings before committing, and do not commit raw discovery material unless it is explicitly approved and necessary.

Sandbox mode, approval policy, and network access

Codex projects should be configured so that sandboxing and approval behavior match the risk of the task. OpenAI’s Codex agent approvals and security guidance treats sandbox mode and approval policy as separate controls, which means teams should reason about both. A sandbox can limit what the agent may access or change, while an approval policy determines when a human must authorize an action. For customer-specific demos, err toward restrictive defaults and add permissions only when a reviewer can explain why they are required.

Network access deserves special scrutiny. A static HTML prototype usually does not need outbound network calls. If Codex can reach the network, a mistaken command, package script, or generated integration could contact an external system, download dependencies, or attempt a call that reviewers did not intend. When network access is not needed, keep it unavailable. When network access is needed, document the reason, approved domains if your environment supports that control, expected command, and human approval requirement.

Do not allow the prototype to write to production databases, send customer emails, create CRM notes, update tickets, merge code, deploy assets, process payments, book meetings, submit forms, or change permissions. Those are consequential actions and require authorized human approval in the appropriate system. A demo may show a button labeled “Send approval request,” but the button should trigger a local mock state change, not an actual email or workflow action.

The table below offers a conservative control matrix. It is a recommended operating model, not a claim about every Codex plan, client, workspace, or rollout. Current behavior can vary by account, app, region, plan, and administrator policy, so verify the controls available in your environment before relying on them.

Write the demo scope contract before prompting Codex

The demo scope contract is a short written agreement among the account owner, demo builder, security or legal reviewer when needed, and engineering owner. It states what the prototype will show, what it will not do, what inputs are approved, what controls apply, what review gates must happen, and how the output will be handed off. The contract prevents a promising prototype from quietly becoming an unreviewed product commitment or an unauthorized customer deliverable.

A good scope contract is concrete enough that Codex instructions can be derived from it. “Build a personalized demo” is not a scope. “Build a static HTML prototype that shows synthetic maintenance exceptions grouped by region, a mock supervisor approval step, and a non-functional export button” is a scope. The second version tells the builder what to include, what to mock, and where human review is needed.

# Controlled Demo Scope Contract

demo_name: "Maintenance Exception Triage HTML Prototype"
customer_context_status: "authorized, redacted, and synthetic where possible"
business_goal: "Show how the proposed workflow could help operations managers review overdue inspections and route approvals."
prototype_type: "Static HTML/CSS/JavaScript demo with local
Build the disposable prototype branch and keep it disposable


The safe build pattern for a customer-specific demo is a short-lived branch, a static prototype, fixture data, and a review packet that can be deleted or promoted into engineering-owned requirements without carrying customer-sensitive artifacts forward. OpenAI’s Proaction story describes Codex being used to turn authorized call recordings, prospect email threads, and customer-shared spreadsheets into customized HTML demo environments, but this tutorial treats that pattern as inspiration for a controlled workflow, not as permission to connect accounts, expose private data, write production code, or communicate with customers automatically.

Start by creating a branch whose name communicates scope and disposal. A useful convention is demo/customer-initials-date-purpose, but avoid using a full customer legal name if your repository naming policies treat branch names as widely visible metadata. The branch should contain only static HTML, CSS, fixture JSON, screenshots approved for demo use, a source manifest, acceptance criteria, feedback notes, and the handoff packet. It should not contain production credentials, API keys, live customer exports, regulated data, private recordings, or code intended to bypass an existing product review process.

git checkout main
git pull --ff-only
git checkout -b demo/fleet-ops-2026-09-disposable-html

mkdir -p demo/static demo/fixtures demo/review demo/handoff
touch demo/README.md
touch demo/source-manifest.md
touch demo/acceptance-criteria.md
touch demo/fixtures/vehicles.json
touch demo/static/index.html
touch demo/static/styles.css
touch demo/review/visual-review-notes.md
touch demo/handoff/requirements-packet.md
The branch should be blocked from automatic deployment by repository policy or continuous integration rules. If your build system deploys every branch preview by default, pause before adding any customer-specific content and ask an authorized repository administrator to disable preview deployment for this branch or route it to an internal-only environment. This is an operational recommendation, not a documented Codex feature. The purpose is to keep demo creation from becoming an accidental publication path.
OpenAI’s Codex approval and security guidance distinguishes sandboxing from approval policy, and notes that Codex defaults to no network access in local workspace-write mode. Treat those controls as separate layers: repository isolation limits what files the work touches, sandboxing limits execution context, approval policy governs whether actions require confirmation, and network posture limits external access. Do not assume one layer substitutes for another, and do not ask Codex to fetch customer material from connected services unless the source, account, action, and workspace policy have already been authorized.
Use a build note at the top of demo/README.md that states the branch is disposable, static-only, non-production, and not customer-ready until reviewed. This warning is practical because demo branches often get reused when a customer likes the prototype. Reuse is acceptable only after engineering accepts ownership, removes temporary material, and decides whether any assets or flows should move into the product backlog.
# Disposable controlled demo

Status: internal prototype only.
Purpose: show a static, customer-specific workflow using authorized or synthetic context.
Restrictions:
- No production writes.
- No CRM updates.
- No external messages.
- No deployment without explicit human approval.
- No secrets, regulated data, private recordings, or live customer exports.
- Delete or convert into an engineering-owned requirements packet after review.
Create fixture data that demonstrates workflow without exposing the customer
Fixture data is the safest bridge between discovery context and a visible prototype. It should preserve the shape of the customer’s workflow—vehicle types, task states, approval steps, exception categories, spreadsheet columns, or email-request patterns—while removing or replacing identities, account numbers, exact addresses, unique vehicle identifiers, employee names, phone numbers, message IDs, health information, payment data, and any other unnecessary confidential content. If the demo requires a recognizable object, get explicit customer authorization for that object or use a synthetic equivalent.
For a fleet-management scenario, the fixture file might include vehicle labels, maintenance status, workflow stage, assigned region, and a synthetic urgency score. It should not include real VINs, driver personal details, insurance policy numbers, GPS trails, private claims notes, or raw image metadata. When a salesperson says “the customer will recognize this,” ask whether recognition comes from the process pattern or from sensitive identifiers. Prefer process recognition.
{
  "customerProfile": {
    "displayName": "Regional Fleet Operator",
    "demoLabel": "Synthetic account inspired by authorized discovery",
    "sourceBoundary": "No live customer data; fields derived from approved workflow themes"
  },
  "vehicles": [
    {
      "unit": "Truck-014",
      "type": "Box truck",
      "region": "North route",
      "status": "Inspection pending",
      "workflowStage": "Awaiting photo review",
      "nextAction": "Schedule maintenance review",
      "urgency": "Medium"
    },
    {
      "unit": "Van-022",
      "type": "Service van",
      "region": "Central route",
      "status": "Ready",
      "workflowStage": "Dispatch approved",
      "nextAction": "No action required",
      "urgency": "Low"
    }
  ]
}
Document every fixture transformation in the source manifest. The manifest should state the original authorized source category, the specific fields used, the redaction or synthesis method, the reviewer, and the reason the field is necessary. This does not convert unauthorized material into authorized material; it creates an audit trail for material that was already approved for internal demo preparation. If authorization is unclear, do not include the field.



Fixture element
Allowed source
Transformation
Why it is necessary
Reviewer checkpoint




Vehicle category
Customer-shared spreadsheet with demo authorization
Generalized from specific model to category
Shows routing and maintenance workflow
Confirm no unique asset identifier remains


Workflow stage
Authorized call notes
Converted into generic status labels
Demonstrates operational sequence
Confirm call notes do not reveal private statements


Next action
Prospect email context approved for demo planning
Rewritten as synthetic task text
Shows value proposition in familiar terms
Confirm no email addresses or message IDs remain


Urgency
Local product hypothesis
Synthetic value created for prototype
Supports prioritization screen
Label as hypothetical, not customer-confirmed



Keep fixture files small enough for reviewers to inspect manually. A ten-row synthetic dataset usually demonstrates a workflow better than a 5,000-row spreadsheet excerpt that creates privacy and review burden. If a large dataset is needed to test performance, that task belongs in engineering evaluation using approved test data, not in a sales prototype branch.
Generate the static HTML prototype without connecting to live systems
The first prototype should be static HTML that reads local fixture data or embeds a small fixture object in the page. Static HTML reduces accidental side effects because it does not need authentication, server callbacks, payment flows, CRM writes, production database access, or background jobs. It also keeps the customer-session conversation focused on workflow validation rather than product maturity claims.
Give Codex a narrow implementation request that includes the files it may modify, the files it must not touch, and the output standard. If using Codex CLI or an agentic workflow, keep the task constrained to the disposable branch and review each proposed file change before accepting it. OpenAI’s safety best-practices guidance emphasizes human review for high-stakes work; a customer demo that may influence commitments, roadmap expectations, or procurement should be treated as consequential even when the code itself is static.
Recommended Codex prompt for a static prototype:

You are working in a disposable demo branch. Build a static HTML prototype only.
Allowed files:
- demo/static/index.html
- demo/static/styles.css
- demo/fixtures/vehicles.json
- demo/README.md

Do not:
- Add external network calls.
- Add analytics, trackers, forms, email sending, CRM updates, or production writes.
- Include credentials, tokens, customer identifiers, real VINs, personal data, or regulated data.
- Modify application source outside demo/.
- Create deployment configuration.

Use the fixture data to render:
1. A fleet overview dashboard.
2. A vehicle workflow board.
3. A detail panel for next actions.
4. A visible banner that says this is a static prototype using synthetic or redacted data.

Return a summary of files changed and any assumptions.
The visible prototype banner is not cosmetic. It prevents a common failure mode: stakeholders see a polished screen and infer that the feature already exists, is integrated, or has passed product security review. Use direct language such as “Static internal demo using synthetic or redacted data; not connected to production systems.” Do not bury that statement in a README that the customer never sees.
<div class="prototype-banner">
  Static internal demo using synthetic or redacted data.
  Not connected to production systems. No actions are submitted.
</div>
A good prototype shows workflow sequencing, terminology, and exception handling. It should not simulate legal, financial, insurance, safety, medical, employment, or compliance determinations as if they were automated final decisions. If your customer operates in a regulated or high-stakes environment, label decision-support screens carefully and route consequential decisions to human review in the prototype text.
This 25-prompt website QA collection focuses on privacy review, accessibility checks, validation evidence, and stakeholder approval, providing a concrete companion checklist for evaluating a customer-specific HTML prototype before presentation. The 25 ChatGPT-5.5 Prompts for Website QA, Privacy Reviews, Accessibility Checks, and Stakeholder Approval article is a focused companion for Prototype Review Checklist because the target directly covers website QA, privacy, accessibility, and stakeholder approval and is therefore substantially more accurate than the unrelated Microsoft Store review-summary article.
Write acceptance criteria before the first review
Acceptance criteria prevent the demo from becoming a subjective taste exercise. They should state what the prototype must prove, what it must not imply, and what evidence reviewers need before it can be shown in a customer session. This is not the same as production acceptance criteria. Prototype acceptance criteria are narrower: privacy-safe inputs, accurate reflection of the authorized workflow, no side effects, clear disclaimers, and a useful conversation path for the session owner.



Category
Prototype acceptance criterion
Pass evidence
Failure response




Authorization
Every source used in the prototype appears in the source manifest with approval status.
Manifest reviewed by the accountable owner.
Remove unverified source-derived content.


Data minimization
No unnecessary personal, regulated, confidential, or uniquely identifying data appears in fixtures or UI.
Manual fixture and screen review completed.
Redact, synthesize, or delete the field.


Isolation
The prototype makes no external calls and performs no production writes.
Code inspection and local browser network check.
Remove the integration or stop the demo.


Customer truthfulness
The UI does not imply completed integrations, commitments, or automated decisions that do not exist.
Session owner signs off on talk track.
Add disclaimer or remove the screen.


Engineering handoff
Open questions, assumptions, and customer-specific terms are captured separately from proposed requirements.
Handoff packet contains assumption log.
Return to discovery before engineering estimation.



Use negative criteria as well as positive criteria. “The prototype must not send, submit, update, purchase, book, deploy, merge, or write to production” is clearer than “safe demo only.” The negative list should be tailored to your environment. For a sales-led demo, include no CRM updates and no external emails. For an internal operations demo, include no permission changes and no data deletion. For a code-adjacent prototype, include no merge, no release tag, and no deployment.
# Prototype acceptance criteria

The prototype is ready for internal visual review only if:
- All source-derived content is listed in demo/source-manifest.md.
- All fixture data is synthetic, redacted, or explicitly approved for this demo.
- The UI displays a static-prototype disclaimer.
- Browser developer tools show no external network calls during local review.
- No forms submit data.
- No CRM, email, ticketing, billing, repository, or production systems are updated.
- The customer-session owner has an approved talk track.
- Engineering has not been asked to estimate until assumptions are separated from confirmed requirements.
Do not let a customer deadline erase acceptance criteria. A rushed prototype is exactly when a team is most likely to paste raw spreadsheet rows, expose message fragments, or imply that a desired integration already exists. If the acceptance criteria cannot be met before the meeting, show a generic workflow demo or use a whiteboard session instead.
Run a visual and privacy review before any customer-facing session
The visual review should be conducted by at least two humans with different responsibilities: one person who understands the customer conversation and one person who is accountable for privacy, security, product, or engineering risk. The reviewer mix matters because sales teams are good at spotting workflow relevance, while engineering or security reviewers are more likely to notice hidden external calls, misleading states, over-specific identifiers, or accidental commitments.

Open the prototype locally. Load the static HTML from the disposable branch rather than from a public preview unless an internal-only preview has been explicitly approved.
Inspect the browser network panel. Reload the page and confirm that it does not call external domains, analytics tools, fonts, image hosts, APIs, CRM systems, or storage buckets unless those resources have been approved for this demo.
Scan every visible string. Look for names, email addresses, phone numbers, account numbers, exact addresses, real VINs, private notes, internal pricing, deal strategy, or any statement that should not be shown to the customer.
Compare screens to the source manifest. If a label, workflow step, metric, or example appears in the UI, reviewers should know whether it came from authorized discovery, synthetic design, or product hypothesis.
Test the talk track. The presenter should say out loud what is real, what is simulated, what is hypothetical, and what would require engineering validation.
Record review decisions. Use demo/review/visual-review-notes.md to capture pass, fail, required edits, and unresolved questions.

Visual polish can be risky when it outruns truthfulness. A prototype that looks production-grade should carry stronger disclaimers, not weaker ones. If the customer might interpret a polished dashboard as a shipped integration, add an explicit session statement and on-screen label that it is a static prototype using synthetic or redacted data. The goal is to validate workflow fit, not to create false certainty.
# Visual review notes

Review date:
Reviewers:
Branch:
Commit:

Checks:
- Static prototype disclaimer visible:
- No external network calls observed:
- No production write paths:
- Fixture data inspected:
- Source manifest complete:
- Talk track reviewed:
- Customer permission confirmed for session use:

Required edits:
1.
2.

Unresolved questions:
1.
2.

Decision:
- Not ready / Ready for internal rehearsal / Ready for customer session with named presenter approval
When using plugins or connected apps as part of research before the prototype, remember that OpenAI’s plugin documentation states that installation does not bypass provider authorization or workspace permissions. App access remains subject to the provider account, role, supported actions, approval requirements, domains, sync, and source restrictions. A visual review should therefore confirm not only what the HTML shows, but also whether the path used to create it respected source and workspace boundaries.

Operational warning: Do not use a customer demo session to test whether a connected app can send, sync, update, or retrieve data. Test connected-source behavior separately under approved conditions, and keep the customer prototype static unless engineering and security have approved a different environment.

Prepare the customer session without sending anything automatically
The session preparation step produces a human-approved agenda, talk track, screen order, risk note, and feedback plan. It does not send calendar messages, update a CRM, create customer commitments, publish a preview URL, or distribute files automatically. If any external communication is required, an authorized human should review and send it through the organization’s approved channel.
A useful customer-session agenda separates context confirmation from prototype reaction. Begin by confirming that the demo is static and based on authorized, synthetic, or redacted context. Then walk through the workflow in the order the customer described it: intake, triage, exception handling, approval, reporting, and next action. End with questions that distinguish “this reflects our process” from “this is important enough to build.” That distinction protects engineering teams from inheriting attractive but low-priority screens.
# Customer-session talk track

Opening:
- This is a static prototype for discussion.
- It uses synthetic or redacted data based on authorized discovery themes.
- It is not connected to production systems and does not submit actions.
- We are looking for workflow accuracy, missing steps, terminology issues, and priority.

During walkthrough:
- Confirm each workflow stage.
- Ask whether the displayed terminology matches customer language.
- Mark each assumption as confirmed, corrected, or rejected.
- Do not promise delivery dates, integrations, pricing, legal coverage, or final product behavior.

Closing:
- Summarize confirmed needs and open questions.
- Explain that engineering will review requirements before commitments.
- State that no production changes or customer account changes are being made from this demo.
Prepare a feedback sheet before the call. Live note-taking should avoid unnecessary personal data and should not copy sensitive customer statements verbatim unless there is a documented business need and authorization to retain them. Use categories rather than raw transcripts where possible: confirmed workflow, rejected assumption, missing role, integration dependency, data field needed, compliance concern, and buying-process question.



Feedback category
What to capture
What to avoid
Engineering value




Confirmed workflow
Step name, actor, trigger, expected result
Personal anecdotes not needed for design
Converts into process requirements


Rejected assumption
Screen, assumption, correction
Blame-oriented notes or private negotiation details
Prevents building the wrong flow


Missing field
Field name, source system, user purpose
Raw exports or credentials
Supports data-model discovery


Integration dependency
System name, direction of data flow, approval owner
API keys, tokens, private endpoints
Frames technical feasibility review


Compliance concern
Policy area, review owner, unresolved question
Legal conclusions by non-lawyers
Routes to qualified review



If the customer asks for a copy of the prototype, do not send the branch, files, screenshots, or preview link during the call unless that distribution was approved in advance. Instead, note the request and route it through your customer-facing approval process. This protects both sides from receiving material that contains unreviewed assumptions, internal comments, or content scoped only for live discussion.
Log feedback as evidence, not as a promise
Feedback logging should preserve what was observed without transforming every comment into a commitment. Use a structured log with fields for source, confidence, owner, and required follow-up. A customer saying “we would need this to integrate with our maintenance system” is evidence of an integration dependency; it is not proof that the integration is feasible, contracted, secure, or prioritized. Engineering review, commercial review, and legal or security review may all be required before that statement becomes a requirement.
# Feedback log entry

ID: F-001
Session date:
Customer role:
Prototype screen:
Observation:
Customer wording summary:
Category: confirmed workflow / rejected assumption / missing field / integration dependency / compliance concern / commercial question
Source confidence: direct customer statement / inferred from discussion / presenter observation
Data sensitivity: none / internal / confidential / regulated review required
Follow-up owner:
Engineering relevance:
Commercial relevance:
Open questions:
Do not treat as commitment until reviewed by:
Separate direct feedback from internal interpretation. The direct feedback field should summarize what the customer indicated. The interpretation field should state your team’s hypothesis, such as “This may require role-based task queues” or “This suggests the spreadsheet is a temporary workaround for a source system.” That separation helps engineering challenge assumptions without dismissing the customer’s actual need.
Use issue IDs rather than copying large amounts of transcript text into the repository. If your organization has an approved call-notes system, reference the authorized note location in the source manifest instead of duplicating sensitive content. If the notes contain confidential or regulated information, do not move them into the prototype branch. The branch should remain a low-sensitivity workspace that can be deleted cleanly.
When feedback includes safety, legal, financial, health, employment, youth, or compliance implications, label it for qualified review rather than asking Codex to resolve it. For example, a request to “automatically approve claims under a threshold” should be logged as a consequential-decision workflow requiring policy, legal, and human-approval review. The prototype can show “route to reviewer,” but it should not present automated approval as an accepted product behavior.
Triage issues before engineering sees the packet
Issue triage turns raw session feedback into a clean engineering intake. The triage owner should remove duplicates, separate product questions from sales questions, identify security and privacy blockers, and mark which items are confirmed by customer evidence versus internal hypothesis. This step prevents engineering from receiving a pile of screenshots and call notes with no decision structure.



Triage label
Definition
Example
Next action




Confirmed requirement candidate
Customer validated the need and workflow, but engineering has not accepted it.
Dispatch manager needs a queue of vehicles awaiting inspection.
Write requirement candidate with source reference.


Unvalidated assumption
Prototype included a hypothesis that the customer did not confirm.
Urgency score formula shown without customer agreement.
Move to open questions or remove.


Integration dependency
Value depends on a source, destination, permission, or supported action outside the static demo.
Maintenance system must receive approved work orders.
Route to technical discovery and security review.


Policy blocker
Request affects privacy, security, compliance, legal, safety, or approval boundaries.
Automatically emailing drivers about incident findings.
Require qualified owner review before requirement acceptance.


Commercial or contractual item
Question concerns pricing, delivery commitments, contract terms, or support obligations.
Customer asks whether the integration is included in launch scope.
Route to authorized business owner; do not encode as engineering scope.



Prioritize issues using a simple decision rule: confirmed user workflow before visual enhancement, safety or privacy blocker before convenience feature, integration feasibility before delivery promise, and engineering-owned requirement before roadmap assertion. This order keeps the team from polishing a screen whose underlying data flow cannot be approved.
Codex can help format the triage table, deduplicate issue text, and identify missing fields if the input has already been redacted and authorized. It should not be asked to make business commitments, approve legal interpretations, decide whether data processing is lawful, or silently infer customer consent. Human owners remain responsible for triage decisions and for any consequential communication.
Recommended Codex prompt for triage formatting:

Using only the redacted feedback entries in demo/review/feedback-log.md,
create a triage table in demo/handoff/requirements-packet.md.

Rules:
- Do not add facts that are not in the feedback log.
- Separate confirmed customer statements from internal hypotheses.
- Mark integration, privacy, security, legal, compliance, and commercial questions as requiring human owner review.
- Do not create delivery commitments, dates, pricing statements, or production tasks.
- Do not modify files outside demo/handoff/requirements-packet.md.
If a triage item cannot be traced back to authorized discovery or customer-session feedback, mark it as “internal hypothesis.” Hypotheses can be valuable; they are how product teams explore options. The problem begins when hypotheses are handed to engineering as customer-confirmed requirements. The handoff packet should make that distinction impossible to miss.
Convert the demo into an engineering-owned requirements packet
The requirements packet is the point where the disposable sales prototype stops being the source of truth. Engineering should receive a concise, source-led packet that explains the customer problem, validated workflow, data needs, integration assumptions, non-functional concerns, open questions, and review gates. The packet may include screenshots from the prototype, but screenshots are supporting evidence, not specifications by themselves.
This tutorial explains how to use the Codex IDE extension in VS Code for inline editing, context sharing, and task handoff across multi-file development workflows. The How to Use the Codex IDE Extension in VS Code — Inline Editing, Context Sharing, and Task Handoff article is a focused companion for Requirements Handoff because the article ends with engineering handoff from a demo into implementation, and this target directly covers Codex task handoff and context sharing inside a developer workflow.
A strong packet begins with a status statement: “This packet is a requirement candidate derived from an authorized static demo and customer feedback. It is not a delivery commitment, not a production design, and not approved for implementation until engineering, product, security, and other required owners accept scope.” That language is especially important when the prototype helped move a deal forward, because commercial momentum can pressure teams to skip review.
# Engineering-owned requirements packet

## 1. Packet status
Requirement candidate only. Not a delivery commitment.

## 2. Source boundary
- Authorized call-note themes:
- Approved email-context themes:
- Customer-shared spreadsheet fields:
- Synthetic or redacted fixture fields:
- Excluded sources and why:

## 3. Customer problem
Brief description of the operational problem, affected roles, and current workaround.

## 4. Validated workflow
Step-by-step workflow confirmed during the session, with feedback IDs.

## 5. Requirement candidates
Each requirement includes:
- User role:
- Need:
- Trigger:
- Expected result:
- Source evidence:
- Confidence:
- Open questions:

## 6. Data and integration assumptions
- Source systems:
- Destination systems:
- Read/write direction:
- Permission owner:
- Security review needed:
- Unknowns:

## 7. Non-functional and policy considerations
- Privacy:
- Security:
- Auditability:
- Human approval:
- Retention:
- Accessibility:
- Reliability:
- Compliance or legal review needed:

## 8. Prototype artifacts
- Screenshot references:
- Fixture files:
- Branch name:
- Commit:
- Known limitations:

## 9. Engineering decision request
- Accept for discovery:
- Request more information:
- Reject or defer:
- Assign owner:
For each requirement candidate, include an evidence link or reference to a feedback ID rather than a vague phrase such as “customer wants.” Evidence does not need to be a public URL and should not expose confidential notes in the packet. A safe pattern is “Feedback F-003, session notes retained in approved system, summarized in redacted form.” This gives engineering traceability without expanding access to sensitive content.
Evaluate the demo before engineering treats it as requirements
A controlled customer-specific demo is useful only if the team can prove what it represented, which inputs supported it, what was reviewed, and what was explicitly out of scope. Treat evaluation as a release gate for the requirements packet, not as a sales-deck polish step. OpenAI’s Proaction story describes a workflow in which authorized customer context can be turned into a customized HTML demo, but the story does not remove the need for local evidence, customer permission, reviewer accountability, and engineering approval.
The evaluation package should answer five operational questions: whether the demo used only authorized inputs, whether the prototype accurately reflects the agreed workflow, whether private or regulated material has been excluded, whether the demo is accessible enough for the intended session, and whether engineering can distinguish demonstrated behavior from requested production behavior. If any answer is “unknown,” the packet is not ready for customer use or engineering handoff.
This prompt set is designed for product-engineering teams using ChatGPT and Codex for bug triage, design reviews, remote-agent tasks, strategic documents, and release evidence with human review boundaries. The 25 ChatGPT-5.5 and Codex Prompts for Product Engineering Teams: Bug Triage, Design Reviews, Remote Agents, Strategic Documents, and Release Evidence article is a focused companion for Demo Evaluation Evidence because a controlled customer demo should be evaluated with product-engineering evidence such as design-review notes, release-readiness artifacts, and human review, which this target specifically covers.
Define evidence capture as a required artifact, not an afterthought
Recommendation: maintain a compact evidence folder beside the prototype branch so every reviewer can trace the demo from input to output without reopening sensitive source systems. The folder should not contain raw recordings, full email threads, private spreadsheet exports, API keys, access tokens, production database dumps, or regulated personal data. It should contain reviewed excerpts, redaction notes, synthetic fixture descriptions, approval records, and review outcomes.



Requirement candidate
Evidence
Confidence
Engineering question
Approval gate









Evidence item
Purpose
Minimum safe content
Do not include




Source manifest
Shows which authorized sources informed the demo.
Source type, owner, permission status, date received, retention date, redaction status.
Unredacted call recordings, complete private threads, secrets, health data, payment data, or unnecessary identifiers.


Scope contract
Separates prototype behavior from production commitments.
Approved use case, out-of-scope functions, demo-only assumptions, human approval requirements.
Promises about delivery dates, integrations, pricing, legal terms, or production availability unless separately approved.


Fixture ledger
Explains what data appears in the HTML prototype.
Synthetic vehicle IDs, anonymized workflow labels, sample statuses, mapping from business concept to fake field.
Real credentials, real customer identifiers, private financial fields, or live operational records.


Review log
Records who reviewed privacy, accuracy, accessibility, and engineering implications.
Reviewer role, review date, decision, required fixes, residual risks.
Casual chat approvals that cannot be audited or ambiguous “looks good” notes without a decision.


Customer-session notes
Captures feedback as evidence rather than commitments.
Questions asked, objections, desired workflow changes, explicit customer corrections.
Automatic CRM updates, unapproved follow-up messages, or commitments made without authorization.



Codex can help generate a checklist, summarize a redacted source manifest, and compare prototype screens against acceptance criteria, but human reviewers must decide whether evidence is sufficient. OpenAI’s safety best-practices guidance emphasizes human oversight for higher-risk uses; in this workflow, customer communications, requirements decisions, and engineering commitments are consequential enough to require named human approval.
Recommended evidence folder structure:

demo-evidence/
  00-scope-contract.md
  01-source-manifest.csv
  02-redaction-notes.md
  03-fixture-ledger.csv
  04-review-log.md
  05-session-feedback.md
  06-engineering-handoff.md
  07-deletion-retention-log.md
Assign reviewer roles with explicit decision rights
A demo can fail because the wrong person approved the wrong thing. Avoid generic “team review” language and assign decision rights before the customer session. The sales lead can confirm that the demo tells the right discovery story, but should not approve data handling. The privacy reviewer can approve redaction, but should not convert the demo into production requirements. Engineering can accept or reject feasibility assumptions, but should not be pressured by customer-session enthusiasm into treating mock HTML as implementation design.



Reviewer role
Primary decision
Required check
Stop condition




Account owner or sales lead
Whether the demo addresses the approved discovery goal.
Customer workflow, terminology, pain points, and agreed meeting objective.
The demo introduces unapproved features, makes pricing or timeline commitments, or implies live integration.


Privacy or security reviewer
Whether the packet uses only authorized, minimum-necessary, properly redacted or synthetic data.
Source manifest, redaction notes, fixture ledger, screenshots, browser-visible text.
Secrets, regulated data, unnecessary personal data, unapproved recordings, or customer-private values appear anywhere.


Product reviewer
Whether the demonstrated workflow is coherent and not misleading.
User journey, feature naming, assumptions, edge cases, and product boundaries.
The prototype suggests an existing capability that does not exist or hides material product limitations.


Engineering reviewer
Whether the handoff is testable and feasible enough for planning.
Acceptance criteria, open questions, dependencies, non-goals, integration assumptions.
The packet lacks source references, contains vague “AI magic” requirements, or assumes production writes without architecture review.


Customer-facing presenter
Whether the session can be run safely without improvising commitments.
Talk track, disclaimers, feedback prompts, escalation path, note-taking plan.
The presenter cannot explain which data is synthetic, which behavior is mocked, or what requires further review.



Operational rule: no one reviewer should approve every dimension unless the organization is small enough that roles overlap by necessity. Even then, the review log should record which hat the person wore for each decision. This prevents later confusion when a prototype moves from customer conversation to roadmap consideration.
Run demo fidelity checks against the source manifest
Demo fidelity means the prototype reflects the authorized customer workflow without copying sensitive customer data or overstating product capability. A high-fidelity workflow can still use low-risk fixture data. For example, a fleet-management demo can show “Vehicle A requires inspection after route exception” without using a real vehicle identification number, driver name, exact address, or private maintenance record.

Trace every screen to a source or assumption. Each page, table, chart, workflow state, or notification should map to the source manifest, a synthetic fixture entry, or an explicit product assumption.
Mark mocked behavior visibly in the handoff. If a button does not submit to a backend, the engineering packet should state that it is a static demonstration control, not an implemented action.
Compare terminology against customer language. Use the customer’s authorized workflow labels where allowed, but avoid copying private internal names that were not approved for reuse.
Check edge cases. Include at least one empty state, one exception state, and one reviewer-required state so the demo does not imply that every record is clean.
Separate “observed need” from “proposed solution.” A call note may support the need for exception tracking; it does not automatically justify a specific integration, automation, or alerting mechanism.

Use Codex as a comparison assistant only after the data packet is safe. A suitable instruction is to ask for a traceability matrix between the static HTML screens and the redacted acceptance criteria. Do not ask Codex to retrieve unapproved email threads, browse provider systems, or infer missing customer facts from memory.
Sample prompt for a local, redacted review:

You are reviewing a static HTML customer-demo prototype.
Use only the files in this local workspace.
Do not infer facts from outside the source manifest.
Create a traceability table with:
- prototype screen or component
- source-manifest reference or fixture-ledger reference
- acceptance criterion
- mocked behavior
- privacy risk
- reviewer question
Flag any screen that lacks a source, assumption, or fixture reference.
Complete privacy and security review before showing the prototype
Privacy review is not limited to the source files. Inspect rendered pages, screenshots, filenames, comments, browser titles, alt text, embedded JSON, local storage, image metadata, and build artifacts. Static prototypes often leak context through labels such as customer names, internal project nicknames, route numbers, or spreadsheet column headings that survived a quick redaction pass.
OpenAI’s plugin documentation states that plugins can package skills, connected apps, and templates, but installation does not bypass provider authorization or workspace permissions. Apply that principle directly: a connected app may make context easier to use, but it does not grant permission to collect more than the customer approved, ignore provider role restrictions, or reuse private content for a separate purpose.

No secrets: remove API keys, OAuth tokens, service-account identifiers, private repository URLs, production hostnames, and copied authorization headers.
No regulated or unnecessary personal data: avoid health, payment, financial, government ID, precise location, youth-related, employment-sensitive, or other high-risk fields unless a qualified internal process has explicitly approved handling and controls.
No unapproved recordings: use only authorized notes or excerpts from customer-approved recordings, and prefer summarized, redacted context when possible.
No production writes: do not connect the prototype to live CRM, ticketing, billing, fleet, messaging, document, or database systems.
No silent customer communication: Codex must not send emails, update customer portals, post to Slack, create tickets, or schedule meetings without authorized human review.

The privacy reviewer should record an explicit result: approved for internal review, approved for customer session, approved only after listed fixes, or rejected. “Approved for customer session” should mean the displayed prototype, the fixture data, and the talk track have all been checked, not merely that the code repository looks clean.
Check accessibility and presentation quality without treating the demo as production-ready
Accessibility review for a prototype should focus on preventing avoidable exclusion and misleading polish. A static HTML demo does not need to satisfy every production standard before a discovery session, but it should avoid obvious barriers that prevent customers, internal reviewers, or assistive-technology users from understanding the workflow. At minimum, check keyboard navigation, visible focus states, text contrast, semantic headings, table labels, form labels, button names, and meaningful alt text for non-decorative images.



Check
Prototype-level expectation
Failure example
Fix




Keyboard navigation
Reviewer can move through controls in a logical order.
A modal opens and traps focus without a clear close control.
Use standard buttons, visible focus styles, and predictable tab order.


Contrast
Important text and status labels remain readable in the meeting environment.
Light gray exception text on a white background.
Increase contrast and avoid relying only on color.


Semantic structure
Headings and tables communicate the workflow hierarchy.
A table is built from unlabelled div elements.
Use headings, table headers, labels, and descriptive section titles.


Screen-reader names
Buttons and controls have understandable names.
A button labelled only “Go” or an icon with no accessible name.
Use specific labels such as “Review route exception” or “Open maintenance summary.”



Accessibility findings should be included in the handoff because they often reveal product requirements, not just presentation defects. If a customer needs route-exception review in a noisy warehouse or on a tablet in a vehicle yard, readability, control size, and offline-state language may become real requirements for engineering discovery.
Plan rollback, deletion, and retention before the demo leaves the workspace
A controlled demo should be easy to dismantle. Rollback means you can stop using the demo, remove it from customer-facing circulation, revoke access to any temporary workspace, and preserve only the approved evidence needed for follow-up. Deletion means unnecessary local copies, exported files, screenshots, raw notes, and generated artifacts are removed according to the retention rule defined before collection. Retention means the organization keeps a narrow, justified record of what was shown and why.
Rollback steps for a flawed or outdated demo
Recommendation: use a written rollback checklist whenever a reviewer finds a privacy issue, misleading capability, customer correction, or engineering infeasibility. A rollback is not a failure of the process; it is the control that keeps a prototype from becoming an accidental commitment.

Stop presentation use. Mark the demo “not approved for customer use” in the project tracker or review log.
Disable sharing paths. Remove public links, shared drives, exported ZIPs, meeting attachments, and screenshots that are no longer approved.
Preserve the review evidence. Keep the minimal review log, source-manifest references, and issue description needed to explain the rollback.
Notify affected internal stakeholders. Tell the account owner, presenter, product reviewer, and engineering reviewer that the demo has been withdrawn.
Correct or delete the artifact. Fix the prototype only if the scope contract remains valid; otherwise archive the decision and delete the disposable branch according to policy.
Do not notify the customer automatically. Any external message must be drafted, reviewed, and approved by an authorized human.

If the rollback is triggered by exposed credentials, regulated information, or unauthorized customer data, escalate through the organization’s security and privacy process rather than treating it as a routine prototype bug. Do not paste the exposed material into additional prompts, tickets, or chats while trying to diagnose the issue.
Deletion and retention procedure
Deletion rules should be specific enough that a junior team member can execute them safely. “Clean up files later” is not a retention policy. Define which artifacts are deleted immediately after the session, which are retained until engineering triage completes, and which are retained as a minimal audit record. The safest default is to retain the decision record and synthetic requirements while deleting raw or unnecessary customer-derived material.



Artifact
Suggested disposition
Reason
Approval needed to retain longer




Raw call recording or transcript
Do not place in the demo workspace unless explicitly authorized; delete exported copies when no longer required.
High context density and possible personal or confidential content.
Privacy, legal, or account owner approval according to company policy.


Full email thread export
Avoid storing; use approved excerpts or summary notes instead.
Email threads often contain unrelated parties, signatures, attachments, and confidential side discussions.
Privacy or security approval.


Customer spreadsheet export
Replace with synthetic fixture data whenever possible; delete original export after extraction and review.
Spreadsheets frequently contain hidden columns, formulas, identifiers, or operational data beyond demo scope.
Data owner and privacy approval.


Static HTML prototype
Retain only the approved version or delete after the sales cycle if no longer needed.
Prototype may contain customer-specific workflow language or implied commitments.
Account owner and product approval.


Engineering handoff
Retain in the product planning system if accepted by engineering.
Becomes a business artifact for requirements discovery.
Engineering owner.



Record deletion as an affirmative act. The deletion-retention log should include what was deleted, who deleted it, when it was deleted, what remains, and why the remaining material is justified. Do not include the sensitive content itself in the deletion log; include a description such as “unredacted customer spreadsheet export received on approved date” rather than copying rows or identifiers.
Handle errors and define stop conditions before the customer session
Most demo failures are manageable if the team has pre-agreed stop conditions. The presenter should know when to pause, when to say “we need to verify that,” when to withdraw a screen, and when to escalate internally. This is especially important when a prototype is generated quickly from discovery context, because speed can compress normal review cycles.
Error handling during build and review

Codex generates unsupported content: remove the content, add a review-log entry, and update the prompt or source packet so unsupported claims are not regenerated.
A screen contains real customer data: stop review, remove the data, inspect build artifacts and screenshots, and ask the privacy reviewer whether escalation is required.
A connected-source permission is unclear: do not use the source until the provider permission, workspace policy, and customer authorization are confirmed.
The prototype implies an automated action: relabel it as mocked behavior or remove it until product and engineering approve the concept.
The customer corrects a core assumption: capture the correction as feedback, avoid arguing from the prototype, and route the update to engineering only after triage.
A reviewer cannot complete their check: treat the review as incomplete; absence of review is not approval.

OpenAI’s Codex approvals and security guidance describes sandboxing and approval policy as separate layers, with local workspace-write mode defaulting to no network access. Apply the underlying lesson conservatively: do not rely on a single control. Use isolated files, no live production credentials, restricted network posture where available, human approvals, and manual review before any customer-facing use.
Stop conditions that require pausing the workflow



Stop condition
Immediate action
Who decides restart?




Unauthorized source material is discovered.
Stop processing, isolate the artifact, and escalate to the privacy or security owner.
Privacy or security reviewer.


Secrets or production credentials appear in files, logs, screenshots, or prompts.
Stop work, avoid further copying, follow credential-rotation and incident procedures.
Security owner.


The demo requires production writes or live customer-system access to appear convincing.
Reject the approach and redesign as static, read-only, synthetic, or separately approved integration work.
Engineering and security owners.


A customer asks for a commitment during the session.
Capture the request and state that it requires internal review.
Authorized commercial, product, or legal owner depending on the commitment.


The prototype may affect legal, financial, health, employment, safety, or other high-stakes decisions.
Stop using it as a demo unless a qualified governance process has approved the scope and controls.
Appropriate qualified reviewer, such as legal, compliance, security, or domain expert.



The presenter’s safest phrase is simple: “This prototype is a controlled demonstration based on approved discovery context; we will verify that request before treating it as a product commitment.” That sentence preserves the value of customer feedback without turning a mock interface into a binding representation.
Run a 30-day local evaluation instead of assuming transferable outcomes
OpenAI reports that Proaction uses Codex to create customized demos from authorized customer context and attributes specific business results to that customer story, including four to six customized demos per month, 30–45 minutes per demo, estimated 40–60 engineering hours avoided monthly, and an estimated 50%–60% increase in deals moving from initial contact to solution development rather than nurture. Those figures are source-reported customer-story metrics, not benchmarks that another team should expect to reproduce.
A 30-day evaluation lets your organization determine whether the workflow is useful under your constraints, with your customers, data policies, sales process, review capacity, and engineering standards. The goal is not to prove that AI demos always improve conversion. The goal is to decide whether a controlled, permissioned prototype process produces better discovery, fewer ambiguous requirements, and lower engineering interruption than your current approach.
Define the evaluation cohort and baseline
Choose a small cohort of opportunities where a customer-specific workflow demo is appropriate and authorized. Exclude accounts that require legal review you cannot complete, sources you cannot safely redact, regulated data you cannot handle, or workflows that require live production access to demonstrate. A clean evaluation cohort is more useful than a large, messy one.



Measurement
How to collect it
Why it matters
What not to claim




Preparation time
Track human time spent on permission review, redaction, prototype generation, and review.
Shows whether the controlled workflow is operationally sustainable.
Do not compare to Proaction’s reported figures as if they are guaranteed.


Engineering interruption
Log engineering hours requested before and after prototype review.
Shows whether the demo packet reduces premature engineering work.
Do not count avoided hours unless engineering agrees the work would otherwise have occurred.


Review defect rate
Count privacy, fidelity, accessibility, and unsupported-claim issues found before customer presentation.
Shows whether controls are catching problems.
Do not treat fewer reported defects as safer if review quality also decreased.


Customer clarification quality
Record whether the customer corrected assumptions, ranked needs, or clarified workflow steps.
Shows whether the prototype improves discovery.
Do not treat a positive meeting reaction as a signed commitment.


Engineering handoff acceptance
Ask engineering to classify packets as accepted, needs revision, or rejected.
Shows whether the handoff is actionable.
Do not merge code, create roadmap promises, or deploy from the demo branch.



Use a simple 30-day evaluation calendar

Days 1–3: governance setup. Finalize the source manifest template, scope contract, review log, stop conditions, retention rule, and reviewer assignments.
Days 4–10: first controlled build. Select one authorized opportunity, create redacted or synthetic fixtures, generate the static HTML prototype, and run the full review process.
Days 11–17: customer-session test. Present only after approval, capture feedback as evidence, and avoid automated follow-up or CRM writes unless separately approved.
Days 18–23: engineering handoff test. Convert feedback into an engineering-owned requirements packet and ask engineering to accept, revise, or reject it.
Days 24–27: second build or controlled repeat. Apply lessons to another eligible opportunity or rerun the process with a revised packet.
Days 28–30: decision review. Compare preparation time, defect rate, customer clarification quality, and engineering acceptance against the baseline.

The decision at day 30 should be one of four outcomes: continue with the same controls, continue with stricter controls, limit the workflow to internal discovery only, or stop using the workflow. A “continue” decision should include named owners for privacy review, engineering acceptance, and deletion logs; otherwise the process will drift into informal demo generation without evidence.
30-day evaluation decision memo outline:

1. Evaluation cohort
2. Sources used and authorization status
3. Number of prototypes attempted
4. Number approved for customer session
5. Review defects found before presentation
6. Customer clarifications captured
7. Engineering handoff outcomes
8. Time spent by role
9. Privacy/security incidents or near misses
10. Retention and deletion completed
11. Decision: continue, restrict, internal-only, or stop
12. Required changes before next cycle
Final operating checklist for a controlled Codex customer demo
Use this final checklist before the prototype is shown externally or handed to engineering. It is intentionally conservative because the workflow blends customer discovery, generated code, connected-source context, and commercial expectations. The checklist is not a substitute for your organization’s privacy, security, legal, procurement, accessibility, or engineering policies.

The customer context was authorized for this demo purpose.
The packet uses the minimum necessary source material.
Raw recordings, full email exports, secrets, regulated data, and unnecessary identifiers are excluded.
Spreadsheets were inspected for hidden columns, formulas, metadata, and unrelated records before use.
Synthetic or redacted fixture data is documented in a fixture ledger.
The prototype is static, isolated, read-only, and disconnected from production writes.
Any plugin or connected app use respects provider authorization, workspace policy, role permissions, and supported actions.
Codex was not authorized to send messages, update CRM, merge code, deploy, make purchases, change permissions, or take other consequential actions.
The scope contract distinguishes demonstrated behavior, mocked behavior, assumptions, and out-of-scope functionality.
Privacy, fidelity, accessibility, product, and engineering reviews are recorded with named decisions.
The presenter can explain what is synthetic, what is mocked, and what requires future validation.
Customer feedback will be captured as evidence, not treated as an automatic product commitment.
The engineering handoff is owned by engineering and includes acceptance criteria, open questions, source references, and non-goals.
Rollback, deletion, and retention actions are assigned to named owners and verified after the demo cycle.
The team measures its own outcomes and does not treat Proaction’s reported results as a forecast or guarantee.

OpenAI’s Proaction customer story attributes four to six customized demos per month, 30 to 45 minutes per demo, an estimated 40 to 60 engineering hours avoided monthly, and an estimated 50% to 60% increase in deals moving from initial contact to solution development rather than nurture. Those are reported observations from one customer story, not transferable performance guarantees. A local team must establish its own baseline, inspect quality and rework, and stop the workflow when privacy, security, customer-authority, accessibility, or engineering-review conditions are not met.
A controlled customer-specific demo is therefore a reviewable artifact, not a production deployment or an automated commercial commitment. Use only authorized context, keep the prototype isolated, preserve the source and fixture ledgers, obtain customer permission for the intended demonstration, and require human review plus engineering approval before any requirement becomes a build decision. Plugins and connected apps remain subject to provider authorization, workspace policy, supported actions, and approval requirements; installation does not bypass those controls.

Access 40,000+ AI Prompts for ChatGPT, Claude & Codex — Free!
Subscribe to get instant access to our complete Notion Prompt Library — the largest curated collection of prompts for ChatGPT, Claude, OpenAI Codex, and other leading AI models. Optimized for real-world workflows across coding, research, content creation, and business.
Access Free Prompt Library →
Useful Links

OpenAI: Proaction customer story
OpenAI Help Center: Plugins in ChatGPT and Codex
OpenAI Developers: Codex CLI
OpenAI Developers: Agent approvals and security
OpenAI Developers: Safety best practices





  
  
  

  


    

    

      
      
      
      
      

      Please leave this field empty



Infrastructure & EngineeringInsight & AnalyticsGovernance, Privacy & EthicsProduct & StrategyAdministration & ManagementFinance & AccountingSales & MarketingOperations & ProductionHuman ResourcesInformation TechnologyKnowledge Seekers & CreatorsEnthusiasts & Specialized UsersStudentHousehold ManagerInfluencerResearcher


      

        
Thank you! Please check your inbox (and spam folder) for a confirmation email. Click the link to get instant access to our 40,000+ ChatGPT Prompt Library.Check your inbox or spam folder to confirm your subscription.
        
        
        
      
    

      

    
  
  

  


    

    

      
      
      
      
      

      Please leave this field empty



Infrastructure & EngineeringInsight & AnalyticsGovernance, Privacy & EthicsProduct & StrategyAdministration & ManagementFinance & AccountingSales & MarketingOperations & ProductionHuman ResourcesInformation TechnologyKnowledge Seekers & CreatorsEnthusiasts & Specialized UsersStudentHousehold ManagerInfluencerResearcher


      

        
Thank you! Please check your inbox (and spam folder) for a confirmation email. Click the link to get instant access to our 40,000+ ChatGPT Prompt Library.Check your inbox or spam folder to confirm your subscription.
        
        
        
      
    

          
      

    
  
  

  


    

    

      
      
      
      
      

      Please leave this field empty



Infrastructure & EngineeringInsight & AnalyticsGovernance, Privacy & EthicsProduct & StrategyAdministration & ManagementFinance & AccountingSales & MarketingOperations & ProductionHuman ResourcesInformation TechnologyKnowledge Seekers & CreatorsEnthusiasts & Specialized UsersStudentHousehold ManagerInfluencerResearcher


      

        
Thank you! Please check your inbox (and spam folder) for a confirmation email. Click the link to get instant access to our 40,000+ ChatGPT Prompt Library.Check your inbox or spam folder to confirm your subscription.