Compiled the approved client update into a Reference-Locked Production Template. The status-first sequence stays fixed while project facts become reusable, so the next update can be produced without reconstructing the format. # Reference-Locked Production Template ## Reference Locks - Deliverable type: concise client status update. - Information order: progress first, then risk, then next action, then owner. - Voice: compact, factual, operational, no promotional language. - Each item is a direct statement rather than a narrative paragraph. - Risk remains visibly separated from progress and next action. - Owner remains the closing accountability signal. ## Variable Surface PROJECT_STATUS Purpose: the current progress or completion statement. Source example: Migration is 80% complete. PRIMARY_RISK Purpose: the most important blocker or uncertainty that the client should know. Source example: vendor API delay. NEXT_ACTION Purpose: the next concrete milestone or action. Source example: staging Friday. OWNER Purpose: the accountable person or team. Source example: Maya. ## Template Blueprint 1. Open with one measurable or concrete status statement. 2. State one primary risk with no speculative padding. 3. State the next action or milestone. 4. Close with the accountable owner. 5. Keep the full update compact enough to scan in seconds. ## Compiled Template {{PROJECT_STATUS}} Risk: {{PRIMARY_RISK}} Next: {{NEXT_ACTION}} Owner: {{OWNER}} Usage rule: fill all four tokens with current project facts. Keep the labels, order, and concise factual style unchanged unless the template itself is intentionally revised. ## Dependency Rules - {{PROJECT_STATUS}} controls only the opening progress statement. - {{PRIMARY_RISK}} must describe a current risk; it must not introduce a second status or next-step claim. - {{NEXT_ACTION}} must be forward-looking and concrete enough to function as the immediate next milestone. - {{OWNER}} identifies accountability for the update or next action and remains the final line. - A change to one token does not rewrite the labels or reorder the four information blocks. ## Filled Proofs Filled proof 1 Checkout redesign is ready for QA. Risk: analytics events are still missing on mobile. Next: QA handoff Tuesday. Owner: Priya. Filled proof 2 Data migration is 55% complete. Risk: two legacy tables have inconsistent IDs. Next: reconciliation review Thursday. Owner: Platform team. Both proofs change the project facts while retaining the reference sequence: status → risk → next → owner. ## Drift Guards - Do not turn the update into a long project narrative. - Do not move the risk below the next action. - Do not add unsupported causes, dates, percentages, or commitments. - Do not replace the owner line with vague collective language when accountability is known. - Do not add celebration, persuasion, or executive-summary filler unless the buyer explicitly changes the reference pattern. ## Reuse Notes Copy the Compiled Template, replace the four declared tokens, and keep every lock unchanged for consistent client updates. If a future approved update introduces a new recurring block, revise the template through Template Iteration rather than adding one-off text outside the structure. Completion checks: - Reference structure preserved: PASS - Only declared variable tokens remain: PASS - Dependency rules are explicit: PASS - Filled proofs preserve the reference pattern: PASS - Direct buyer use: PASS - No hidden dependency: PASS - No unsupported runtime claim: PASS