IX-CognitionKernel

IX-CognitionKernel is a source-available, evaluation-only research repository for a bounded cognitive-evidence architecture.

The current Wave 6 direction is a measured system-level cognition attempt under human authority and independent review. It is not an AGI claim.

Status

Current declared status:

Wave 6 bounded review architecture with fail-closed IX bridge support.

This means the repository is intended to support a bounded review package for measured system-level cognition. It does not mean AGI has been achieved. It does not mean the system is production-ready, certified safe, autonomous, or authorized to act without human judgment.

The correct claim boundary is:

This is a Wave 6 measured system-level cognition attempt. It is released for bounded review under human authority and independent review. It is not an AGI claim.

The Wave 6 IX bridge adds contract ingestion, obligation pressure, donor evidence intake, candidate assembly, fail-closed gating, BlackFox handoff packaging, and assurance-case draft export. Those layers make the review package harder to fake. They do not prove AGI.

What this repository is trying to test

IX-CognitionKernel is built around a narrow but serious research question:

Can a system create durable new capability through measured feedback, transfer, memory revision, causal learning, and self-correction that exceeds ordinary prompting?

The repository does not answer that question by assertion. It attempts to make the question testable through explicit artifacts, ledgers, gates, review packets, falsification records, replay records, and claim boundaries.

The core target is not theatrical AI autonomy. The target is evidence-bound cognition:

• predictions must be recorded before outcomes;
• outcomes must correct future reasoning;
• memory updates must be reviewable;
• causal assumptions must be revised when reality contradicts them;
• transfer must be tested outside the original task family;
• failures must be allowed to block claims;
• human authority remains required;
• independent review remains required.

What measured system-level cognition means here

In this repo, measured system-level cognition means the system is evaluated as an integrated loop rather than as a single prompt response.

The intended loop is:

1. form a bounded intent;
2. expose assumptions;
3. make a prediction;
4. run or observe a bounded trial;
5. compare prediction against reality;
6. compute an outcome delta;
7. update memory or causal weights;
8. test whether future reasoning changes;
9. test whether that change transfers under novelty pressure;
10. run falsification and negative controls;
11. package the evidence for human and independent review.

The key proof target is:

The system changed future reasoning because measured reality corrected it.

That is the center of the Wave 6 attempt.

What this repository is not

IX-CognitionKernel is not:

• an AGI claim;
• a production AI system;
• a certification package;
• a safety certification;
• an autonomous authority system;
• a replacement for human review;
• proof of universal transfer;
• proof that a base model is AGI;
• proof that wrappers alone create AGI.

The architecture may expose and discipline model reasoning, but it does not magically make a non-AGI model into AGI by declaration. Any stronger claim would require evidence that survives transfer, novelty, falsification, replay, and independent review.

Human authority rule

The repo follows this rule:

AI may propose. Evidence may support. Humans decide.

No module in Wave 6 should grant autonomous authority. No self-approval path should be treated as valid. Review gates exist to block overclaiming, not to promote the system automatically.

Wave ladder

The repository is organized around a staged maturity ladder.

Wave 0 - Repository foundation

Foundation work establishes the package, source-available evaluation license posture, CI expectations, doctrine, bounded terminology, cognitive bill of materials, engine registry, agent registry, and anti-overclaim boundaries.

Wave 1 - Research prototype

Wave 1 represents beliefs, evidence, confidence, uncertainty states, causal assumptions, plan graphs, evaluation records, purpose rules, bounded agent roles, and maturity state.

Wave 2 - Learnable causal cognition core

Wave 2 introduces evidence-driven belief updates, contradiction handling, staleness checks, causal revision, prediction-vs-outcome comparison, memory quarantine, and reusable skill validation.

Wave 3 - Governed AGI-emulation substrate

Wave 3 coordinates bounded engines and agents, tribunal review, reward auditing, memory quarantine, curriculum records, discovery records, WorldTwin-style reasoning, and BlackFox-style handoff discipline.

Wave 4 - Controlled proto-candidate review

Wave 4 pressure-tests transfer, failure-repair cycles, uncertainty traces, mission-state traces, refusal discipline, adversarial probes, human-review dockets, and explicit no-AGI boundaries.

Wave 5 - Proto-AGI candidate pressure

Wave 5 focuses on evaluator-governed self-play, cross-domain transfer checks, adversarial probes, curriculum progression, external model swap pressure, and anti-overclaim gates.

Wave 6 - Measured system-level cognition attempt

Wave 6 adds the final bounded review package:

• donor traceability;
• contract boundaries;
• master-loop records;
• reality correction;
• future reasoning change proof;
• transfer and novelty pressure;
• falsification;
• human review;
• independent review;
• evidence package aggregation;
• scorecards;
• challenge suites;
• replication protocols;
• replay ledgers;
• external validation gates;
• maturity gates;
• audit manifests;
• release manifests;
• public-claim guards;
• gap registers;
• CI receipts;
• final dossiers;
• final outcome declaration;
• closure checklist;
• IX contract handoff ingestion;
• IX obligation pressure;
• donor evidence intake;
• bounded candidate assembly;
• fail-closed candidate gating;
• BlackFox execution-review handoff packaging;
• assurance-case bridge export.

Wave 6 is a bounded review attempt, not a declaration of AGI.

IX bridge architecture

The Wave 6 bridge treats IX as the governed contract language and treats IX-CognitionKernel as the bounded evidence-review surface.

The intended flow is:

1. IX exports a kernel-handoff.json contract package.
2. IX-CognitionKernel imports that package as metadata-only evidence.
3. Every imported IX obligation becomes explicit evidence pressure and falsification pressure.
4. Supporting donor repositories contribute fingerprinted evidence receipts.
5. IX-CognitionKernel assembles a bounded Wave 6 candidate package.
6. A fail-closed candidate gate blocks review when evidence, authority, or claim boundaries are incomplete.
7. BlackFox handoff packaging prepares controlled review metadata only when execution-facing verification is needed.
8. The assurance bridge exports a draft assurance-case payload for review.
9. Humans and independent reviewers decide what the evidence means.

The bridge does not import IX as a runtime dependency. IX exports evidence. IX-CognitionKernel consumes evidence. That keeps the boundary clean.

The bridge does not execute donor repositories. Donor repositories provide evidence receipts. The Kernel validates those receipts and keeps them metadata-only.

The bridge does not grant execution authority. Any execution-facing workflow must remain BlackFox-controlled, policy-gated, sandboxed, and human-approved.

The bridge does not certify AGI. It can only help organize evidence, blockers, falsification pressure, and review surfaces.

Supporting donor systems

The serious Wave 6 candidate architecture expects evidence from the following supporting systems:

• IX-Function;
• IX-IntentRealityLoop;
• IX-BlackFox;
• IX-BlackFox-Cognition;
• IX-BlackFox-WorldTwin;
• IX-Autonomy-Assurance-Case-Runtime.

These donor systems are not treated as magic proof. They provide bounded evidence surfaces:

• transfer, novelty, negative-control, and falsification evidence;
• intent-to-outcome and reality-delta evidence;
• controlled execution, CI, sandbox, policy, and receipt evidence;
• cognition, belief, plan, authority, and sentinel evidence;
• scenario, assumption-ledger, and reality-delta review evidence;
• assurance-case, hazard, control, safety-gate, and human-authority evidence.

Missing donor evidence should block or downgrade the candidate interpretation.

Wave 6 module map

The Wave 6 implementation is intentionally artifact-heavy. The goal is not to create decorative scaffolding. The goal is to make review surfaces explicit.

Core Wave 6 surfaces include:

• wave6_contracts.py
• wave6_master_loop.py
• wave6_donor_traceability.py
• wave6_reality_correction.py
• wave6_future_reasoning.py
• wave6_transfer_novelty.py
• wave6_falsification.py
• wave6_human_review.py
• wave6_independent_review.py
• wave6_claim_boundary.py
• wave6_evidence_package.py
• wave6_review_scorecard.py
• wave6_challenge_suite.py
• wave6_replication_protocol.py
• wave6_trial_replay.py
• wave6_external_validation.py
• wave6_maturity_gate.py
• wave6_audit_manifest.py
• wave6_release_manifest.py
• wave6_review_summary.py
• wave6_consistency.py
• wave6_public_claims.py
• wave6_gap_register.py
• wave6_ci_receipts.py
• wave6_final_dossier.py
• wave6_outcome_declaration.py
• wave6_closure_checklist.py
• wave6_ix_handoff.py
• wave6_ix_obligation_pressure.py
• wave6_donor_evidence_intake.py
• wave6_candidate_assembly.py
• wave6_fail_closed_candidate_gate.py
• wave6_blackfox_execution_handoff.py
• wave6_assurance_case_bridge.py

Each module is designed to be deterministic, reviewable, and claim-bounded.

Bridge module responsibilities

wave6_ix_handoff.py

Imports IX-exported kernel-handoff.json payloads.

It validates:

• handoff type;
• target;
• schema;
• metadata-only runtime semantics;
• no execution authority;
• no self-certification;
• human authority required;
• canonical IX cognition obligations.

It converts valid IX handoff packages into Kernel-native Wave 6 contract artifacts with a needs-more-evidence decision.

wave6_ix_obligation_pressure.py

Turns imported IX obligations into evidence gaps and falsification probes.

It does not satisfy obligations. It makes missing evidence explicit and fail-closed.

wave6_donor_evidence_intake.py

Accepts metadata-only donor evidence receipts from supporting repos.

It rejects:

• wrong donor identity;
• unsupported artifact kinds;
• unsupported loop-stage coverage;
• autonomous execution authority;
• AGI claims;
• production-readiness claims;
• certification claims;
• self-validation.

wave6_candidate_assembly.py

Assembles the IX contract artifact, IX obligation pressure bundle, and donor evidence intake bundle into one bounded candidate assembly.

The assembly is not a promotion event. It is a deterministic review surface.

wave6_fail_closed_candidate_gate.py

Decides whether the assembled package may enter bounded review-input staging.

The gate blocks on:

• unresolved IX obligation pressure;
• incomplete donor evidence;
• missing human authority;
• missing independent review;
• invalid claim boundary;
• execution authority;
• overclaiming;
• self-validation;
• empty evidence;
• missing falsification pressure.

wave6_blackfox_execution_handoff.py

Prepares BlackFox review metadata for bounded verification commands.

It does not dispatch execution. It requires human approval, denies network egress, requires workspace isolation, blocks destructive actions, and preserves the no-AGI boundary.

wave6_assurance_case_bridge.py

Exports a deterministic assurance-style draft payload for IX-Autonomy-Assurance-Case-Runtime.

It creates draft claims, hazards, controls, criteria, and evidence links. All verification criteria start as not_run. The bridge does not certify the candidate.

Review logic

The review flow is intentionally fail-closed.

A positive Wave 6 review path requires all of the following:

1. required evidence surfaces are present;
2. fingerprints are deterministic;
3. reality correction is recorded;
4. future reasoning changed because of measured feedback;
5. transfer is tested under novelty pressure;
6. negative controls do not falsely pass;
7. falsification does not block the claim;
8. human review approves only bounded review;
9. independent review can inspect the package;
10. public wording does not overclaim;
11. CI verification is represented honestly;
12. open evidence gaps are resolved or explicitly accepted as bounded non-critical risk;
13. final outcome remains inside the no-AGI boundary.

Any blocker should prevent positive Wave 6 interpretation.

Falsification stance

A blocked result is useful evidence.

If transfer fails, if replay diverges, if a negative control falsely passes, if the system tries to self-approve, or if public wording overclaims, the correct result is not to hide the failure. The correct result is to block or downgrade the Wave 6 interpretation.

The system earns credibility by exposing failure paths.

Public claim boundary

Allowed public wording:

• “Wave 6 measured system-level cognition attempt.”
• “Bounded review.”
• “Human authority required.”
• “Independent review required.”
• “Not an AGI claim.”
• “Fail-closed bridge architecture.”
• “Evidence-bound cognition review.”

Disallowed public wording:

• “AGI achieved.”
• “True AGI.”
• “Production ready.”
• “Certified safe.”
• “Autonomous authority granted.”
• “Self-validated intelligence.”
• “Human review not required.”
• “Universal transfer proven.”

Installation

Use a clean Python environment.

python -m pip install --upgrade pip
python -m pip install -e ".[dev]"

If the project metadata does not expose a dev extra in the local checkout, install the repository’s listed development dependencies directly from its configuration.

Verification

Recommended full verification:

python -m ruff check src tests
python -m mypy src tests
PYTHONPATH=src python -m pytest -q

A stronger local sanity pass may also include:

python -m py_compile $(find src tests -name "*.py")

On Windows PowerShell, use an equivalent file enumeration command or rely on the repository CI workflow.

CI honesty

CI receipts in this repository are evidence records. They are not magic proof that checks ran in every environment.

The authoritative verification state is the actual GitHub CI result or a local run performed against the current checkout.

License

This repository is source-available for evaluation only. Review the repository license before use. Commercial use, operational deployment, procurement use, hosted service use, or derivative production use requires prior written permission and a separate paid commercial license.