Latest verified engineering — 25 October 2026
NIKI-generated Circuits must pass real original compiler inputs and independent oracles. The model selected public cutblock features, but the submitted assembly failed a dataset socket requirement; two hosted model calls returned unusable output and HTTP 429.
Oct 25 full engineering record · Contribution/use economy · Council qualification
Who this manual is for
Research sponsors, institutional reviewers, technical project owners and oversight teams. Readers should first understand the product scope and respect the fact that roles, contracts, source permissions and approvals cannot be created by a mere software screen.
Before starting
- Use only an official, current and authorized release.
- Identify which organization or account is responsible for the action.
- Review the permissions, data classification, allowed scope and supporting rights.
- Verify current product availability and the limits of published evidence.
- Do not disclose passwords, access tokens, financial details, sensitive source records or confidential algorithms.
01 — Prepare a research question
Describe the practical problem and desired result, provide only authorized materials, and define a measurable success criterion before any experiment.
02 — Review a candidate proposal
Check its objective, assumptions, scope, novelty claim and what independent evaluation was planned. Do not treat fluent explanation as proof.
03 — Read a test report
Compare attempted versions, test counts, failing input classes, environment, oracle and whether repairs were actually different and executed.
04 — Request a revision
Return a documented error or counterexample. Require NIKI to preserve the failed candidate and make the new proposal separately testable.
05 — Evaluate promotion to a reusable chip
Confirm test evidence, rights clearance, compatibility and authorization. Distinguish a research candidate from an accepted component.
06 — Escalate safety or rights concerns
Stop affected deployment or dissemination and involve competent reviewers when output may breach privacy, confidentiality, ownership, operational or legal restrictions.
Understanding statuses and results
Proposed: a design or candidate, not an accepted product or offering. Qualified: supported by named evidence within a stated test scope. Authorized: a competent rights holder, organization or regulator has given the particular approval required. Completed: the independently defined outcome has actually occurred, including any external settlement or delivery where applicable.
Common questions
Does the public document grant access?
No. Publishing a description or a manual does not give readers access to private software, underlying data or investments.
Does a test pass establish production readiness?
No. Tests must be interpreted by version and scope; actual production readiness requires the applicable operational, legal and security qualifications.
Who decides data or investment rights?
The legally competent rights holder, issuer, contracting parties and applicable authorities—not a software identifier or automation alone.
Support and issue records
Record the date, relevant public identifier, product version if known, symptom or question, steps observed and the minimum permitted evidence. Report through BTG’s official contact page. Avoid attaching unrelated confidential or personal records.
Detailed workflow and decision record
This is a task and review manual for a planned or specifically authorized deployment. Screen names, buttons, account permissions and automatic outcomes must be checked against the actual tested product version; where the UI has not been verified, instructions are deliberately expressed as actions, not invented clicks.
Define mandate
State practical question, allowed materials, expected behaviour, oracle and prohibited actions.
Review proposal
Check candidate identity and version without treating explanation as proof.
Inspect evaluation
Compare pass/fail counts with input domain, test origin and restricted runtime.
Request repair
Retain original failures, introduce a revised candidate and rerun unchanged challenge rules.
Decide retention
Require specific acceptance, owner-signed authority, provenance and restrictions.
Escalate safety
Stop promotion if code reaches prohibited files, devices, networks or rights.
Before operating — acceptance checklist
- Identify the actual operating version and service owner.
- Confirm your role and explicit authority for this data, research or financial action.
- Read the purpose, risks, permitted scope and available evidence before taking action.
- Know which support and incident-reporting channel applies and how to stop safely.
- Make no release, resale, rights-transfer or investment decision on a proposed record alone.
Expected workflow
- Receive an authorized problem and success criteria
- Search permitted prior knowledge and propose a candidate
- Freeze the exact candidate before evaluation
- Execute in a bounded test environment
- Compare independent oracle and negative cases
- Preserve failures, repairs and qualification decision
Problem and recovery guide
| What you notice | What to do |
|---|---|
| Output differs from oracle | Retain wrong cases and freeze current candidate as failed. |
| Dependency not available | Report blocked qualification, not success. |
| Sandbox boundary breached | Terminate evaluation and preserve negative-test evidence. |
| Unverified invention claim | Request unfamiliar-task benchmarks with truly separate graders and withheld holdouts. |
What the operator should record
- Date, timezone, role and intended action.
- Public object identifier and version, never a secret or private credential.
- The authority, permission or review reference in appropriately protected storage.
- Expected outcome versus observed result, including negative and failed cases.
- Whether action is proposed, internally qualified, externally authorized or actually completed.
- Escalation destination and final decision, if any.
What this manual does not promise
Not every capability described here is available to a public account or installed in a consumer application. Real operation depends on qualified builds, actual provider permissions, formally delegated roles and sometimes legal authorization. Do not infer an available menu, released feature, verified rights entitlement or active securities market from a conceptual workflow.
Documents to request before relying on a result
- Frozen candidate hashes and prompt/mandate references
- Independent test oracle and holdout definitions
- Raw pass/fail counts and observed counterexamples
- Sandbox cgroup/rlimit/network negative evidence
- Three-host replication if distributed claims made
- Owner-signed governed admission and provenance
Corporate system information → Engineering evidence and limitations → Publications → ENTITY (the separately published open component) →
AI Creation Council and FarmNode research — audited update
BTG has implemented a local, bounded AI Creation Council workflow. It can preserve local Qwen3-8B proposals in ADAM/BTDU, perform restricted reviews, independently test executable candidates inside a sandbox and retain only research evidence in FarmNetwork. Two different model-generated methods passed 65,536/65,536 bounded tests each. The Granby model candidate failed 256 of 65,536; the subsequent full-pass correction was reviewer-authored, not an autonomous NIKI repair.
Cross-model critiques were also exercised using fixtures; no real authenticated hosted multi-model inference or 25-task cross-domain comparison has been qualified. Local tests do not establish novelty, field utility, global superiority or production rights.
Read the complete AI Council research guide → · Public operator manual → · Printable evidence report →
UPDATED AUDIT · 23 OCT 2026 · 18:26 UTC
Latest Council and FarmNode qualification evidence
The completed 18:26 UTC audit reports 114/114 local tests in nine suites, including the earlier 70 tests (not 184 independent results). The 34 physical-host security tests qualify policy/refusal contracts only, not three real computers. Four explicitly approved hosted routes were zero-priced at the 18:17 UTC catalogue snapshot; no authenticated hosted inference comparison was completed.
The original Granby model-authored algorithm failed 256 of 65,536 cases. A separately documented engineer-reviewed deterministic repair passed 65,536/65,536 in isolated WebAssembly. This is not NIKI self-repair, a domain-qualified commercial invention, or owner-granted Genome admission. Two other different genuine local Qwen3-8B small-domain candidates passed bounded 65,536-case tests apiece.
Full Council qualification report → · Download qualification PDF → · Three sector evaluator packs → · Download evaluation PDF →