Create a Permissioned Migration Proof Pack Without Exposing Customer Data

Assemble version-bound migration evidence, a sanitized derivative and separate written sharing decisions before releasing a narrowly supported engineering claim.

1. Start with the claim a reader could reasonably infer

Create a proof pack when you have a delivery result worth explaining and need to share it beyond the team that produced it. Keep restricted evidence, the publishable derivative and the authority to share that derivative as three separate records. A technical reviewer can establish that a calculation follows the supplied measurements. That reviewer cannot grant a customer's publicity rights merely by accepting the calculation.

Write the proposed sentence first. “A migration reduced processing time by 25%” leaves the workload, measurement window, sample and meaning of processing time unresolved. A narrower statement might describe total elapsed time for twelve defined rehearsal cases under a fixed test configuration. It may be less dramatic, but a buyer can understand what was measured and what would need testing in their own system.

This procedure owns the transition from internal evidence to a permissioned sharing package. Engineering acceptance evidence owns whether a delivery result is supported and accepted internally. Engineering partner evaluation helps buyers assess supplier proof. Use those records as inputs rather than repeating their acceptance process here.

The worked pack below is entirely fictional. Its measurements, source records and permission decisions are synthetic test inputs. No customer result, AWS operation, contractual interpretation, actual disclosure scan or production performance test was performed. This is an engineering procedure, not legal advice. The customer's authorized decision makers and your legal or rights owner resolve actual sharing rights.

2. Give each decision an owner and a version

The evidence-release owner assigns a pack ID and a revision before collecting material. Record the proposed audience, channel, release date, review date and withdrawal contact. “Sales use” is too broad if the intended destinations include a public website, a prospect email and a downloadable PDF. Those destinations have different copy and access consequences.

The measurement owner explains how each result was obtained. The technical reviewer checks the calculation and whether the proposed wording overstates that result. The disclosure reviewer checks the material that will leave the restricted boundary. The authorized sharing decision owner resolves permission for customer information and any third-party material. The publication operator deploys only the frozen derivative and records its destinations.

One person may perform several roles in a small team. Preserve the decisions separately, and apply the separation of duties required by the engagement. An account manager's informal recollection of a conversation does not fill an absent written decision. If the authority of the purported approver is unclear, put the affected material on HOLD and ask the rights owner to resolve it.

The output is a responsibility record tied to the pack revision. Permission to access a customer environment, payment for a project and acceptance of delivered work do not by themselves establish permission to publish metrics, architecture or a logo. The playbook does not infer rights from any of those events.

3. Freeze the measurement boundary before choosing a headline

For every proposed claim retain the metric definition, unit, aggregation, baseline and comparison configurations, observation windows, included population, excluded population, sample count and source revision. Record failures and missing observations alongside successes. If the denominator changed between baseline and comparison, either reconcile the population explicitly or stop the comparison.

An average needs its weighting rule. A percentile needs a sample and a calculation method. A percentage reduction needs a nonzero baseline and the direction of improvement. A cost result needs a currency, time basis and treatment of commitments, credits, overlap and retained resources. A measured technical change does not automatically establish a financial saving or a causal business outcome.

The measurement owner links the private evidence through opaque record IDs. Keep actual account identifiers, customer names, environment URLs, invoices and raw logs in the controlled evidence store. Record the full hash or version there where policy permits. A hash identifies bytes; it does not prove that the measurement was honest, representative or authorized. Restrict even reference metadata when identifiers or the existence of a project are sensitive.

Gate: the technical reviewer can reproduce the declared aggregation and explain every exclusion. Missing windows, unresolved failures, incompatible task sets or unverifiable denominators remain HOLD. Ask the reviewer to approve the exact claim text and limitations, not a general permission to “use the project.”

4. Classify the material before copying it

Review the original material with its data owner. AWS Well-Architected data classification guidance calls for understanding data, handling requirements, storage and ownership. Apply the customer's classification and contractual rules to source exports, diagrams, screenshots and proposed derivatives. A public-looking dashboard is not automatically public data.

Make an inclusion list for the derivative. A result may need a metric definition, normalized totals and limitations, without raw event bodies or resource names. A useful architecture view may need trust and dependency boundaries but not exact subnet ranges, account numbers, security policy text or customer-specific integration names. Remove a component if its presence would reveal an unapproved business relationship.

Inspect filenames, document properties, hidden spreadsheet sheets, speaker notes, comments, revision history, embedded files, image text and hyperlinks. Blurring a screenshot does not review the underlying PDF text layer. Rebuilding a chart from approved aggregates is usually easier to inspect than altering a screenshot of a customer console. Keep enough context to avoid misleading readers; if that context cannot be shared, withdraw the claim or use a separately labelled generic reference design.

Output: an approved-field list and transformation plan. Hold: necessary context cannot be disclosed, or the planned abstraction could identify the customer when combined with public information. A customer's name being absent is only one disclosure check.

5. Produce a derivative that can be inspected independently

Work in a staging area separate from the originals. Copy only the approved fields into a new artifact, rather than placing a full customer folder beside a publishable summary. Record each source revision, transformation, reviewer and derivative revision. Preserve the original measurement meaning when rounding or grouping values. If you replace a diagram with a generic design, say that it is illustrative and no longer the customer's deployed topology.

Use tools for checks they can perform. An allowlist can reject unexpected fields. A secret detector can identify patterns it knows. File inspection can enumerate embedded links and attachments. A comparison can detect a changed source revision. None of those tools can decide whether a distinctive workload description reveals a customer or whether an approver has the required authority.

Amazon Macie offers sensitive-data discovery for S3, including sampled automated discovery and scoped jobs. Its analysis depends on supported objects and access, including key access for encrypted data. If used, retain the actual inspected scope and exceptions. A result covering selected S3 objects is not clearance for an entire pack, an uninspected attachment or contractual sharing rights. Do not move restricted evidence into a new service solely for this procedure without authorization.

The telemetry sensitive-data audit owns deeper investigation of capture points and downstream copies. Use it when evidence reveals a collection problem. Sanitizing a marketing derivative does not remediate the original telemetry leak.

*Conceptual evidence lineage. Only approved information is transformed into the derivative; originals remain private. Byte identity does not authenticate truth or rights, and unchanged rounded output does not preserve approval after a source change.*

Conceptual evidence lineage. Only approved information is transformed into the derivative; originals remain private. Byte identity does not authenticate truth or rights, and unchanged rounded output does not preserve approval after a source change.

6. Bind written sharing decisions to the exact package

Give the authorized sharing decision owner the proposed text, final derivative, audience and destinations. Ask which specific customer name, logo, testimonial, metrics, diagram and attributed statements may be used, for what purpose and duration, and what correction or withdrawal process applies. Record exclusions explicitly. Do not interpret silence as consent or assume approval for text includes a logo.

Retain the decision in the controlled system with its date, authority basis and exact derivative identity. Where several organizations own material, resolve each necessary permission. A vendor's documentation license or trademark rules may apply to its assets independently of customer permission. Obtain the relevant review instead of copying an official icon or customer logo merely because it is downloadable.

Approval has separate scopes. A technically correct claim may remain held for sharing rights. An authorized derivative may remain held because its measurement is misleading. A disclosure review may pass while the destination has changed from restricted email to an indexable public page. Require all applicable decisions to remain valid immediately before release.

Output: version-bound decisions, exclusions and expiry or review rules. Abort: the exact proposed package is outside a decision's scope. Rework the package and request a decision on the new version. Do not edit the approved artifact in place and keep its old approval reference.

*Proposed permissioned-release procedure, not actual authorization. All three decisions are required, not sequential substitutes. Tools can detect declared contract mismatches but cannot grant sharing rights. Controlled copies can be corrected or withdrawn; external copies may remain.*

Required reviews are conjunctive, not alternatives or an automatic tool result. Current source, exact claim, derivative, assets, audience, destination and time scope must match immediately before release. HOLD retains an owner and next action.

This panel follows the all-three gate above. Solid arrows carry approved derivative bytes; dashed amber relationships identify change and re-review. Correct or remove controlled copies without promising universal recall. No actual release is shown.

7. Work through a fully synthetic proof pack

The fictional pack compares the same twelve rehearsal cases across two fixed configurations. Each case uses the same agreed data and completion check. Elapsed minutes include retries during that case. They exclude preparation, migration implementation and production operation. The synthetic windows are 1 September and 2 September 2026, both 09:00 to 17:00 UTC. The illustration stipulates equivalent conditions; the offline checker cannot establish that equivalence for a real experiment.

Cases A1 to A3Baseline: 120 minutes each, 360 minutes total. Comparison: 90 minutes each, 270 minutes total.

Cases B1 to B3Baseline: 80 minutes each, 240 minutes total. Comparison: 60 minutes each, 180 minutes total.

Cases C1 to C3Baseline: 100 minutes each, 300 minutes total. Comparison: 75 minutes each, 225 minutes total.

Cases D1 to D3Baseline: 100 minutes each, 300 minutes total. Comparison: 75 minutes each, 225 minutes total.

Totals reconcile to 1,200 baseline minutes and 900 comparison minutes. The reduction is (1,200 − 900) / 1,200 = 25%. Twelve cases remain in both populations. This is a sum of elapsed case durations, not wall-clock time for a parallel migration, a production latency percentile or an annual savings estimate.

The derivative sentence is: “In a fictional rehearsal of twelve matched cases, total case elapsed time was 1,200 minutes in the baseline and 900 minutes in the comparison, a 25% reduction.” Its adjacent limitation says that the data are synthetic and establish no customer, AWS or production result. No customer name or logo appears. The fictional permission record permits only this synthetic example on the designated example channel; it grants no real-world rights.

The companion offline fixture keeps twelve pairs, the measurement boundary, a derived summary, exact source and derivative hashes, and mock review decisions. Its tests change the source, population, claim, destination, expiry and decision status. They demonstrate whether a local package agrees with its own declared contract. They do not authenticate a signature, evaluate real permission or publish anything. For an actual project, retain originals privately and assemble a separate approved derivative using the same fields.

Download the synthetic proof-pack source (ZIP)

8. Resolve holds without laundering missing evidence

When a source row changes after review, invalidate the dependent summary and claim decision. Recompute, recheck disclosure and obtain the required decisions for the new derivative. If the correction does not change the headline number, the lineage still changed and needs review. Do not use identical rounded output as evidence that the original approval remains applicable.

If one rehearsal case is missing, do not keep “twelve matched cases” in the headline. Restore the evidence or define a new, explicitly narrower population and investigate why it is missing. If the baseline is zero, a relative reduction is undefined. Choose a supported absolute difference or withhold the comparison. If a failed case was excluded from elapsed time, expose that rule and its consequence rather than silently improving the result.

If the customer permits a metric but not its identifying context, the disclosure reviewer tests whether enough context remains to interpret it. An industry, geography, uncommon topology and timing can jointly identify a project. A generic synthetic example may be the appropriate publication; label it as such and avoid presenting it as anonymized proof of delivered work.

A missing sharing decision stays held even if all automated checks pass. An unknown scan scope stays unknown. A reviewer cannot resolve a contractual conflict by changing a JSON status. The evidence-release owner records the unresolved issue, responsible decision maker and next review date, with no scheduled release of the affected artifact.

9. Separate restricted review access from public distribution

Keep private evidence in its authorized store. If using S3, review the effective access configuration rather than assuming a bucket is private from its name. S3 Block Public Access provides controls at several resource and account boundaries. Preserve the customer's security requirements; creating a public proof pack is not a reason to disable controls on the original evidence store.

For an authorized restricted review, a presigned S3 URL is a bearer token. Anyone possessing it can use the permitted operation while it remains valid. Temporary credentials can end its validity earlier than its configured expiry. Avoid putting such links in public source files, analytics, issue trackers or screenshots. Select recipient access and sharing controls for the actual sensitivity, and remember that expiring access cannot recall a downloaded copy.

Public distribution uses only the frozen approved derivative. The publication operator records the page, PDF, image, email attachment or other controlled destination, plus the derivative hash served there. Check the actual public bytes, selectable text, links and image alternatives. A screenshot of the intended page does not establish what a downloadable PDF contains.

Pass: destination, content and decision scope agree. Hold: an original, restricted URL or unapproved attachment appears in the output. Stop distribution and follow the customer's incident process if material has already escaped its boundary. Do not hide a disclosure problem by deleting only the visible page.

10. Keep correction and retention workable

Assign a review date based on evidence age, permission terms and the life of the claim. A result from a particular configuration remains tied to that configuration even when the current application changes. Update time-sensitive wording or withdraw it when the context no longer supports a fair reading. Keep a change log so old URLs and distributed files can be identified.

For a correction, pause scheduled distribution, replace controlled public copies with the approved correction and verify actual readback. Record who received restricted attachments when that tracking is authorized and necessary. For withdrawal, remove or restrict controlled copies, request third-party removal where appropriate and record unresolved copies. Never promise erasure from search caches, recipients' devices or independent archives.

Retain the restricted evidence and decision records according to the applicable customer policy and rights-owner decision. If S3 Object Lock is chosen, it protects specified object versions under retention or hold settings; it does not determine the correct retention period or create publication rights. AWS Object Lock guidance describes those controls. Review consequences before applying retention. Removing a public claim and deleting the supporting evidence are separate decisions, especially during a dispute or investigation.

The recoverable failure path is a held or corrected release, not a promise to reverse disclosure. Keep the incident, correction and future-use decisions open until their owners record closure.

11. Use a release record that another operator can follow

Keep the following record in the controlled system. Use references instead of copying restricted material into a public worksheet. Each field should name a decision or artifact that can be retrieved by an authorized reviewer.

Claim and measurement

Record the pack ID and revision; exact proposed sentence; audience and channel; metric, units and aggregation; baseline and comparison configurations and windows; population and matching rule; failure and exclusion treatment; source IDs and revisions; calculation output; limitations; and technical reviewer decision bound to the source and claim.

Derivative and disclosure

Record the approved-field list; transformation steps; exact derivative filename and hash; embedded-link and attachment inventory; scan scope, findings and uninspected surfaces; identifying-context review; disclosure reviewer decision; and any excluded customer or vendor assets. Record every HOLD with an owner and resolution evidence.

Permission and distribution

Record the written sharing decision reference; authorized decision maker and authority verification reference; allowed text, assets, audience, purpose and destinations; expiry or review conditions; withdrawal contact; final pre-release check; actual controlled copy locations and hashes; and post-release correction or withdrawal history.

This can be a form, structured document or issue record. Do not make every field mandatory for every claim, but explicitly mark a field inapplicable with a reason. Empty, unknown and inapplicable must not collapse into the same “approved” state. The local fixture provides one small inspectable example, not a production permission-management system.

12. Apply the final acceptance checklist

The evidence-release owner closes the pack only when all applicable checks have an accountable result:

• The exact sentence and adjacent limitations match reproducible measurements within the declared scope.
• Baseline, windows, units, population and missing or failed observations have been reviewed.
• Restricted originals remain controlled; derivative inspection covers the actual files to be shared.
• Technical, disclosure and written sharing decisions all identify the same current package and destination.
• No tool output is represented as proof of legal authority, universal sanitization or actual AWS execution.
• The publication operator can read back every controlled copy and identify its version.
• Expiry, evidence change, correction and withdrawal have owners, with unresolved copies recorded honestly.

If any required item fails, retain the pack as held and name the next authorized action. A useful discussion can still use a fully synthetic reference design, provided its caption and surrounding prose make that scope unmistakable. Bring a sanitized claim description and the unresolved decision to the appropriate owner; do not send raw customer evidence through a website enquiry form.