An automated document may draw from a shared record containing an approved project update, an internal concern and a suggested negotiation position. All three can be useful to staff, but they do not belong in the same audience version. A fluent paragraph can blur that distinction unless the input and template make it explicit.
The proposed design here uses visibility fields and two reviewed outputs. It keeps authorised internal notes available without allowing them to flow into the client draft. This is an audience-boundary workflow, rather than a general redaction task: the system knows which fields are approved for the client before composing that version.
Assign audience visibility to facts and comments
Create a field inventory for the source record. Mark approved client facts, internal-only notes and unresolved material separately. A field labelled comment is too vague; the label does not establish who may receive it. Use a reviewed visibility value and identify who can change that value.
An internal note should not become client-safe because the assistant paraphrases it. For example, a staff concern about an unreliable supplier may remain internal even when rewritten politely. Conversely, an approved delay explanation may legitimately appear in the client version. The owner decides the content boundary, and the template implements it.
Keep approval status distinct from visibility. A fact can be intended for a client but still unconfirmed. Require both an approved audience and an approved factual status before placing it in the client allowlist. Unresolved dates and disputed explanations should follow a hold rule rather than becoming confident prose.
Use separate templates with an explicit input contract
OpenAI's Structured Outputs guide documents schema-constrained responses and refusals. It can support explicit fields for audience, approval status, source reference and text. The schema does not determine that a field's visibility label is truthful or that the generated wording contains only permitted facts. Source: OpenAI structured outputs
Populate visibility and approval from the trusted record or review process. Let the model assist with approved wording within the permitted fields. The client-generation step should receive only what it needs where feasible, reducing dependence on an instruction to ignore internal material already present in context.
Do not use hidden text, collapsed comments or formatting to protect internal notes in a client file. Those features may remain accessible in downloads or alternative views. Build separate outputs and inspect the actual export, rather than sharing a single document with internal sections visually concealed.
Audience-safe document output contract
Use this complete proposed contract for a fictitious project update. The example contains an approved milestone, an internal risk note and an unconfirmed future date.
| Source field | Visibility and status | Internal document | Client document |
|---|---|---|---|
| project_reference | Internal reference; approved | Include permitted reference | Include only the approved client-facing reference |
| completed_milestone | Client-permitted; approved with source M01 | Include fact and source reference | Include approved plain-language completion statement |
| next_action | Client-permitted; approved with source M02 | Include action and accountable owner | Include approved action relevant to the client |
| internal_risk_note | Internal-only; reviewed for team use | Include within restricted risk section | Exclude entirely, including paraphrases and hints |
| negotiation_position | Internal-only; proposed | Keep as a staff proposal, clearly unapproved | Exclude entirely |
| proposed_completion_date | Client-intended but unconfirmed | Show unresolved status and decision owner | Exclude the date; use only an approved statement that timing is awaiting confirmation |
| source_links | Role-restricted | Include permitted internal references | Include only separately approved client-accessible links |
Internal template: Project reference; approved progress; proposed next steps; internal risks; unresolved facts; source register; review owner. Restrict the document and notifications to the approved project team.
Client template: Approved client reference; approved milestone statement; approved next action; approved timing statement; agreed contact route. No internal sections, source-message excerpts, negotiation notes or unrestricted links. For this fictional example, the draft reads: “The review stage is complete. We are preparing the agreed next action. Timing for the following stage is awaiting confirmation, and the designated team will provide an approved update.” Those statements require the corresponding approved sources; the wording is not permission to use it for an unrelated project.
Release checks: Compare every client sentence with the allowlisted fields and sources. Inspect the rendered document, comments, tracked changes, title, author metadata, attachment names, embedded content and links. Confirm the intended recipient list and exact file version. Creation produces an unsent draft; release follows the separate sending process.
Acceptance fixtures: a normal approved update; a record containing an internal risk phrase in several fields; a missing visibility label; duplicate milestone records with conflicting status; and an attachment containing internal comments. The normal case produces the approved client statements. The other cases exclude the internal material or hold the affected output until a reviewer resolves the gap.
The contract is accepted when both templates preserve their purpose, the client version contains only approved content and the reviewer can explain every inclusion. Record the checked version and audience so later edits do not inherit an approval that applied to different text.
Inspect export surfaces that can undo separation
A clean body paragraph is only part of the document. A filename can carry an internal risk label; a source link can expose a private thread; tracked changes can reveal deleted notes. Review the actual file or rendered message the recipient will receive, not only the assistant's intermediate JSON.
Check copied attachments separately. The proposed workflow excludes unreviewed attachments by default. If the client needs an attachment, its audience and factual status must be approved through the same process. A permitted link in the internal document does not automatically become a permitted client link.
Also test the client-generation input. If the allowlist is correct but the application sends the entire internal record to the model, the design still depends on the model ignoring unnecessary material. Minimise that input where possible and document any remaining exposure for the information owner.
Keep provider handling separate from client visibility
OpenAI's data-controls guide distinguishes abuse-monitoring logs from application state and describes endpoint-specific conditions. Excluding a note from the client output does not establish that it was never sent to a provider or retained elsewhere. Review the actual processing path and local copies separately. Source: OpenAI data controls
The visibility contract answers who may receive a particular output. It does not replace the organisation's decisions about source access, provider processing, storage or deletion. Record those responsibilities without claiming that one client-safe template solves the whole information-handling question.
Work through normal, missing and duplicate records
In a hypothetical normal case, the source contains one approved milestone and one approved next action. The internal document includes the team's restricted risk note; the client draft uses only the allowlisted progress fields. The reviewer checks both rendered versions and approves the exact client text for the separate release step.
In a missing-label case, a new comment arrives without a visibility value. The workflow holds that content rather than assuming that an ordinary-sounding sentence is client-permitted. The designated owner classifies it and, if appropriate, supplies factual approval before the client version is regenerated.
In a duplicate case, two milestone entries have different completion statuses. The application reports the conflict and holds the affected claim. It does not select the newest-looking sentence or merge the statuses into a reassuring update. The project owner determines the authoritative record.
Separate generation from sending
OpenAI's function-calling guide separates a model request from application execution and returned output. Apply that distinction to document release: creating a draft, approving it and sending it are separate observed actions. Source: OpenAI function calling
An approved document still needs the intended recipient and version checked by the sending process. If text changes after review, require the appropriate new review before release. If sending has an uncertain outcome, investigate the existing operation before retrying and risking duplicate messages.
FAQ about internal and client document versions
Is a visibility label enough to prevent leakage?
No. The application must enforce the allowlist and the reviewer must inspect the actual output surfaces. Labels supplied by untrusted content or guessed by a model are not authoritative classification.
Can we paraphrase an internal risk note for the client?
Only after the responsible owner approves that separate client-facing content. Polite wording does not change the note's audience or approval status. The proposed client template excludes internal-only facts and their paraphrases.
What if the client draft needs an unconfirmed date?
Hold the date and request the authorised decision. Use a statement about awaiting confirmation only if that statement is itself approved. Do not manufacture a date to complete the template.
If your business needs help defining this process, explore Document processing, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.