What IDG is
IDG is a fast, local gate evaluated exactly at the interface where a system receives signals, data, or commands from outside its trusted domain.
- checks determinability (can this be explained and audited?)
- checks boundary integrity (does this violate declared scope?)
- checks responsibility leakage (is ownership implicit or missing?)
If IDG conditions are not satisfied, the system must fail closed.
What IDG is not
IDG defines hard stops and reject reasons, not outcomes. It is not:
- a decision mechanism
- a policy engine
- a replacement for human judgment
- a way to “make AI safe” by post-hoc explanation
- a substitute for RP (Resolution Protocol)
Where IDG sits in VCDesign
In BOA, artifacts are separated into Fact, Meaning, and Responsibility.
Meaning → Responsibility (promotion)
External / Untrusted Input → System Boundary
IDG can be deployed even when governance is incomplete because it does not claim authority — it only blocks what is undeterminable.
Fail-closed by design
IDG defaults to fail-closed:
- Default outcome: block
- If determinability is insufficient: reject with a reason
- If a boundary is violated: reject with explicit boundary reference
Design principles
- Fast: minimal checks, low operational burden
- Local: scoped to the interface, not system-wide governance
- Explainable: every block has a clear, documentable reason
- Non-authoritative: it does not “decide”; it only denies passage
- Composable: multiple IDGs can exist at different boundaries
Relationship to RP
IDG and RP are complementary:
- IDG blocks early (boundary integrity and determinability)
- RP governs promotion (Meaning → Responsibility)
- IDG can exist without RP
- RP assumes an explicit Responsible Domain; IDG does not
Specification & Further reading
IDG is intended to be implemented as a simple gate (code, config, or contract clause) at any interface where determinability matters.