Skip to content

Vault-transform safety protocol

Status: open/proposed

  • The safety rules a vault reshape must satisfy before it may delete or overwrite output: a hard deny boundary distinct from seed selection, target-state preconditions with journaled recovery, collision keys computed before plan approval, and an explicit plugin trust model.
  • Gates the dossier’s full seven-stage scope: M-J9TB-vault-kernel-and-transforms ships no destructive execution until this decision is accepted.

The migrated dossier’s filtering.md states that a note rejected by select “may still be pulled into the survivor set” by expansion. As content-closure semantics that is intentional; as an export boundary it means publish: false does not mean denied. Separately, dry-run parity re-verifies source hashes only — the approved target diff is not proven to still be the diff being applied, and a crash between writes and manifest refresh stalls the next run.

  1. Two predicates. select chooses seeds; deny (or eligible) is a hard boundary expansion cannot cross. An embed crossing the boundary degrades or fails per explicit policy — the provenance report is not the security boundary.
  2. Target preconditions. Each planned action carries expected target state. Execution locks or CAS-checks the manifest and relevant target paths, then applies through a recoverable journal. Managed-file drift blocks by default.
  3. Collision keys at plan time. Case-folded and Unicode-normalized collision keys are computed before plan approval; overlapping target roots are rejected.
  4. Plugin trust. Transform configs that can execute code are trusted input; hosts may disable exec and code-level hooks. Plugins see plan-scoped data only and may not override the invariants above.
  • Q-8: whether any frontmatter flag (publish: false, private: true) may ever be overridden by dependency expansion, and the exact embed degrade behavior.
  • Q-9: transform closure — may transforms introduce references to non-survivors, and if so, bounded-fixpoint re-expansion versus deliberate degradation.
  • Q-10: the precise hash/lock/journal recovery sequence and its crash matrix.
  • Q-11: the plugin capability surface — what data plugins see, which hooks a host can disable, and how third-party plugin trust is declared.

D-7VMX-markdown-ecosystem-strategy review-discussion.md (R-5, R-6, Q-8..Q-11); vault-transform-dossier/architecture/vault-transform/design/filtering.md, expansion.md, sync-and-manifest.md, path-mapping.md.


← Back to Decisions