# Clearweft: Build and Improve Workbook

**Good systems. More room to create.**

Twenty editable worksheets for building one useful online-business journey and improving it with evidence. Use the foundation sheets first, then follow the alternating practical builds and analytics reviews. Choose the audience/affiliate, service/booking or digital-product path that fits your actual offer.

## How to use this workbook

- Work in an editable copy and retain dates, decisions and source references.
- Complete only the journey your business needs. Label demonstrations clearly.
- Set up essential measurement before launch. Later analytics can use only what was actually collected.
- Distinguish observed zero, missing data, tests and assumptions.
- Keep customer-identifying details in private operating records, not in public case studies.
- At each review, choose one next action and assign an owner and date.

## Contents

- Week 1: Online Business Map
- Week 2: Content Brief and Weekly Planner
- Week 3: Resource and Welcome Sequence Kit
- Week 4: First Offer Canvas
- Week 5: Automation Blueprint and Test Checklist
- Week 6: Subscriber Response Playbook
- Week 7: Business Review Scorecard
- Week 8: Measurement Map and Baseline Review
- Week 9: Useful Website Planning and Test Kit
- Week 10: Discovery and Website Review
- Week 11: Booking Journey and Appointment Checklist
- Week 12: Conversion and Appointment Review
- Week 13: Digital Product Delivery Blueprint
- Week 14: Revenue, Cost and Effort Review
- Week 15: Onboarding and Follow-up Planner
- Week 16: Activation and Support Review
- Week 17: Reporting Workflow Specification
- Week 18: Evidence and Improvement Decision Brief
- Week 19: Improvement Experiment Record
- Week 20: Season Review and Next 90 Days


---

# Online Business Map

Clearweft · Week 1

## The person and the useful result

- The person we help:
- Their current situation:
- The task they want to finish:
- The obstacle we can help remove:
- Evidence for this need, or the assumption to test:

Complete the sentence: We help __________ achieve __________ through __________.

## Initial revenue route

Choose one: software recommendation / small digital product / focused service.

- Useful result supported by the offer:
- What we provide:
- What the person receives or purchases:
- Prerequisites or limitations:
- Why this belongs after the free resource:

## Customer journey

| Step | What the person needs | What we provide | Next action | Destination checked |
| --- | --- | --- | --- | --- |
| Discovery | | | | |
| Profile | | | | |
| Resource | | | | |
| Follow-up | | | | |
| Offer | | | | |

## Profile draft

Who we help:

Useful result:

Next action:

Destination:

## Clarity test

Ask a reader who has not seen your notes to describe the audience, result and next step.

- What they understood:
- What confused them:
- The wording we changed:
- Retest result:

## Decision record

Date:

Options considered:

Choice and reason:

What remains uncertain:

Next check and owner:

Completion: every promised step has a destination, and a new reader can explain the profile without additional context.

## Choose the initial path and measure
- Audience and affiliate / services and bookings / digital products and education:
- Why this path fits the real audience need:
- Meaningful completion event:
- Authoritative source for that event:
- Minimum events to collect before launch:
- Measurement collection start and test:
- Demonstrations that must remain labelled:


---

# Content Brief and Weekly Planner

Clearweft · Week 2

## One useful content brief

- Audience and situation:
- Exact question:
- Where the question came from:
- Useful result after consuming the post:
- Opening sentence:
- One central teaching point:
- Concrete example:
- Factual claims and sources:
- Primary next action:
- Destination:

## Seven complementary angles

| Angle | Working title | Useful takeaway | Format | Next action |
| --- | --- | --- | --- | --- |
| Problem | | | | |
| Decision | | | | |
| Recipe | | | | |
| Worked example | | | | |
| Failure or misconception | | | | |
| Complete explanation | | | | |
| Review or evidence | | | | |

Each post should be understandable independently. The longer lesson should connect the ideas around a worked example.

## AI assistance boundary

- Input we will provide:
- Drafting or adaptation task:
- What the tool must not invent:
- Facts we will check:
- Person reviewing the output:

## Publication review

- [ ] Answers a specific audience question.
- [ ] Gives a usable example or action.
- [ ] Claims match the available evidence.
- [ ] Text is readable at a realistic phone size.
- [ ] Caption and visual provide enough context.
- [ ] One primary next action leads to a working destination.
- [ ] Any affiliate relationship is disclosed where relevant.

## Production log

Actual minutes spent on brief:

Script and design:

Rendering and review:

Revision count and reasons:

Main bottleneck:

One process improvement:

Completion: seven connected ideas are planned and one complete post passes the review.


---

# Resource and Welcome Sequence Kit

Clearweft · Week 3

## Resource promise

- Intended reader:
- Task the resource helps finish:
- Format and contents:
- What it does not include:
- First useful action:

## Landing page fields

Headline:

Short promise:

Three included items:

Who the resource suits:

What happens after submission:

What emails the person is choosing to receive:

Required form fields and purpose of each:

## Delivery email

Subject: Your [resource name] is ready

Opening: Here is the [resource] you requested. It helps you [specific task].

Resource link:

First action: Start by [small practical action].

Help route:

## Follow-up 1

Purpose: help the reader apply the resource.

Obstacle to address:

Example or explanation:

Next action:

## Follow-up 2

Purpose: explain a relevant next step.

Who this next step is useful for:

Guide, tool or offer:

Fit, relevant limitations and costs to explain:

Affiliate disclosure if applicable:

## End-to-end test

| Check | Expected result | Actual result | Correction |
| --- | --- | --- | --- |
| Form submission | | | |
| Delivery message | | | |
| Resource access | | | |
| Mobile readability | | | |
| Follow-up links | | | |
| Email expectations and exit path | | | |

Completion: the promised resource arrives, opens correctly and gives the reader a clear first action.

## Website destination and evidence
- Promise made by the source post:
- Page's primary job:
- Actual action and destination:
- Resource access: freely available / optional email / explained signup requirement:
- Mobile and fresh-reader test result:
- Website event and its limited meaning:
- Provider-confirmed subscription source:
- Collection start and test exclusion:


---

# First Offer Canvas

Clearweft · Week 4

## One focused offer

- Intended customer:
- Current situation:
- Finished result:
- Starting conditions or prerequisites:
- Format: recommendation guide / template / mini-course / service.
- Essential contents:
- Exclusions and limits:

## Offer page draft

Headline:

Who it helps:

Task it supports:

What is included:

How to use it:

Sample or example:

Cost where relevant:

Other software requirements and relevant costs:

Support or update scope:

Next action:

What happens immediately afterward:

## Recommendation guide variant

- Job the software performs:
- Who it suits:
- When someone can defer adopting it:
- Official product and pricing sources:
- First useful setup task:
- Test evidence for the recipe:
- Affiliate relationship and disclosure, if applicable:
- Confirmed destination link:

## Promise and delivery test

| Promise on the page | What actually happens | Evidence or test | Needed change |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

For a paid product, use the provider's appropriate checkout or access test. For a recommendation guide, test the resource and the destination. For a service, test the request and scope-confirmation handoff.

## Reader review

Ask a reader to explain the intended customer, result, contents, limitations and next action.

Unanswered question:

Revision:

Next test:

Completion: the scope is clear and the next action delivers what the page promised.

## Path-specific completion
- Chosen path:
- Service: appointment purpose, preparation and outcome (if relevant):
- Product: contents, prerequisites, delivery and support (if relevant):
- Affiliate: useful tool adoption and available provider evidence (if relevant):
- Completion event and source:
- What is live now versus a demonstration:
- Deeper build needed in Week11/13 or another relevant week:


---

# Automation Blueprint and Test Checklist

Clearweft · Week 5

## Select the recurring job

- Job:
- Why it repeats:
- Current manual steps:
- Observable successful result:
- Approximate frequency based on actual use or a labelled assumption:
- Consequence of a wrong action:

## Workflow definition

Trigger:

Required fields:

Event identifier or duplicate check:

Conditions:

Allowed actions:

Expected output:

Status record:

Failure owner:

Recovery procedure:

## Five layers

| Layer | Responsibility | Source or implementation |
| --- | --- | --- |
| Logic | Rules and allowed actions | |
| Data | Required records and source of truth | |
| Intelligence | Optional bounded AI call | |
| Orchestration | Run steps and handle exceptions | |
| Presentation | Subscriber output and operator view | |

## Implementation choice

Options considered: existing native features / integration workflow / custom code.

Required connections:

Why the chosen option fits:

Running cost and maintenance work:

Current official instructions checked:

## Test matrix

| Case | Input | Expected result | Actual result | Evidence |
| --- | --- | --- | --- | --- |
| Normal request | | | | |
| Same event again | | | | |
| Missing required field | | | | |
| Failed action | | | | |
| Recovery after correction | | | | |

## Maintenance note

Owner:

Where failures appear:

Safe retry conditions:

When to stop and review:

Last successful test:

Next review date:

Completion: the normal case works, an unintended duplicate is prevented and a failure has a practical recovery path.

## Workflow responsibility map
| Layer | Responsibility in this workflow | Owner/system | Check |
| --- | --- | --- | --- |
| Logic | | | |
| Data | | | |
| Intelligence, only if needed | | | |
| Orchestration | | | |
| Presentation | | | |
- Native feature already sufficient:
- Repeated handoff worth automating:
- Exception requiring a person:


---

# Subscriber Response Playbook

Clearweft · Week 6

## Question groups

| Intent | Information needed | Approved source | Owner | Response route |
| --- | --- | --- | --- | --- |
| Find a resource | | | | |
| Choose the next lesson | | | | |
| Understand a recommendation | | | | |
| Report a delivery problem | | | | |
| Account-specific or other request | | | | |

## Approved answer record

Answer ID:

Question or selected intent:

Approved answer:

Source link:

Useful next action:

When to ask for clarification:

When to route to a person:

Owner:

Last review date:

## Response policy

Automatic fixed answers are allowed for:

Reviewed AI drafts are allowed for:

Human or provider review is required for:

Unknown question fallback:

How the person reaches further help:

Response-time wording the business can meet:

## Optional AI drafting brief

Task: draft a helpful reply using only the approved material supplied.

Inputs: question, relevant answer records and the response policy.

Output: proposed answer, answer IDs used, missing information and escalation reason when needed.

Rules: do not invent facts, account status, refunds, guarantees or permissions. If the source cannot answer the question, ask a useful clarification or use the defined escalation route.

Reviewer:

## Minimum case record

Case reference, received time, selected intent, answer version, response route, outcome and review status. Record only the information needed for the support process.

## Test matrix

| Question type | Expected route | Expected answer or action | Actual result |
| --- | --- | --- | --- |
| Common known question | | | |
| Broken resource link | | | |
| Ambiguous question | | | |
| Account-specific request | | | |
| Outside the answer library | | | |

Completion: known questions get accurate help, exceptions have an owner and the answer library can be corrected when something changes.

## Context and current state
- Relevant subscriber/customer/appointment state:
- Authoritative source for that state:
- Approved answer and version:
- Stop/change condition:
- Exception owner:
- Resolution record needed:
- Information omitted from public examples:


---

# Business Review Scorecard

Clearweft · Week 7

Review period:

Owner:

## Complete journey check

- [ ] Post promise matches its destination.
- [ ] Profile makes the audience and next action clear.
- [ ] Resource page explains what the person receives.
- [ ] Delivery and resource access work.
- [ ] Follow-up is useful and understandable.
- [ ] Offer scope and next action are clear.
- [ ] Automation status and failures are visible.
- [ ] Support answers and escalation work.

## Weekly measures

| Measure | Definition and source | Current period | Previous comparable period | Notes |
| --- | --- | --- | --- | --- |
| Useful guide visits | | | | |
| Resource signups | | | | |
| Relevant software clicks | | | | |
| Reported qualifying paid referrals | | | | |
| Approved commissions | | | | |
| Cash received | | | | |
| Recurring support issues | | | | |
| Production hours | | | | |
| Operating costs | | | | |

Use “not measured” for unavailable information. For a rate, record the numerator and denominator. Keep website events and provider reports separate when attribution cannot be reconciled.

## One improvement

Observed issue:

Evidence:

What remains uncertain:

Proposed change:

Why the change could help:

What we will check:

Owner and review date:

Decision after review:

## Tool review

| Tool | Actual job | Useful output | Cost | Maintenance | Keep or change |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

Completion: the journey has been tested, evidence is separated from missing information and one next improvement has an owner and review point.

## Prepare the twenty-week continuation
- Actual launch and measurement start:
- Sources available for Week8:
- Reporting period/time zone:
- Known missing data:
- Tests and internal activity excluded:
- One next question to investigate:
- Active business path:
- Build/review publishing capacity:
- Next analytics episode and owner:


---

# Measurement Map and Baseline Review

Clearweft · Week 8 · Analytics and decisions

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## Outcome and decision
- Business path:
- Current customer journey:
- Decision this review should support:
- One or two headline outcomes:

## Event dictionary
| Event | Exact meaning | Unit | Authoritative source | Timestamp/time zone | Stable identifier | Known gap |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

## Controlled test
- Test identifier and date:
- Expected events:
- Events observed and source:
- Duplicate handling:
- Test exclusion rule:
- Fault to repair:

## Baseline
- Period start/end and time zone:
- Collection began:
- Source exports retained at:
| Measure | Observed value | Unit | Source | Status: observed / unavailable / excluded | Qualification |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

## First decision
- What the evidence supports:
- What remains unknown:
- Reader or usability evidence:
- Next investigation:
- Owner and review date:
- Public reporting redactions:

## Completion check

The review includes a decision, owner and next review date without inventing missing results.

Date:

Owner:

Next review:


---

# Useful Website Planning and Test Kit

Clearweft · Week 9 · Practical build

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## Page job
- Visitor and situation:
- Question on arrival:
- Primary action:
- Source content and promise:
- Successful completion:

## Copy draft
- Heading:
- Result and intended audience:
- What is included:
- Prerequisites or limitations:
- Evidence available:
- Action label and actual destination:
- What happens afterwards:

## Implementation choice
| Option | Initial effort | Ongoing editing | Connections needed | Recurring cost | Recovery/ownership | Choice |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

## Journey test
| Check | Device/scenario | Expected result | Observed result | Correction/owner |
| --- | --- | --- | --- | --- |
| Fresh-reader explanation | | | | |
| Primary action | | | | |
| Confirmation/delivery | | | | |
| Error recovery | | | | |
| Keyboard/mobile use | | | | |
| Measurement | | | | |

## Review
- Problems observed:
- Changes made:
- Remaining assumptions:
- Next review date:

## Completion check

The full journey works on mobile and its observed problems have been recorded.

Date:

Owner:

Next review:


---

# Discovery and Website Review

Clearweft · Week 10 · Analytics and decisions

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## Review scope
- Business question:
- Decision to support:
- Content group and destination:
- Observation dates/time zone:
- Comparison period, if comparable:
- Collection or distribution changes:

## Evidence table
| Measure | Count/value | Unit | Period | Source | Attribution limit | Tests excluded |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

## Reader task check
- Intended reader and task:
- What the reader expected:
- Where they hesitated:
- Exact observation:
- Interpretation (hypothesis):

## Improvement brief
- Obstacle to address:
- Single change:
- Why it should help:
- Measure and qualitative check:
- Review window:
- Other concurrent changes:
- Owner and decision date:

## Completion check

The next action has a clear mechanism, measure and review date.

Date:

Owner:

Next review:


---

# Booking Journey and Appointment Checklist

Clearweft · Week 11 · Practical build

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## Appointment purpose
- Real offer or clearly labelled demonstration:
- Intended participant:
- Appointment outcome and scope:
- Duration and owner:
- Qualification needed before booking:
- Preparation required:

## Availability and intake
- Calendar representing real commitments:
- Working hours and time zone:
- Buffers and advance notice:
- Booking horizon/capacity:
- Required questions and purpose of each:
- Payment requirement and confirmation source, if relevant:

## Journey map
| Step | Trigger/input | Action | Owner/system | Completion evidence | Exception |
| --- | --- | --- | --- | --- | --- |
| Offer to booking | | | | | |
| Confirmation | | | | | |
| Preparation/reminder | | | | | |
| Appointment | | | | | |
| Follow-up | | | | | |

## Lifecycle checks
| Scenario | Expected result | Observed result | Record updated | Correction |
| --- | --- | --- | --- | --- |
| Normal booking | | | | |
| Time-zone booking | | | | |
| Calendar conflict | | | | |
| Reschedule | | | | |
| Cancellation | | | | |
| No suitable slots | | | | |

## Review
- Confirmed booking definition:
- Attendance recording method:
- Test exclusion rule:
- Support owner:
- Next review date:

## Completion check

The booking journey works and its exceptions have an assigned response.

Date:

Owner:

Next review:


---

# Conversion and Appointment Review

Clearweft · Week 12 · Analytics and decisions

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## Active conversion path
- Business path:
- Real operating case or demonstration:
- Decision to support:
- Period/time zone:
- Outcomes that have had time to mature:
- Source refresh times:

## Stages and definitions
| Stage | Definition | Unit | Source | Count | Eligible denominator, if used | Limits |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |
- Reschedule handling:
- Cancellation handling:
- Future appointment handling:
- Test activity exclusions:

## Investigation
- Observed stopping point:
- Possible explanations:
- Journey test and result:
- Customer feedback:
- Capacity or preparation constraint:
- Strongest supported hypothesis:

## Decision
- Change selected:
- Expected mechanism:
- What would make us keep it:
- What would make us revise/reverse it:
- Review date and owner:
- Public interpretation and uncertainty:

## Completion check

The change has an owner, expected mechanism and observable review criteria.

Date:

Owner:

Next review:


---

# Digital Product Delivery Blueprint

Clearweft · Week 13 · Practical build

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## Product definition
- Intended buyer and situation:
- Useful first result:
- Actual contents and formats:
- Prerequisites and expected effort:
- Support included and owner:
- Maintenance commitment:
- Evidence of demand or assumption to test:

## Selling setup
- Product page / focused checkout / course platform / catalogue store:
- Reason for the choice:
- Price and currency:
- Delivery method and timing:
- Purchase conditions and current provider requirements checked:
- Authoritative payment/order status:

## Delivery specification
| Step | Trigger/input | Rule/action | Completion record | Failure response |
| --- | --- | --- | --- | --- |
| Confirm purchase | | | | |
| Grant/deliver access | | | | |
| Send first-use message | | | | |
| Handle support | | | | |
- Stable order/event identifier:
- Duplicate prevention:
- Refund/access-change procedure:

## Test cases
| Scenario | Expected result | Actual result | Correction |
| --- | --- | --- | --- |
| Successful test purchase | | | |
| Incomplete/failed payment | | | |
| Repeated notification | | | |
| Delivery failure | | | |
| Fresh customer first use | | | |

## Launch decision
- Ready / revise / demonstration only:
- Remaining work and owner:
- First review date:

## Completion check

The normal and exception paths work, with a clear support owner.

Date:

Owner:

Next review:


---

# Revenue, Cost and Effort Review

Clearweft · Week 14 · Analytics and decisions

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## Reporting basis
- Period/time zone:
- Business models active:
- Sources and refresh dates:
- Reporting currency and conversion rule, if any:
- Included and excluded costs:

## Affiliate activity
| Provider | Reported referrals | Pending commission | Approved commission | Reversals | Cash received | Currency | Reporting limits |
| --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | |

## Product/service activity
| Offer | Confirmed sales/orders | Refunds | Cash received | Direct fees/costs | Outstanding delivery | Currency |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

## Costs and working time
| Activity/tool | Cash cost | Recurring or one-off | Allocation basis | Hours | Recorded or estimated | Useful result |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

## Interpretation
- Cash contribution definition, if used:
- Founder time shown separately:
- Outcome maturity/reporting delay:
- Dependencies or concentration:
- What the evidence supports:
- What it cannot yet establish:

## Investment decision
- Continue / improve / simplify / pause / retire:
- Activity selected:
- Reason:
- Expected benefit and required effort:
- Review condition and date:

## Completion check

The decision identifies the expected benefit, cost and review conditions.

Date:

Owner:

Next review:


---

# Onboarding and Follow-up Planner

Clearweft · Week 15 · Practical build

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## Onboarding path
- Person and starting event:
- Promise already made:
- First useful result:
- Evidence available: system event / self-report / proxy / unavailable:
- Prerequisites:

## Sequence design
| Message/step | Trigger or timing | One purpose | Useful action | Destination | Evidence | Stop/change condition |
| --- | --- | --- | --- | --- | --- | --- |
| Delivery | | | | | | |
| First-use guidance | | | | | | |
| Obstacle/help | | | | | | |
| Relevant next step | | | | | | |

## Rules and ownership
- Confirmed source event:
- Duplicate-start prevention:
- Current-state check:
- Preferences/unsubscribe handling:
- Cancellation/refund/changed-status handling:
- Human help owner and response expectation:

## Recipient test
| Scenario | Expected experience | Observed experience | Fix/owner |
| --- | --- | --- | --- |
| First delivery | | | |
| First task | | | |
| Repeated trigger | | | |
| Changed or stopped status | | | |
| Help request | | | |

## Review
- Main obstacles observed:
- Change made:
- First-use evidence to collect:
- Review date:

## Completion check

A new recipient can reach the first useful result and request help when needed.

Date:

Owner:

Next review:


---

# Activation and Support Review

Clearweft · Week 16 · Analytics and decisions

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## First-use definition
- Journey/product version:
- First useful result:
- Why this result matters:
- Available evidence and source:
- Evidence type: observed / self-reported / proxy / unavailable:

## Group and period
- Entry event and dates:
- Time allowed to act:
- Eligible population and exclusions:
- Comparison group, if useful:
- Onboarding changes during the period:

## Progress evidence
| Measure | Value | Unit | Source | Window | Limitation |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

## Support review
| Category | Observed issue | Context | Resolution | Repeat contact | Effort | Possible underlying cause |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

## Improvement decision
- Problem selected:
- Evidence supporting it:
- Change and expected customer benefit:
- Useful support that should remain:
- Test method:
- Owner/review date:
- Public summary and redactions:

## Completion check

The chosen correction has an owner, a clear customer benefit and a review method.

Date:

Owner:

Next review:


---

# Reporting Workflow Specification

Clearweft · Week 17 · Practical build

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## Reporting contract
- Decision supported:
- Measures and definitions:
- Period/time zone:
- Required sources and expected refresh:
- Complete / partial / blocked conditions:
- Owner and review deadline:

## Five-layer specification
| Layer | Responsibility | Inputs | Outputs | Owner/check |
| --- | --- | --- | --- | --- |
| Logic | Definitions, exclusions, calculations | | | |
| Data | Source and derived records | | | |
| Intelligence | Optional evidence-based interpretation | | | |
| Orchestration | Collection, sequence, retries, review | | | |
| Presentation | Private scorecard and public explanation | | | |

## Source contract
| Source | Export/API route | Required fields | Stable identifiers | Refresh/cutoff | Missing/late handling |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

## Reliability checks
- Run identifier and log location:
- Duplicate/rerun rule:
- Corrected-record handling:
- Missing field behaviour:
- Native total reconciliation:
- Secret configuration location (name only):
- Public/private output boundary:

## Acceptance test
| Scenario | Expected result | Observed result | Correction |
| --- | --- | --- | --- |
| Complete input set | | | |
| Missing source | | | |
| Duplicate import/rerun | | | |
| Corrected/refunded record | | | |
| Public output review | | | |

## Operating decision
- Collection effort before/after, if measured:
- New maintenance required:
- Next source justified by:
- Review owner/date:

## Completion check

A reviewer can trace each published result to its source and reproduce the calculation.

Date:

Owner:

Next review:


---

# Evidence and Improvement Decision Brief

Clearweft · Week 18 · Analytics and decisions

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## Constraint statement
- Person and task:
- Observed obstacle:
- Business/operating consequence:
- Data-quality checks completed:

## Evidence register
| Evidence | Date/source | Type: observed / reported / proxy / assumption | What it supports | Limitation |
| --- | --- | --- | --- | --- |
| | | | | |

## Candidate actions
| Action | Customer benefit | Evidence strength | Effort/cost | Dependencies/maintenance | Commercial relevance | Decision |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

## Chosen improvement
- Problem:
- Change:
- Expected mechanism:
- Included scope:
- Deferred work:
- Owner and required resources:
- Why this action now:
- Why alternatives were deferred:

## Review rule
- Evidence to collect:
- Observation window:
- Retain when:
- Revise when:
- Reverse/stop when:
- Investigate further when:
- Other changes to record:
- Review date:

## Completion check

The next build has a decision brief that can be reviewed against actual evidence.

Date:

Owner:

Next review:


---

# Improvement Experiment Record

Clearweft · Week 19 · Practical build

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## Confirmed decision brief
- Linked Week18 decision:
- Problem and evidence:
- Change selected:
- Expected mechanism:
- Any new evidence or revised decision:
- Completion test:

## Implementation record
- Original version/configuration:
- Changed components:
- Required related content/link updates:
- Deferred ideas:
- New cost or maintenance:
- Owner and change date:
- Reversal/recovery route:

## Verification
| Test | Expected result | Observed result | Evidence | Remaining issue |
| --- | --- | --- | --- | --- |
| Original customer task | | | | |
| Primary action/completion | | | | |
| Relevant exception | | | | |
| Measurement | | | | |
| Related promise/link | | | | |
- Controlled test exclusion:

## Outcome observation
- Metric definition and source:
- Observation start/end:
- Qualitative check:
- Other concurrent changes:
- Review rule carried forward:
- What can be claimed now:
- What requires later evidence:

## Completion check

The improvement is ready for an honest outcome review without premature claims.

Date:

Owner:

Next review:


---

# Season Review and Next 90 Days

Clearweft · Week 20 · Analytics and decisions

Use your own verified records. Blank fields are intentionally unpopulated. Label demonstrations, unavailable data and assumptions; never present them as actual customer results.

## System status
| Component/journey | Planned / implemented / connected / tested / observed | Evidence | Owner | Maintenance/next action |
| --- | --- | --- | --- | --- |
| Audience and offer | | | | |
| Content and website | | | | |
| Relevant conversion path | | | | |
| Delivery/onboarding/support | | | | |
| Reporting and improvement | | | | |

## Season evidence
- Actual data collection dates:
- Definitions or setup changes:
- Verified outcome measures and sources:
- Pending/approved/paid distinctions:
- Customer questions and progress evidence:
- Costs, production time and maintenance:
- Most important uncertainty:

## Decisions
| Component/activity | Keep / repair / simplify / pause / stop | Evidence and reason | Consequence | Owner |
| --- | --- | --- | --- | --- |
| | | | | |

## Next ninety days
- Focus audience and business path:
- Useful outcomes:
- Available operating capacity:
- Build/review cadence:
| Project | Audience need | Evidence | Intended result | Effort/dependencies | Review point |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

## Publication and handover
- Claims verified against sources:
- Demonstrations and unknowns labelled:
- Customer details removed from public materials:
- Outdated guides/links updated:
- Operating owners and next review dates assigned:
- Next season decision:

## Completion check

The next plan has priorities, evidence checks and enough capacity to operate the current business.

Date:

Owner:

Next review: