# OftenCited Foundation sample pack Synthetic demonstration. Morgan Vale is fictional. No customer, revenue or citation outcomes are claimed. October 20, 2026. SYNTHETIC DEMONSTRATION · NOT A CLIENT RESULT ## A sample you can inspect. Morgan Vale is a fictional independent operations consultant serving founder-led B2B service firms. All situations and examples below are invented to show the deliverable format. No client endorsement, observed citation, measured result or working business is implied. Foundation Build scope and price · Download the complete editable sample pack Buyer: a founder whose service business keeps missing handoffs between sales and delivery. Offer: a bounded diagnostic followed by an agreed operating-system implementation. These are fictional sample services; no prices or results are asserted. A handoff is complete when the next owner can act without chasing missing context. Measure rework before buying automation. A weekly review should end with decisions, owners and dates. One accountable owner is more useful than a crowded responsibility chart. Fix the exception path as carefully as the happy path. Evidence gaps: these are working arguments. A real engagement must supply permissioned examples and sources before presenting them as empirical claims. Use short sentences, operational examples and named decisions. Say “in this example” for hypothetical cases. Avoid “revolutionize,” invented percentages and assertions of universal success. Explain a tradeoff before giving a recommendation. Before: “We unlock transformational efficiency.” After: “We map the handoff that keeps sending work back, then test one change with the people who own it.” I help founders of B2B service firms find where delivery loses context, clarify who decides, and test a practical operating rhythm. About: This fictional consultant favors small changes that a team can inspect. A real biography would contain verified experience and permissioned examples; none are fabricated here. Contact: A real client-owned contact route is configured and tested before launch. This preview deliberately collects no inquiries. Your handoff needs an acceptance test Measure rework before automating it What a weekly review should decide These short demonstrations show the editorial direction. A purchased Foundation includes three 800 to 1,200 word essays. The downloadable pack contains the drafts, source gaps and expansion briefs; these demonstrations are not represented as full paid-length deliverables. ## Your handoff needs an acceptance test A handoff can look complete to the sender and still leave the recipient unable to act. A signed proposal does not necessarily tell delivery who can approve a change, which promise matters most, or where the source material lives. Consider an invented agency engagement. Sales marks the opportunity won and sends a folder. Delivery finds three versions of the brief. Nobody knows whether the founder approved the latest date. Work starts anyway, then returns for clarification. The missing step was not a longer meeting. It was agreement on what “ready” means. Write the acceptance test with the receiving team. Can they name the buyer, intended outcome, scope, approval owner, deadline and unresolved decisions? Can they find the latest approved source? Each answer should point to a record, not somebody’s memory. Keep exceptions visible. If the buyer cannot confirm a date yet, name the person who will resolve it and the latest safe decision date. A blank field should not silently become a promise. Try the checklist on the next three handoffs. Record missing items and clarification time. That is a local test, not evidence that a checklist improves every organization. Keep what helps the receiving team start correctly; remove fields nobody uses. ## Measure rework before automating it Automation is appealing when a team keeps repeating the same task. But repeated activity can have different causes. A legitimate recurring check, missing context and an unclear approval rule deserve different responses. Take an invented proposal process. Every draft returns to sales for a change. Automating the document generator may make the first draft faster while leaving the returns untouched. The team needs to understand why each return happened. For one week, log each return with its reason, owner and approximate time spent. Separate factual corrections, changed requirements and approval disagreements. Avoid blaming individuals; the purpose is to locate the decision that the process failed to make. Choose one frequent, controllable cause. If scope changes because the buyer never approved the assumptions, test an explicit assumptions review before drafting. If approved information is repeatedly copied incorrectly, a template or integration may be appropriate. Compare the next set of proposals with the recorded starting point. Note the sample size, unusual cases and other changes. A reduction during a short trial is useful local evidence, not proof that automation caused the entire difference. Invest further only when the observed improvement justifies the maintenance burden. ## What a weekly review should decide A weekly review can consume an hour without changing the week. People recite completed tasks, the same blocked issue appears again, and nobody can say which decision became clearer. Start with the decisions that need a shared view. Which commitment is at risk? What tradeoff requires the founder? What can the responsible owner resolve without another meeting? Status belongs in the record before the discussion. For each decision, write the options, relevant evidence and decision owner. Give the discussion a boundary. If the evidence is missing, assign its collection and a return date rather than treating a confident opinion as a conclusion. Close with a decision log: what changed, who will act and when the next evidence arrives. “Discussed onboarding” is not an actionable result. “Delivery owner tests the revised handoff on the next two starts and reports missing information on Friday” can be inspected. After four reviews, ask which decisions would have happened anyway. Shorten or remove agenda items that do not need the group. The goal is a reliable way to resolve dependencies, not a meeting that proves everyone is busy. 1 · Immediately after confirmed signup: “Welcome. Here is the handoff acceptance checklist. Start with one recent handoff and mark what the receiving team could not find.” 2 · Two days later: “Before you automate: record why work returns. Separate changed requirements from missing context and copying errors.” 3 · Five days later: “Make the weekly review end with a decision, owner and date. If you want help diagnosing your own handoffs, reply with the situation.” This preview sends no email. A live sequence must include accurate sender identity, consent, an unsubscribe link and a tested client-owned account. Sample buyer question: “How do I reduce repeated sales-to-delivery handoff problems?” Baseline rows record engine, exact prompt, date/time, mode/locale, response, cited URLs and screenshot. All sample observation fields are not run. No citation score is invented. The editable pack includes five target questions, the baseline CSV format, source and configuration handoff, newsletter QA checklist and acceptance signoff. A real client gets actual observations and verified account access. ## Baseline worksheet (all rows NOT RUN) Freeze these five sample questions before recording responses: 1. How do I reduce sales-to-delivery handoff problems in a service firm? 2. What information should a client handoff include? 3. When should a founder-led agency automate its workflow? 4. How do I measure rework without blaming individuals? 5. What should a weekly operations review decide? CSV columns: question_id, exact_prompt, engine, product_mode, locale, run_at_utc, response_file, cited_urls, screenshot_file, own_site_cited, limitations, reviewer. Twenty initial rows (five questions x four engines), all NOT RUN in this sample. Record Google AI Overview absent/unavailable without replacing it with ordinary search results. Do not turn repeat runs into distinct-engine counts. Do not imply a change caused a citation. ## Newsletter QA - Client owns account, sender and list. Document provider and charges. - Use a controlled address with permission; verify signup, double opt-in where configured, welcome messages and unsubscribe. - Keep confirmation/provider logs and actual inbox evidence separate. - Test invalid email, provider failure and retry; never show success for a mock provider. - This synthetic preview has no connected form and sends no messages. ## Export manifest site-source.zip; content/three-essays.md; positioning.md; voice-guide.md; newsletter/three-emails.md; baseline.csv; baseline-evidence/; README-deploy.md; accounts-and-costs.md; acceptance.md. No credentials in exports. Client owns repository, domain, hosting and provider; record delegated access and revocation. Include backup/export and restoration steps. ## Acceptance record template Client: [required]; agreed scope/version: [required]; paid invoice: [verified reference]; delivery owner: [required]; kickoff date: [agreed]; delivered assets: [links]; desktop/mobile/form checks: [evidence]; revisions: [request and response]; publication approval: [client + timestamp]; handoff/access check: [evidence]; remaining defects: [explicit]; accepted: [client + date]. Never pre-fill approval.