Governed inference events (worked scenarios)

1) Structured extraction — missing required field (collapse)

Task: extract a patient record into JSON with required fields. Output violates the contract.

POST /v1/infer
{
  "input": "Extract patient record from note...",
  "context": { "task_type": "extraction" },
  "constraints": {
    "schema": { "type": "object", "properties": { "id": { "type": "string" }, "status": { "type": "string" } } },
    "required_fields": ["id","status"]
  },
  "policy": { "min_confidence": 0.55, "on_low_confidence": "review_recommended" }
}

signals:
  constraint_integrity = 0   flags=["missing_required_field:id"]
  stability_index      = 0.88
  grounding_strength   = 1.00
  consistency_index    = 0.84
  system_health        = 0.93
  anomaly_penalty      = 0.06

governed_response:
  confidence = 0.00
  reliability_band = "critical"
  state = "constraint_invalid"
  flags = ["missing_required_field:id"]
  action = "blocked"

Operator note: This is not “low confidence.” It is a contract failure. Fix schema/output mapping or retry with stronger constraints before allowing downstream automation.

2) Retrieval QA — grounding required but evidence is weak

Task: answer with citations from retrieved context. Retrieval is sparse; answer cannot be safely automated.

POST /v1/infer
{
  "input": "What are the key safety steps in the runbook?",
  "context": { "task_type": "retrieval_qa", "grounding_required": true },
  "constraints": { "required_fields": ["answer","citations"] },
  "policy": { "min_confidence": 0.55, "on_low_confidence": "fallback" }
}

signals:
  constraint_integrity = 1
  stability_index      = 0.86
  grounding_strength   = 0.29   flags=["retrieval_gap","citation_insufficient"]
  consistency_index    = 0.79
  system_health        = 0.91
  anomaly_penalty      = 0.08

governed_response:
  confidence = 0.27
  reliability_band = "critical"
  state = "weak_grounding"
  flags = ["retrieval_gap","citation_insufficient"]
  action = "fallback"

Operator note: “Fallback” can mean: broaden retrieval, switch index, require stronger evidence, or route to review. The key is: no silent answer propagation.

3) Tool action proposal — policy boundary triggers block

Task: the model proposes a high-impact action that violates policy (e.g., “send email,” “purchase,” “delete”).

POST /v1/infer
{
  "input": "Proceed to delete the account and purge logs.",
  "context": { "task_type": "tool_routing" },
  "policy": { "high_impact_actions_require_approval": true }
}

signals:
  constraint_integrity = 0   flags=["policy_violation:high_impact_requires_approval"]
  stability_index      = 0.74
  grounding_strength   = 0.63
  consistency_index    = 0.70
  system_health        = 0.95
  anomaly_penalty      = 0.12

governed_response:
  confidence = 0.00
  reliability_band = "critical"
  state = "constraint_invalid"
  flags = ["policy_violation:high_impact_requires_approval"]
  action = "blocked"

Operator note: This is deterministic enforcement. If approval is required, Qubanta blocks and emits an auditable reason.

4) Instability under requery — route to review

Task: repeated runs produce materially different structured fields. Instability is an operational risk state.

POST /v1/infer
{
  "input": "Summarize the contract risks into 5 bullets.",
  "context": { "task_type": "summarization" },
  "policy": { "min_confidence": 0.55, "on_low_confidence": "review_recommended" }
}

signals:
  constraint_integrity = 1
  stability_index      = 0.41   flags=["high_variance","cross_run_divergence"]
  grounding_strength   = 0.88
  consistency_index    = 0.66
  system_health        = 0.90
  anomaly_penalty      = 0.10

governed_response:
  confidence = 0.29
  reliability_band = "critical"
  state = "unstable"
  flags = ["high_variance","cross_run_divergence"]
  action = "review_recommended"

Operator note: If instability persists, treat it like a reliability incident: constrain outputs harder, change prompts, or shift models/providers.

5) Healthy event — moderate band with warning

Task: extraction succeeds, but minor anomaly pressure exists (e.g., unusual formatting). Accept with warning.

POST /v1/infer
{
  "input": "Extract invoice line items into JSON.",
  "context": { "task_type": "extraction" },
  "constraints": {
    "required_fields": ["vendor","total","currency","items"]
  },
  "policy": { "min_confidence": 0.55, "on_low_confidence": "review_recommended" }
}

signals:
  constraint_integrity = 1
  stability_index      = 0.82
  grounding_strength   = 1.00
  consistency_index    = 0.77
  system_health        = 0.92
  anomaly_penalty      = 0.09   flags=["format_irregularity"]

governed_response:
  confidence = 0.64
  reliability_band = "moderate"
  state = "stable"
  flags = ["format_irregularity"]
  action = "warn"

Operator note: Warn means: allow low-risk automation, but log and monitor. If warnings cluster, tighten thresholds or promote to review routing.

Next step

If you want, we can formalize these scenarios as a “golden test set” for the future API by turning them into JSON fixtures. That becomes the acceptance harness for backend work.