Synthetic planning example · WEB-038

From agreed details to a reviewable proposal

All records, names and rules here are invented. This is a static demonstration, not a client result or a working document system.

Starting inputs

Approved project record: P-104, revision 1: customer “Example Company”; scope “Reporting workshop”; delivery date “20 October”.
Approved template: T-03, revision 3. The customer, scope and date fields come from the project record; the surrounding wording comes from the template.
People in this example: The coordinator maintains the project record. The delivery lead agrees its delivery date and reviews the generated proposal. The template owner maintains approved wording.

The rule and the first output

Generate only when all three fields are present and both the record and template are approved. Save the exact source revisions with a new document version. A generated version starts as “Awaiting review”.

Template: “Proposal for [customer]: [scope]. Delivery date: [date].”

Proposal for Example Company: Reporting workshop. Delivery date: 20 October.

This is document version 1, created from P-104 revision 1 and T-03 revision 3.

Sample version history

Version 1 — returned for correction

Source: P-104 revision 1 · Template: T-03 revision 3

The delivery lead returns the draft: “Move the workshop to 27 October.” The saved version still says 20 October. The reason and reviewer stay with it.

Source revised — new date agreed

Source: P-104 revision 2 · Template unchanged

The coordinator changes the record to 27 October. The delivery lead agrees the new source details before another document is generated.

Version 2 — awaiting its own review

Source: P-104 revision 2 · Template: T-03 revision 3

New output: “Proposal for Example Company: Reporting workshop. Delivery date: 27 October.” Version 1 is retained. Its review cannot approve version 2.

Version 2 — approved

Same saved document version; no content change

The delivery lead reviews and approves version 2. Keep who approved it and when with this exact saved copy. Storage, reading access and authority to send are separate checks.

When generation must stop

Remove the date from the same record. Expected result: no new document and a request to the coordinator to complete the date. Do not copy 20 October from an earlier proposal as a fallback. An unapproved record or template also stops generation.

If someone edits only a downloaded copy, review the change before making another draft. The coordinator updates agreed project details in the source record; the template owner handles changes to shared wording. A required content change after approval creates a new version and a new review; it does not overwrite the approved copy.

Generation and review states

Approved record and template, completeness check, generated numbered draft, review, approval of the exact version, then a separate access and sending check. Returned edits go back to the approved sources. — Missing or unapproved inputs stop generation. Returned edits go back to the source or template, are agreed, and produce a new version for review.

What this example proves

A separate check produced both expected drafts and kept their source versions. It stopped when the date or input approval was missing. It also rejected an attempt to approve the older draft. It tests this invented rule only. It does not test a live product, document permissions, simultaneous edits, delivery or recovery after a system failure.

For your own trial, keep each version, its source and template revisions, the change reason, the person making it, and the reviewer’s decision and time. Ask the process owner to check the complete document, not just the filled fields.

Back to the article