The Deliverable Lands Elsewhere
A generic workshop cannot own every artifact it carries. Code may land in a repository, a document in a shared folder, a research answer in a task response, and a call in the world. Pulling copies of all deliverables into Crucible would turn it into a shadow document store and blur which destination is authoritative.
The task therefore names the real landing destination before execution. Acceptance evidence is collected there: a served behavior, a delivered file acknowledgement, a signed decision, or another domain-appropriate proof. Crucible records the destination description and evidence summary without becoming the destination.
This boundary also limits retention and access risk. The workshop keeps its brief, stage trail, reviews, attachment package, and landing record. The deliverable follows the policy of the system that owns it. One product does not silently inherit another product's backup, permission, or publication rules.
Links in the record must be durable enough for the intended audience but need not be public. Where direct references would expose sensitive topology, record a bounded identifier and evidence description. Conceptual proof is not an excuse to copy private material.
Name the Authority
For every deliverable, write one sentence: “The authoritative result is X at destination Y, accepted by evidence Z.” If the sentence names Crucible only because the task passed through Crucible, the ownership model is wrong.
Then test deletion or movement in the destination system. The workshop record should still explain what happened, while making clear that it is not a substitute copy of the deliverable.