Start with the irreversible sinks

Intake is structured around one question: Where can your system commit irreversible external effects? We scope governance only for those declared sinks and propose the appropriate tier.

✅ What to send (minimum viable intake)

• A short description of the system and what irreversible actions it can perform.
• A list of suspected sinks (even if incomplete) and the teams that own them.
• Your preferred tier (if known) or your constraints (time, engineering bandwidth, urgency).

🧩 Irreversible sink template (copy-ready prompts)

• Sink name + what “commit” means
  (e.g., funds released, config mutated, delete executed)
• Inputs to the sink (high-level) and where the sink is invoked from (high-level)
• What would constitute an invalid execution (business or technical invalidity)

🔒 Constraints & boundaries (so we don’t over-scope)

• Which sinks are in scope vs explicitly out of scope.
• Deployment / integration constraints (environmental, operational, language/runtime at a high level).
• Evidence expectations: what reviewers need to see to trust VETO ⇒ no side effects.

🧾 What happens after submission

• We respond with a tier recommendation and proposed artifact list.
• We define scope boundaries for declared sinks and confirm success criteria.
• Work begins with Spec Pack outputs (even if proceeding to Full Build).

🛡️ Handling note

• Initial intake can be done with sanitized descriptions.
• Deeper details can be shared under your normal confidentiality process.
• Avoid sending secrets or credentials via intake.