# Reference expression and review

Andrew David W.Y. · T03 exercise material 04

Read after producing your three forms and hearing an unfamiliar reader's retelling. This is one possible organization, not the only answer. All business, sample and feedback examples are fictional teaching materials, unrelated to real projects.

## 1. Match the four questions to evidence

| Question | Reference organization | Evidence and limits |
| --- | --- | --- |
| Whom? | Small multi-store retail teams lacking dedicated design coordination | E01/E02: intended audience, not proven demand scale |
| What problem? | Scattered campaign information, store differences and unclear final versions | E02: hypothesis; no actual interviews/demand statistics |
| How? | Appointed campaign owner confirms requirements; team prepares/revises layouts; owner confirms usable catalogue; stores use independently and report back | E03/E04: proposed workflow; no real trial delivery |
| Evidence? | Mock requirements form, written style rules, two-store draft fields, change/catalogue records | E05/K01–K03: fields/status checkable, not business effects |

E03 specifies no fee, period or supported store scale. Do not invent a price, delivery days or national coverage. E08 contains only a trial plan; automatic synchronization is undeveloped.

## 2. Three sample forms

### 1. Positioning sentence

We are developing a store campaign-material collaboration service to help small multi-store retail teams lacking design coordination turn campaign requirements into store-specific versions that can be confirmed and handed over.

“Developing” retains the stage; the small multi-store retail team fixes the audience; campaign requirements and store versions define scope. Follow immediately with a paragraph/caption explaining that only desktop samples exist and there has been no real-store trial. The sentence cannot carry the entire evidence explanation alone.

Other sentence structures are acceptable if meaning/status remain unchanged; do not copy word order merely to match the example.

### 2. Explanatory paragraph

This service is at proposal and desktop-prototype stage. It is intended for small multi-store retail teams lacking design coordination, addressing scattered campaign requirements, store differences and unclear final versions. A campaign owner appointed by the retail team first consolidates/confirms text, prices, dates and store differences. The service team prepares layouts, revises from feedback and delivers a numbered, status-labelled version catalogue. Once the owner confirms usability, each store arranges printing or online use, and feedback informs later improvement. Mock requirements, style rules, store-specific drafts and change/catalogue records can be inspected. There are no real-store trials or efficiency/sales evidence; the problem hypothesis remains unverified. Fees, timing and scale are unconfirmed; automatic synchronization is undeveloped.

This adds the process and limits readers need to question. It can be shorter, but “proposed” and “unverified” must not disappear into mature-capability claims or promised effects.

### 3. One-page mechanism diagram

![Reference store campaign-material collaboration diagram](/journal/business-positioning-one-page-exercise/materials/en/asset-05.svg)

[Download reference SVG](/journal/business-positioning-one-page-exercise/materials/en/asset-05.svg)

Check these relationships individually; arrows are not proof of achieved effects.

1. Appointed campaign owner → service team: confirmed campaign information and store differences.
2. Team → owner: drafts for checking text, prices, dates and versions.
3. Owner → team: required revisions return to layout; unconfirmed drafts cannot enter usable handover.
4. Team → owner: numbered/status-labelled catalogue for final usability confirmation.
5. Owner → stores: corresponding usable versions; stores choose printing or online use themselves.
6. Stores → team: usage issues/revision proposals; changed requirements return to owner confirmation.

This entire chain is proposed. K01–K03 provide desktop sample formats only, not evidence of real-store handovers. Any automatic synchronization shown must be separate and labelled undeveloped.

## 3. What differs and what must remain consistent

| Content | Sentence | Paragraph | Diagram |
| --- | --- | --- | --- |
| Purpose | Broadly whom/what | Operation and current evidence | Participants, outputs, confirmation and returns |
| May omit | Fields, full steps, future ideas | Individual simulation records | Full copy/sample detail |
| Retain | Audience, campaign-material scope, experimental stage | Audience, roles, main outputs and evidence limits | Proposed status, duties/conditions, present/future distinction |
| Evidence display | Adjacent explanation may supplement | Explicit desktop-only/no-real-effects evidence | Notes, captions and IDs define scope |

Adjust detail for customers or internal executors, but changing the audience to all businesses or showing automatic sync as existing changes core facts.

## 4. Issues to find in samples

K01 gives Store A 2030-06-08 to 2030-06-09, and Store B only 2030-06-08. K02's A-01 omits A's second day. A consistent shared style alone cannot justify acceptance.

K03 retires A-01 and maps A→A-02, B→B-01. The diagram must show checking, return, revision, reconfirmation and usable catalogue relationships; it need not list every version ID.

A corrected simulated error proves neither a lower real error rate nor 100% error elimination. Samples check information/version alignment; actual delivery still requires a trial.

## 5. Revising E07

| Early claim | Treatment | Reason |
| --- | --- | --- |
| Global intelligent brand-growth platform | Delete; name specific service scope | No evidence of global coverage, an operating platform or growth effects |
| Automatic synchronization of all stores | If mentioned, separate as an undeveloped future idea | E08 proposes manual collaboration first, not automatic capability |
| 100% elimination of material errors | Delete guarantee; explain proposed checking/version records for handovers | Desktop materials do not prove zero errors |
| 80% greater efficiency | Delete figure; identify need for comparable trial records | E06 contains no efficiency comparison |
| Guaranteed 30% campaign-sales increase | Delete both guarantee and figure | No sales records; material collaboration alone cannot establish sales changes |

Adding “expected” or “possible” does not support an otherwise unevidenced precise number. Treat effect targets as research questions and specify needed evidence.

## 6. Handling retelling feedback

These fictional quotations illustrate classification; they are not reader-test results actually obtained. In formal worksheets, record real readers' actual words.

| Illustrative retelling | Finding | Next step |
| --- | --- | --- |
| “You already have a system that sends to every store automatically.” | Invented current capability/publication responsibility | Check wording/legend; state proposed manual collaboration, undeveloped automation and store-controlled publication |
| “You just make posters for every company.” | Expanded audience/scope | Put target audience, differences and confirmation/handover earlier; retest |
| “These posters already increased customer sales.” | Desktop samples mistaken for real effects | Put simulated status near samples/diagram; retain no-real-effects statement |
| “I know who designs, but not who confirms usable versions.” | Missing confirmation responsibility | Show appointed owner, confirmation point, usable catalogue and return conditions |
| “I understand the process, but will stores pay?” | Genuine business-evidence gap | Record as unverified; research needs/willingness to pay, not copy changes alone |

Background and reading time may affect retelling. Retain actual words/conditions before suggesting causes; do not blame all misunderstandings on copy or equate disagreement with failure to understand.

## 7. Review criteria

Use “clear / partly clear / needs revision” with a corresponding sentence or node, rather than uniform copy or a simple total score.

| Criterion | Observable success | Needs further work |
| --- | --- | --- |
| Specific audience | Small multi-store teams and clear context | All industries/businesses included |
| Bounded problem | Specific problem, hypothesis status retained | Author's ambition presented as customer necessity |
| Connected operation | Who hands what, who confirms, how returns work | Concepts connected without handovers |
| Evidence alignment | E/K references and support limits | Samples used as proof of efficiency, sales or real acceptance |
| Three forms consistent | Different detail, same facts/stage | Sentence says prototype; diagram shows operating system |
| Traceable reader feedback | Words and reading order recorded | Author explains first, then calls retelling independent |
| Reasoned revisions | Wording/evidence changes distinguished and logged | Louder language hides gaps |
| Maintainable updates | Version, checker and update triggers traceable | Sentence changes while paragraph/diagram retain old status |

## 8. Return to complexity, simplicity, accessibility and diagrams

Complexity: lay out source materials, roles, hypotheses and current status.

Simplicity: use four questions to find this reader's main thread.

Accessibility: write understandable sentences/explanations with recognizable next collaboration.

Diagram: draw checkable design relationships and use retelling to test expression.

Business validation continues after the diagram is clear. Each task has its own next steps; neither substitutes for the other.