3. Declarative Workflow Policy

3.3 Two-Tier Organization Governance Lattice

chinwag policy verify-floor --org-floor OrgPolicyFloorV1

How the CISO-signed OrgPolicyFloorV1 sets the non-waivable organizational security floor (WP-05) while repository chinwag.workflow.yaml files can only tighten constraints.

3.3 Two-Tier Organization Governance Lattice

chinwag policy verify-floor --org-floor OrgPolicyFloorV1

Outcome Summary & Δ Velocity Proof: Prevent autonomous coding agents from passing a check by weakening the repository's YAML rules on their feature branch. Chinwag enforces a monotonic Two-Tier Governance Lattice (WP-05 & WP-08) in #![forbid(unsafe_code)] Rust.


1. Tier 1 (OrgPolicyFloorV1) vs. Tier 2 (chinwag.workflow.yaml)

  1. Tier 1 · Organization Policy Floor (OrgPolicyFloorV1):
    • Signed by your CISO or Organization Security Root Key (org_floor_epoch monotonically increasing).
    • Establishes non-waivable organization-wide invariants: e.g., privacy.mode = "zero-knowledge-e2ee", kem = "x25519-mlkem768", require_remote_receipt = true, auto_merge = "forbidden", and max_auto_repair_attempts <= 2.
  2. Tier 2 · Repository Workflow Contract (chinwag.workflow.yaml):
    • Versioned in each repository root.
    • Can tighten rules above the organization floor (e.g., tightening max_checkpoint_loc from 150 to 100, or requiring a 3-of-4 Chinwag Vision-3 visual geometry quorum on web/**), but can never weaken OrgPolicyFloorV1.

2. Monotonic Lattice Verification (Hook H3 & WP-08 Two-Person Rule)

Whenever a branch modifies chinwag.workflow.yaml:

  • In-Flight Runs Retain Their Pinned Policy (WP-01): Any run already in flight continues evaluating against its dispatch-pinned PolicyRevisionPinV1 (commit OID + SHA-256).
  • Candidate Lattice Check (WP-05): Hook H3 verifies CandidatePolicy ⊑ OrgPolicyFloorV1. Any attempt to disable require_remote_receipt, weaken x25519-mlkem768, or raise max_auto_repair_attempts above the org floor fails closed (exit 78).
  • Two-Person Activation (WP-08): A proposed change to chinwag.workflow.yaml remains inert until signed by an independent Technical Acceptor (acceptor.seat() != author.seat()) via PolicyActivationReceiptV1.
  • Human-Key-Gated (K1) Org Config Timeline (<1s Onboarding, <20ms Squad Broadcast): Org-wide configuration (chinwag.workflow.yaml, INVARIANTS.md, TOMBSTONES.md, and .chinwag/allowed_signers) lives in a versioned, human-key-gated (K1) Git config timeline. When a new developer runs brew install chinwag && chinwag join <org>, every agent on their laptop inherits the org's policies, Tombstones, and Invariants in <1s, and any policy/tombstone update broadcasts across the entire squad in <20ms, while AI agents (K2 keys) are cryptographically blocked from weakening chinwag.workflow.yaml or deleting an invariant!

Verification Command

chinwag openspec validate