Date Compiled: 2026-04-28
Type: concept — factory-methodology
Related Questions: task-criteria, agent-verification, quality-gates, task-definition
Related Articles: superada-multi-agent-architecture, superada-enterprise-operations, autonomy-policy-v3

Source Attribution: compiled/sources/superada-multi-agent-architecture.md · compiled/sources/superada-enterprise-operations.md

ISC — Inference Selection Criteria

What Is ISC?

Inference Selection Criteria (ISC) are the standard for writing task criteria in the SuperAda Enterprise Crew's formal execution algorithm. They define what makes a task criterion well-formed enough to serve as a reliable pass/fail signal for agent work.

ISC is part of the inner loop of the crew's 7-phase execution algorithm:

OBSERVE → THINK → PLAN → BUILD → EXECUTE → VERIFY → LEARN

Specifically, ISC governs the THINK phase: before an agent does work, it creates success criteria against which the VERIFY phase will run.

The Four Rules

Each ISC criterion must be:

  1. Exactly one concern — one clear condition, not a compound condition that could be satisfied two different ways
  2. Binary testable — either the criterion is met or it isn't, with no subjective judgment required
  3. Stated as a result, not an action — describes the outcome, not the step to get there
  4. Quick to verify — can be checked in seconds or minutes, not requiring a long-running process

Good ISC Examples

  • Tests pass
  • No credentials exposed in git history
  • Homepage loads without console errors
  • API returns 200 for /health
  • No 404 resources on page

Each of these is:
- One concern (not "tests pass AND no console errors AND API responds")
- Binary (pass/fail, no gray area)
- A result ("tests pass" not "run the test suite")
- Quick to verify (seconds to minutes)

Bad ISC Examples

  • Run the tests — this is an action, not a result
  • Check the repo — undefined, non-binary, too vague
  • Make sure it works — subjective, multi-concern, not testable

Bad ISCs fail on multiple dimensions: they don't give the VERIFY phase a clear pass/fail signal, they require interpretation, and they often combine concerns that should be separate criteria.

Why ISC Exists

Without ISC, agents produce work that sounds complete but cannot be programmatically verified. This creates two problems:

  1. The agent cannot self-verify — without a binary test, the agent must ask a human to judge quality
  2. Handoffs become ambiguous — the next agent in the chain doesn't know what "done" means

ISC forces every task to be framed as a testable claim about reality, not a request for effort.

Connection to Formal Algorithm

ISC applies in the THINK phase, before the PLAN and BUILD phases:

OBSERVE: Reverse-engineer the request
↓
THINK: Create success criteria (ISC) before doing the work  ← ISC lives here
↓
PLAN: Select capabilities and lock the approach
↓
BUILD: Produce artifacts
↓
EXECUTE: Run the work
↓
VERIFY: Prove success against criteria  ← ISC criteria are the test input here
↓
LEARN: Capture lessons

The autonomy-policy-v3 is complementary: ISC defines the quality of the criteria, the autonomy policy defines the authority to act on them.

Connection to Design Gates

In the dark-factory-kb's pipeline methodology, design gates perform a similar function — they are quality thresholds that work must pass before advancing. ISC is the micro-version of this: the per-task criterion that drives design-gate-style verification at the agent level.

Sources: superada-multi-agent-architecture.md (compiled/sources/)

autonomy-policy-v3, design-gate, superada-enterprise-operations, superada-multi-agent-architecture