Skip to content
C.W.K.
Stream
Lesson 01 of 04 · published

The Deliverable Lands Elsewhere

~11 min · destination, product-boundary, delivery, records

Level 0Cold Vessel
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

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.

The workshop closes the run; the destination receives the work. Crucible records what was attempted, reviewed, and proven, but it does not become the canonical home of a patch, document, deployment, or message. Keeping those landings separate prevents an audit system from swallowing the products it audits.

Code

Record a destination without absorbing the deliverable·python
landing = {
    "deliverable": "approved accessibility briefing",
    "destination": "the task's named document system",
    "acceptance": "owner acknowledgement recorded",
    "workshop_copy": False,
}
assert landing["destination"] and landing["acceptance"]
assert not landing["workshop_copy"]
print(landing)

External links

Exercise

Map five task types to their authoritative destination, acceptance evidence, and the bounded record Crucible should keep.
Hint
At least two should be non-repository deliverables.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.