Who this manual is for
Research sponsors, laboratory operators, institutions, communities and reviewers. 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 — Describe a research request
State the question, legitimate purpose, permissible data, measurable acceptance criteria, time budget, reviewers and disallowed effects.
02 — Select an approved laboratory
Check the domain, qualifications, current operator, resource status and independent-host evidence. Do not infer certification from a farm label.
03 — Authorize a research run
Confirm the mandate and data permissions through the responsible authority before releasing information or computing resources.
04 — Read experiment results
Check what was observed, what failed, which versions ran, whether the work was reproduced independently and the limits of any success claim.
05 — Challenge a finding
Submit a counterexample, alternate test or documented disagreement through the research review procedure; preserve both successful and adverse results.
06 — Consider reuse or commerce
Separate qualified scientific usefulness from legal authority to licence or issue instruments. Request a rights record before claiming commercial entitlement.
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.
Frame question
Write practical objective, acceptable sources, failure criteria, timeframe and named sponsor.
Assign laboratory
Check farm identity, active host, data permissions, reviewer separation and computing limits.
Authorize experiment
Record scope, isolation rules, approved toolset and safe termination conditions.
Read results
Distinguish completion from scientifically validated performance and inspect failures.
Request challenge
Require separate tests with frozen candidate and known input provenance.
Consider economic release
Seek rights, usefulness and security review; no asset is automatically market-ready.
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
- Create a research mandate and eligible domain
- Assign data permissions, constraints and budget
- Choose a logical farm and confirm real runtime identity
- Execute bounded tasks and retain failures
- Review evidence against external challenge cases
- Seek truly independent repeat tests before commercial promotion
Problem and recovery guide
| What you notice | What to do |
|---|---|
| Unexpected network/data access | Stop the run and retain controlled incident evidence. |
| Experiment exhausted its budget | Mark incomplete; do not promote partial results. |
| Replicator disagrees | Record discrepancy, environment and exact result rather than hiding it. |
| “Independent node” on same PC | Correct the description to logical worker and leave physical independence unqualified. |
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
- Hardware/host enrollment and control attestations
- Isolation, least-privilege and negative test results
- Exact research-task and artifact identifiers
- Separate evaluator acceptance criteria and observations
- 3 independent host demonstrations if claimed
- Rights and source-data permission records
Corporate system information → Engineering evidence and limitations → Publications → ENTITY (the separately published open component) →
AI Creation Council and FarmNode research — audited update
A new FarmNode research-demand controller consolidates actual requests and routes testable work to NIKI without inventing independent laboratories. The 23 October audit recorded 5,125 type designs, 2,305 registry-only bindings, four locally running logical research environments, 16 existing source-backed processors and six source messages consolidated into four research needs. Three of those needs still require independent evaluators.
Actual independent physical-host qualification remains 0 of the required 3. A registered type, logical lab or accepted research-only algorithm is not proof of a commercially operating farm.
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.
Research controller: 5,125 registered types; 2,305 registration-only bindings; 16 source-backed local methods; six original messages consolidated to four unique research requirements. Three historical source-backed evaluation packs now exist for forestry (8 holdouts), agriculture (8), and emergency-response metadata (9). These 25 recorded cases are not 25 new algorithm inventions. Forestry median-change beat naive forecasting on the recorded sample, while agriculture median-change performed worse; emergency-response checks verified historical metadata/timestamps only, not event truth or live warning decisions.
Full Council qualification report → · Download qualification PDF → · Three sector evaluator packs → · Download evaluation PDF →