Traceability: knowledge remains connected to behaviour

This is a map of claims and intended evidence, not a blanket assertion that Relay is complete.

Product intent	Design decision	Contract / implementation	Evidence	Current disposition
Avoid duplicate submission records	Identity is (source, external_id) for demo	RequestStore.create_if_absent	test_exact_replay_returns_original	Demonstrated in memory
Do not overwrite contradictory submissions	Replay conflict must be explicit	DuplicatePayloadConflict	test_conflicting_duplicate_rejected_without_mutation	Demonstrated in memory
Make request creation auditable	Intake emits creation event only once	RequestIntake + audit port	test_creation_audit_is_emitted_only_once	Demonstrated in memory
Make ownership visible	Separate assignment and product workflow	Assignment design target	Needs UI trials and integration tests	Not implemented
Protect user/site data	Auth and tenancy designed before exposure	Security boundary TBD	Needs threat model and tenant tests	Open blocker
Keep product lean	Prioritisation is an optional hypothesis	No scoring dependency in mechanics	Product evaluation and decision log	Removed in illustrative scenario

What this prevents

The team can change a product decision without losing the reason for it. A delivery task points to a design and a verifiable claim. A reviewer can tell which behaviours are supported and which remain assumptions.

The intention is traceability without a heavyweight tool mandate. A small team might use Markdown and Git; a larger organisation may link these relationships through existing product and governance tools.