Skip to content

Support explicit external dependency contracts for selective PM4 pieces #56

Description

@jacksenpierce

Context

Parmesan 4.2.0 closes selective capsules over every recognized graph membership and semantic Markdown pointer. Publication currently fails closed if a dependency is missing or an alias is ambiguous. That is the correct safe default and completes #54's ordinary self-contained-piece workflow.

Some future pieces may intentionally depend on material distributed elsewhere: a large shared basis, another capsule, or an object the recipient is expected to hydrate later. That should not be smuggled through an allow-missing flag.

Desired contract

Design explicit external dependency declarations for selective pieces. A declaration should use exact identity—not an unresolved readable alias—and should state at least:

  • target object UUID and corpus/workspace scope when known;
  • expected content/revision identity or acceptable frontier policy;
  • why the dependency is external rather than carried;
  • whether the piece may be inspected, mounted, mutated, or composed before hydration;
  • an optional capsule/resource identity capable of satisfying it;
  • provenance for the operator decision that externalized it.

Receive/inspect should classify every declaration as already present, satisfiable from an attached capsule/resource, absent, mismatched, or ambiguous. Hydration/composition must be explicit and idempotent. A readable alias must never capture an external dependency silently.

Acceptance evidence

  • Default 4.2 behavior remains fail-closed and requires no new user ceremony.
  • An explicit exact external dependency produces a valid but visibly incomplete piece with operation-specific readiness.
  • A recipient with the exact object already present reports it satisfied without duplication.
  • Wrong UUID/revision/content fails; same-looking aliases or homologous nodes do not satisfy the declaration.
  • Hydrating the declared dependency produces the same semantic result as carrying it in the original closure.
  • Receipts distinguish sender-declared externality from corruption or accidental omission.
  • Bounded LLM responses expose counts, status, and next action while the complete ledger remains in the artifact.

Follow-up to #54 and the 4.2.0 selective-capsule release. Related: #41 and #44.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    corpus-safetyCorpus release safety and source-tree protectionsenhancementNew feature or requestllm-affordanceStructured guidance and recovery for LLM operatorspm4Parmesan 4 managed-workspace behavior

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions