VCDesign BOA IDG Library / IDG Boundary Patterns

IDG Boundary Patterns

This page is optional. It is not a set of requirements, and not a reference implementation. It provides boundary patterns that reveal where determinability breaks and why an IDG blocks passage.

Not examples to follow.
Treat these as boundary lenses: keep the structure, adapt the details locally.

Related repositories (pattern workbench): interface-determinability-gate

Structural notice — non-direct execution boundary

In systems where non-deterministic or responsibility-bearing judgments are involved, this library assumes the existence of a structural boundary that prevents such judgments from being passed directly into execution, control, or promotion layers.

This boundary is structural, not algorithmic. It does not decide outcomes, enforce policies, or optimize results. Its sole role is to interrupt passage when determinability, ownership, or scope cannot be made explicit before downstream effects occur.

Whether the judgment source is human, rule-based, or AI-driven is intentionally left unspecified. Only the placement of the boundary is fixed:

The patterns below illustrate where such boundaries commonly appear—not how they are implemented.

structural boundary non-direct execution judgment isolation

Minimum gate conditions (ambiguity signals)

IDG does not decide outcomes. It blocks when any of the following is ambiguous.

IDG: non-governance IDG: fail-closed IDG: local

Pattern 1 — API Boundary Gate

Boundary: External API client → Internal service

Input

  • payload fields, headers, auth context, rate-limits
  • optional AI-generated fields (if any) must be marked as candidates

Why this boundary exists

  • Prevent silent coupling (unknown fields become “features”)
  • Prevent responsibility leakage (who owns the request meaning?)

What becomes ambiguous

  • Unspecified parameters that change meaning downstream
  • Implicit ownership (“the client assumed you would interpret this”)

Gate conditions (ambiguity signals)

  • Scope: fields outside declared contract → block
  • Ownership: no accountable caller identity / role → block
  • Auditability: missing correlation / request fingerprint → block
  • Explainability: reject reason cannot be stated as contract clause → block

Fail-closed behavior

  • Return 4xx with explicit reason code and boundary reference
  • Do not “fix” or “guess” missing fields

Non-goals

  • Not validating business correctness
  • Not deciding acceptance policies beyond the declared boundary

Pattern 2 — AI Input Gate (Prompt / Context Boundary)

Boundary: Human/system context → AI model input

Input

  • prompt, retrieved context, tool outputs, attachments
  • policy constraints and declared scope of assistance

Why this boundary exists

  • Prevent “probabilistic drift” from entering a responsibility-bearing flow
  • Keep the model inside the declared assistive role

What becomes ambiguous

  • Facts vs. guesses mixed without markers
  • Missing provenance of retrieved snippets
  • Requests that implicitly ask for decisions / authority

Gate conditions (ambiguity signals)

  • Auditability: no source/provenance for key claims → block
  • Scope: request exceeds declared assistive scope → block
  • Ownership: user seeks delegation of responsibility → block
  • Explainability: cannot express refusal in boundary terms → block

Fail-closed behavior

  • Return “cannot proceed” with a boundary reason (no speculative completion)
  • Request missing provenance or explicit ownership statement

Non-goals

  • Not maximizing helpfulness
  • Not producing a “best guess” when determinability is broken

Pattern 3 — OT → IT Data Handoff Gate

Boundary: Physical observation (OT) → Business artifact (IT)

Input

  • measurements, timestamps, collection conditions
  • metadata mapping (tag, unit, equipment context)

Why this boundary exists

  • Prevent meaning injection from becoming “fact” by accident
  • Preserve where responsibility begins (OT facts vs IT interpretations)

What becomes ambiguous

  • Unit / scale drift, sensor replacement, wiring changes
  • Interpretation promoted as “official KPI” without owner
  • Scope creep (using OT data to justify decisions without resolution)

Gate conditions (ambiguity signals)

  • Auditability: missing collection conditions / fingerprint → block
  • Scope: attempts to attach decision meaning at handoff → block
  • Ownership: KPI promotion lacks explicit owner → block
  • Explainability: cannot explain the mapping change as a tracked artifact → block

Fail-closed behavior

  • Quarantine the record / mark as non-promotable
  • Allow downstream to see “blocked” reason without auto-correction

Non-goals

  • Not deciding correctness of the physical world
  • Not replacing field verification or RP for promotion

Pattern 4 — Contractual Boundary Gate (Clause Pattern)

Boundary: Vendor deliverable → Client responsibility domain

Input

  • deliverables (reports, AI outputs, configs), acceptance criteria, scope
  • ownership statements and escalation path

Why this boundary exists

  • Prevent “implicit acceptance” from becoming responsibility
  • Make rejection explainable without arguing about intent

What becomes ambiguous

  • Who owns the final decision when AI is involved
  • What is inside/outside contract scope
  • Whether evidence is auditable after delivery

Gate conditions (ambiguity signals)

  • Ownership: no named accountable role for promotion → block
  • Scope: deliverable exceeds declared boundary → block
  • Auditability: missing evidence/provenance package → block
  • Explainability: reject reason cannot be stated as clause reference → block

Fail-closed behavior

  • Reject with explicit clause/boundary reference and reason code
  • Require explicit re-submission with ownership + provenance

Non-goals

  • Not evaluating quality of the vendor’s “best effort”
  • Not turning IDG into governance—only a rejectable boundary