How the Bidirectional Mission Cycle replaces the project brief

The project brief has been the standard opening document in consulting and freelance work for decades. The client writes what they need, the consultant reads it, asks clarifying questions, and eventually begins work. The problem is structural: the brief is one-way. It captures what the client knew how to articulate when they wrote it, which is often not the same as what they actually need.

The result is familiar to any independent professional. The first draft of a deliverable prompts a round of corrections that reveal the requirements the brief omitted. A second draft prompts another round. By the time the final version is approved, the consultant has spent as much time on revision cycles as on the original production. None of that time was priced into the original brief.

The brief fails because it treats a collaborative professional process as a one-way information transfer. It puts the entire burden of specification on the client at the moment when the client knows least about what the final result will look like.

The Bidirectional Mission Cycle in Temet replaces the brief with a five-phase structured exchange, each phase signed and traceable.

Phase one is Prepare: the expert and their agent produce a Mission Plan. This is not a proposal or a quote. It is a scoped professional object: the deliverable format, the method, the constraints, the assumptions, and what the expert needs from the client. The agent drafts the first version; the expert reviews and approves it before it leaves their workspace.

Phase two is Push: the Mission Plan is sent to the client through the signed A2A Network channel. A snapshot of the version sent is stored locally as sent.md. The client is notified and can open the mission using their own agent.

Phase three is Receive: the client interacts with the Mission Plan freely, as they would in a document editor. They keep what works, modify what does not, add requirements, remove assumptions. When they return it, the signed mission/update envelope arrives in the expert's Mission Inbox. Temet verifies the signature, applies the patch, and stores the returned version as received.md.

Phase four is Report: the expert's agent reads the diff between sent.md and received.md and produces a semantic report. This is the differentiating feature. The report tells the expert not just what changed, but what the client kept without comment (implying agreement), what they modified and how (implying priority), what they added (implying unmet needs), and what they removed (implying rejection or misunderstanding). The expert reads a narrative analysis, not a line diff.

Phase five is Orchestrate: the expert does not reproduce the deliverable from scratch. They pilot. They accept suggestions from the semantic report, validate the direction, and let the agent prepare the next iteration. The expert's time is spent on judgment calls, not on mechanical revision.

The semantic report is what separates the Bidirectional Mission Cycle from any document collaboration tool. A line diff shows what changed. The semantic report explains what those changes mean.

From the comparison of sent.md and received.md, the agent produces a structured narrative covering five dimensions. What the client kept without change, which signals acceptance and alignment. What the client modified and in what direction, which reveals their actual priorities beneath the original brief language. What the client added, which surfaces requirements they could not articulate before seeing the first version. What the client removed or contested, which identifies assumptions that were wrong. And the implicit signals: phrasing choices, emphasis patterns, structural reorganization that reveals how the client thinks about the problem.

The expert receives this report before opening the client version. By the time they review the returned Mission Plan, they already have a diagnostic of the client's reaction. That is the difference between a professional who is constantly reacting to feedback and one who is leading the iteration.

The technical foundation of the Bidirectional Mission Cycle is a snapshot architecture. For every version of a mission, Temet stores two files: sent.md, the exact version the expert pushed to the client, and received.md, the version the client returned.

These snapshots are stored in the expert's local vault under a versioned directory: .temet/missions/msn_id/v1/. They are independent of the current state of the mission note. That independence is essential. The semantic report compares the two snapshots, not the current note against a vague memory of what was sent. The diff is exact and reproducible.

The snapshots also provide the legal audit trail. If a dispute arises about what scope was agreed, the expert can produce the signed sent.md and the signed received.md, showing exactly what was proposed and exactly what the client returned. The Mission Plan is not a verbal agreement or an email chain. It is a versioned, signed document sequence.

Malt, Upwork, and comparable freelance marketplaces are built around profiles, ratings, and message threads. The unit of exchange is the consultant's availability, represented by a day rate or an hourly rate. The client posts a job, consultants apply or are invited, a conversation begins, a contract is issued.

None of that infrastructure supports the Bidirectional Mission Cycle. There is no signed Mission Plan, no snapshot architecture, no semantic report, no A2A Network. The brief is still a text box. The revision is still an email thread. The deliverable is still a file attached to a message. The supervision trace does not exist.

The Certified Deliverable that closes a Bidirectional Mission Cycle, signed with the expert's Ed25519 key and backed by a sent/received snapshot pair, cannot be produced inside a marketplace infrastructure built for hour trading. The Encoded Method behind the expert's practice cannot be surfaced by a profile that shows star ratings and a biography.

This is not a feature gap on those platforms. It is a structural incompatibility. The Bidirectional Mission Cycle requires a protocol layer that turns iteration into signed, versioned professional objects. That is what Temet is built to provide.