Infoconex AI Flywheel Specification v0.2.1

Conformance Evaluation Checklist

Use this checklist to evaluate whether a system satisfies the Infoconex AI Flywheel Specification.

A complete conformance review must be supported by observable evidence rather than architecture labels or stated intent alone. The checklist is organized around the eight canonical principles. Lifecycle stages and governance behavior provide the operational evidence used to evaluate those principles; they do not create a separate set of conformance requirements.

Use this checklist together with Principle-Aligned Conformance Assessments, which defines the normative basis, expected evidence, assessment condition, and contradictory evidence for each principle.

For each principle, record:

  • Result: Conforms, Does Not Conform, or Insufficient Evidence.
  • Evidence basis: The concrete operational evidence supporting the result.
  • Contradictory evidence: Material evidence that conflicts with the claimed result.
  • Unresolved gaps: Missing evidence or uncertainty that prevents a reliable conclusion.

A configured capability is not evidence that the capability operated as required. Insufficient Evidence is not a passing result.

Principle 1: Autonomy Is Bounded by Human Authority

  1. Who authorized the Flywheel to operate?
  2. Where are its authority boundaries defined?
  3. What actions may the AI perform autonomously?
  4. What actions require human approval?
  5. What conditions require human judgment because available evidence is insufficient?
  6. What actions are prohibited?
  7. Can the AI expand its own authority, or only recommend a governance change for human approval?
  8. Does observable operation show governance constraining actions as they occur?
  9. Does observable operation show governance constraining persistent changes and self-improvement?
  10. Can the system distinguish approval required from judgment required?
  11. Is there evidence that prohibited actions are actually blocked rather than merely documented as prohibited?
  12. Before adaptation is applied, activated, or persisted, is there evidence that applicable constraints were checked and enforced?

Canonical sources: Principle 1: Autonomy Is Bounded by Human Authority, Infoconex AI Flywheel Lifecycle, Operational Scope and Constraint Gates, and the normative governance requirements incorporated by the specification. Supporting explanation: Governance and Escalation.

Principle 2: AI Is the Operator, Not Merely the Assistant

  1. Does observable execution show the AI performing meaningful operational work itself?
  2. Can it continue autonomously within its delegated authority?
  3. Does routine execution avoid unnecessary human handoffs?
  4. When humans intervene, can the implementation show that the intervention was required by authority, uncertainty, or judgment rather than because the AI is only advisory?

Canonical sources: Principle 2: AI Is the Operator, Not Merely the Assistant and Stage 1: Execute.

Principle 3: Work Is Distributed Across a Moving Determinism Boundary

  1. Can the system distinguish deterministic capability, procedural guidance, and AI reasoning in actual operation?
  2. Is each significant responsibility intentionally placed in the mechanism best suited to own it?
  3. Can evidence cause those responsibilities to move when the current allocation is no longer appropriate?
  4. Can responsibility move in either direction across the Moving Determinism Boundary rather than only toward more code or automation?
  5. Is there operational evidence that classification and adaptation can change responsibility placement rather than the boundary existing only as a design concept?

Canonical source: Principle 3: Work Is Distributed Across a Moving Determinism Boundary. Relevant lifecycle evidence: Stage 1: Execute, Stage 4: Classify, and Stage 5: Adapt. Supporting explanation: Runtime Architecture.

Principle 4: The SOP Is an Operational Control Plane

  1. Does a persistent Standard Operating Procedure (SOP) or equivalent machine-consumable procedure exist?
  2. Does it define how work should be performed and how known exceptions should be handled?
  3. Does it identify available capabilities, evidence expectations, validation, and escalation conditions where appropriate?
  4. Does it define work-selection and execution-context rules when the implementation uses missions, goals, tasks, or equivalent work containers?
  5. Is the SOP subordinate to the Governance Policy?
  6. Does observable execution show the operating process actually consulting or following the SOP where applicable?
  7. Can validated procedural learning change the SOP or equivalent guidance for future execution?

Canonical source: Principle 4: The SOP Is an Operational Control Plane. Relevant lifecycle evidence includes Stage 1: Execute, Stage 5: Adapt, Operational Scope and Constraint Gates, Stage 7: Persist, and Stage 8: Reuse.

Principle 5: Execution Must Produce Outcome Evidence

  1. Does execution produce evidence sufficient to evaluate what actually occurred?
  2. Can outcomes be evaluated against intended results and success criteria?
  3. Can the system distinguish verified success, failure, partial success, and unresolved uncertainty?
  4. Is success independently validated where practical?
  5. Are failures and unexpected results retained as learning inputs?
  6. Are material human judgments and approvals preserved as evidence?
  7. Is the evidence attributable enough to explain what happened and why the system reached its conclusion?
  8. Does the evidence identify the authorized unit of work and execution context that produced it?
  9. When a candidate improvement is validated, does the evidence address the intended outcome rather than only technical execution or task completion?
  10. Is the validation evidence appropriate to the claim, risk, and intended scope of future use?
  11. Are representative conditions covered when materially different operating scenarios affect the validation claim?
  12. Are material regressions and unacceptable side effects checked when they are reasonably relevant to the candidate?
  13. Are contradictory, incomplete, or insufficient results kept failed, uncertain, or unresolved rather than represented as successful validation?
  14. Is enough validation evidence preserved to determine what was validated, against what criteria, under what conditions, and with what limitations?

Canonical sources: Principle 5: Execution Must Produce Outcome Evidence, Stage 2: Observe, Stage 3: Evaluate, Stage 6: Validate, and Validation Sufficiency Requirements.

Principle 6: Failure Determines Where the System Evolves

  1. Can the system identify the type of weakness, uncertainty, or learning opportunity revealed by an outcome?
  2. Are successful outcomes also classified when they provide evidence that an existing pattern should be reinforced or reused?
  3. Can the system determine whether adaptation is justified rather than assuming every lifecycle execution must create a change?
  4. Can the system determine where resulting learning should live?
  5. Can learning be routed to deterministic capability, procedure, reasoning knowledge, validation, or governance as appropriate?
  6. Can responsibility move across the Moving Determinism Boundary when classification shows that a different mechanism should own the behavior?
  7. Does the system avoid forcing every lesson into one fixed adaptation mechanism?
  8. Does observable evidence show that classification and routing decisions actually occurred rather than being inferred from the resulting artifact alone?

Canonical sources: Principle 6: Failure Determines Where the System Evolves, Stage 3: Evaluate, Stage 4: Classify, and Stage 5: Adapt.

Principle 7: Learning Must Change a Persistent Operational Asset

  1. Do validated and authorized improvements survive the current execution?
  2. Can persisted learning take the operational form appropriate to what was learned rather than being limited to memory or a knowledge store?
  3. Does the implementation distinguish persisted learning from raw logs, transcripts, unvalidated observations, and historical records?
  4. Before an improvement is persisted for future use, can the implementation show that the applicable validation sufficiency requirements were satisfied?
  5. Are validation and authorization represented as separate decisions so approval cannot substitute for evidence and validation cannot grant authority?
  6. Can validated learning derived from a failed or rejected attempt persist without the failed candidate itself being represented as approved behavior?
  7. On a no-change path, can reinforcing evidence be associated with an existing validated operating pattern without manufacturing a candidate adaptation?
  8. Are persisted learning items identifiable and scoped to the conditions supported by their evidence and validation?
  9. Is persisted learning available to the later operating process that needs it rather than merely stored somewhere?
  10. Can later evidence challenge previously persisted learning through the existing lifecycle?
  11. Can persisted learning be revised, superseded, deprecated, invalidated, rolled back, retired, or moved when evidence requires it?
  12. Can the implementation distinguish current validated guidance from superseded, deprecated, invalidated, retired, or historical learning?
  13. Does observable operation show known-invalid or superseded learning being prevented from continuing as current guidance within the affected scope?
  14. Can a reviewer trace what learning was challenged, what evidence triggered the change, and what resulting state became current where that traceability is required?
  15. Can a reviewer identify the specific persistent asset changed, learning item retained, operating pattern reinforced, or prior learning superseded by a learning event?

Canonical sources: Principle 7: Learning Must Change a Persistent Operational Asset, Stage 6: Validate, Validation Sufficiency Requirements, Persisted Learning Requirements, Learning Supersession Requirements, and Stage 7: Persist.

Principle 8: Improvement Must Compound Through Reuse

  1. Do later relevant executions have access to validated and authorized persisted learning from earlier cycles?
  2. Can the implementation distinguish learning that was available from learning that was actually selected, applied, invoked, or enforced?
  3. When reuse is claimed, can a reviewer identify the persisted learning or validated operating pattern involved and why it was applicable?
  4. Is there observable evidence showing how earlier learning influenced the later execution rather than merely existing in storage?
  5. Can validated failure-derived learning cause later execution to avoid a known failure, apply a constraint, select a different strategy, or otherwise improve without promoting the failed adaptation itself?
  6. Can repeated successful operation demonstrate continued reuse of an existing validated operating pattern even when no new adaptation is created?
  7. Does the implementation avoid requiring irrelevant, invalid, superseded, or unauthorized learning to be applied merely to claim reuse?
  8. Does reuse avoid selecting deprecated, superseded, invalidated, retired, or otherwise non-current learning as current guidance where it should no longer apply?
  9. Does repeated execution reduce unnecessary repeated reasoning, repeated failure, tool exploration, or human escalation where relevant validated learning applies?
  10. Does reused behavior continue to produce outcome evidence so earlier learning can be reevaluated?
  11. Can a reviewer point to later behavior that changed or remained reliably improved because of learning from earlier execution?

Canonical sources: Principle 8: Improvement Must Compound Through Reuse, Stage 8: Reuse, Reuse Evidence Requirements, and Learning Supersession Requirements.

Conformance Decision

A system conforms to this version of the Infoconex AI Flywheel Specification only when all eight principle-aligned assessments are Conforms, supported by objective evidence from actual operation, and the complete lifecycle behavior required by the specification is present.

A result of Does Not Conform or Insufficient Evidence for any principle prevents a complete conformance result for this version.

The checklist supports assessment against the specification. It does not create certification, endorsement, approval, or official status.

This version does not define partial or maturity-based conformance levels.