What an analyst should inherit: sources, decisions, and unresolved questions

The final memo is not the complete handover

A new analyst receives an options memo and the source folder. The memo favors one course of action, but its author is no longer available. Which undertaking ruled out the alternative? Was a contradictory report rejected, or simply never seen? Did a later amendment change the assessment? Without that record, the next analyst may repeat the investigation or inherit a judgment they cannot explain.

The capsule design asks what useful context can accompany the artifact: attributed claims, source versions, scope, assumptions, review decisions, and open questions. This is a practical record of analytical work, not a complete account of a person’s cognition. Professional judgment can remain difficult to articulate, and a method that helped in one case may be inappropriate in another.

Treat reuse as an explicit dependency

PROV-O distinguishes an entity from the activity that generated it and the agent responsible for that activity. Its derivation and revision relationships provide useful language for a handover: this comparison used these source versions, followed this method, and received this review decision. Attribution is not endorsement; a named reviewer can still be mistaken. [1]

The following fictional manifest illustrates the contract. A consuming workspace should check the referenced versions and permissions before presenting the package as ready for use. A missing source is a visible limitation, not a reason to silently replace the receipt with an uncited summary.

{
  "capsule_revision": "rev-17",
  "question": "Which commitments constrain option B?",
  "depends_on": [
    {
      "id": "agreement-4",
      "revision": "3"
    },
    {
      "id": "comparison-method",
      "revision": "2"
    }
  ],
  "review": {
    "decision": "accepted_with_caveats",
    "caveat": "Annex translation remains provisional"
  },
  "open_questions": [
    "Does the exception apply to the regional authority?"
  ],
  "access_requirement": "Check source access in the receiving workspace",
  "derived_artifacts": [
    {
      "id": "options-memo-6",
      "status": "valid_for_this_snapshot"
    }
  ]
}

Forking should preserve differences, not hide them

A receiving team may have a different mandate or a more recent source set. A fork should identify its parent revision and record changed assumptions, methods, and decisions. It should not present the parent’s approval as approval of the new assessment. If two teams independently revise the same claim, merging requires a visible reconciliation decision.

For a small case, an annotated document plus a versioned manifest may be enough. A relational record may handle approvals and dependencies well. A graph becomes useful when the relationships must be traversed across many artifacts. The system should justify that complexity through a task that simpler storage cannot serve as well, not through a general claim that documents are inadequate.

Invalidate conclusions as carefully as you cache them

A content hash detects a byte change; it does not say whether an interpretation remains valid. Conversely, an unchanged document can require reassessment because a new event alters its relevance. Dependency-driven invalidation therefore needs both mechanical checks and review triggers. Retention and deletion obligations can also limit what history may be kept.

Shorter context must not mean thinner accountability

An agent may receive a compact handover rather than the complete conversation. Anthropic’s context-engineering guidance discusses compaction and persistent notes as ways to maintain continuity. These are useful techniques, but a compressed note can omit a qualification or transform a disputed claim into apparent fact. Preserve retrieval pointers and test whether important disagreements survive. [2]

Reusing reviewed context may avoid repeated extraction, but the saving has conditions. Count the original preparation, source refreshes, invalidation, and later expansion of the summary. A stale package that causes rework is not efficient merely because its initial prompt was short.

Test a handover with a second reader

Give one analyst a bounded case, then give another either the final memo and sources or the proposed capsule handover. Ask the second analyst to locate support for a claim, identify a caveat, correct an inserted error, and update the assessment after a new document. Measure time, missed qualifications, unsupported carryover, and access failures. Structural checks, including SHACL-style validation, can test required records but cannot substitute for this task. [3]

PRAXIS is the intended handover workspace, with DIALECTICA supplying reviewed context proposals. Cross-workspace portability and complete source-access preservation remain development work. The standard of success is whether the next person can inspect and revise the work responsibly, not whether the package can be downloaded.

A successor inherits questions as well as decisions

A local handover carries pinned source versions, the question, mandate, method correction, sentence dependencies and exact-revision review. Importing author approval does not authorize the new analyst’s task. The successor checks audience, jurisdiction, source access and unresolved adoption/funding again.

The restricted example removes text, revealing locators and derived free text from export. The file records the omission and cannot fully support independent review of the missing evidence. A changed S03 marks only declared dependent spans potentially stale; unrelated sentences and historical approvals remain intact. Production cross-owner sharing is a separate acceptance task. [4]