Smartphrase: demonstrate SAP <-> AC/DC model linkage (PoC for the working group)

# Smartphrase — demonstrate SAP ↔ AC/DC model linkage

> **Rework note (2026-07-12).** This issue body was rewritten to reground the requirements. The original body specified solution choices — an XHTML carrier with bespoke `sap:`/`smartphrase:` namespaces, grounding in the TransCelerate SAP template, and a fixed deliverable/file layout — before the requirements were stated, and the first round of work on branch `smartphrase_01` followed those choices in the wrong direction. The comment trail below is the record of that first PoC. This body now states **requirements only**; solution design is a separate, subsequent work product.

## Purpose

Produce a tangible demonstration for the **AC/DC working group** that makes the value of the AC/DC model obvious. The concept being demonstrated is the **smartphrase**: a link between spans of SAP prose and AC/DC model metadata such that the prose and the model are **two views of one thing**.

The working group is the primary audience; this is a concept vehicle for them to react to and steer, not production tooling.

## Core requirements — the four claims

The demonstration succeeds if it makes these four claims believable:

1. **One source of truth.** SAP prose and model metadata are co-equal, bidirectional authoring surfaces: edit the model and the prose follows; author the prose and the model instance follows. Both directions are first-class.
2. **Traceability to data.** Any smartphrase in the SAP can be followed down its full resolution chain to the physical dataset/variable it depends on.
3. **Template-level reuse.** One standard library building block (transformation template + its phrases) is shown instantiating with different parameters — write once, apply many.
4. **Standards alignment.** Identifiers ground in existing standards (USDM, ARS, STATO, CDISC/NCIt terminology, the AC/DC model's own artefacts) rather than a private identifier space.

## Authoritative grounding

- The **model source of truth is the `methods_02` branch data artefacts**: Transformation Library **v0.7** (anchor/placeholder structure), the per-method files (`lib/methods/`, Method schema v0.9.1), the concept models (`lib/concepts/`) and vocabularies (`lib/vocabulary/`).
- Only the **data** is binding. The eSAP v0.5.0 schema and the `acdc:macro` authoring-tag dialect on that branch are **design inputs to weigh, not constraints**.

## Scope

- **One analysis passage, done deeply** — enough prose to carry all four claims. Not a document-scale SAP encoding.
- Reuse is demonstrated at the **template level** (same building block, different parameterisations); no second full study is required.

## Constraints

- **Zero-install demos.** Static files that run from `file://` in any browser — working-group members double-click and it works. No server, no build step.
- **Carrier-neutral requirements.** No carrier format is mandated here; the carrier is a design decision, to be made with its rationale recorded.
- **SAP structure is volatile.** A sister project is starting up to define a standard SAP structure (analogous to the ICH M11 initiative for protocols). Any eSAP/SAP document structure used in this workstream **must be assumed to change**; the smartphrase linking mechanism must not be coupled to a particular SAP document structure.

## Assumptions from the original issue that no longer hold

- ~~XHTML + `sap:`/`smartphrase:` XML namespaces as the carrier~~ — premature solution language, retired (see `smartphrase/spec/format-evaluation.md` on the branch for the analysis).
- ~~Grounding in the TransCelerate Common SAP Template~~ — wrong anchor, and superseded by the SAP-structure sister project noted above.
- ~~Transformation Library v0.6 (22 phrases / 8 roles)~~ — superseded by v0.7 (anchors/placeholders) on `methods_02`.
- ~~Two full worked study SAPs (CDISC Pilot + Breast Cancer)~~ — replaced by the one-passage-deeply + template-level-reuse scope.
- ~~Hover / resolve / trace as the mandated demo set~~ — the four claims are the requirement; the interaction shape is a design decision.

## Deliverables

1. **A design record** — the chosen approach (including the carrier decision and its rationale, and how the eSAP-structure volatility is isolated), kept alongside the implementation.
2. **Self-contained interactive demo(s)** that make the four claims believable, runnable from `file://` with zero install.
3. **A short walkthrough** the working-group session can follow.

## Out of scope

- Exhaustive coverage of every SAP sentence or section
- Integration with a live Neo4j backend
- Formal schema / validation pipeline / production authoring tooling
- The standard SAP document structure itself (owned by the sister project)
- Public release beyond the CDISC AC/DC working group