NIKI CGSI-SI: the invention engine
What NIKI is
NIKI is BTG's cognitive research and invention system. In ordinary terms, it is being engineered as a research worker that can do more than answer questions or produce a paragraph of computer code when prompted. Its job is to accept an authorized problem, find relevant permitted knowledge, devise candidate solutions, express them as working computations, run bounded experiments, identify mistakes, improve its designs and retain what the evidence justifies.
A conventional chatbot may give a plausible suggestion. NIKI's architecture is concerned with a more demanding question: Can the system create a working method that was not simply handed to it, test that method against an independent standard and preserve the exact result for other work?
How NIKI works within BTG
A human or authorized research organization begins with a research mandate: the problem to study, data it may use, boundaries on its actions, computing budget, technical acceptance test and authorized decision-makers. For a manufacturing problem, the mandate might be to reduce false alarms when several sensors disagree. For forestry, it might be to improve prediction of a particular equipment failure. For agriculture, it might be to detect a pattern in permitted moisture and weather readings.
NIKI consults authorized knowledge from BTDU and other specified inputs. It can generate a candidate algorithm, a working program, or a proposed arrangement of DataChips. The exact generated bytes and version of the source are retained. The proposed program is treated as untrusted: it runs inside a restricted environment with limits on memory, processor time, processes, files and outside connections. An independent test compares outputs with a known answer or other measurable standard. A failed test is recorded, not rewritten into a success. A repair is recorded as a new version with a visible relationship to the failed one.
If a candidate passes the relevant tests, the evidence travels onward. Its source, compiled executable, input and output definitions, dependency versions, resource limits, observed reliability and permitted-use status can become part of a governed DataChip or Circuit. NIKI may help investigate the next problem, but it does not approve its own legal rights, independent test findings or financial transactions.
Why it matters
The economic importance lies in the possibility of producing more useful, verifiable intellectual work for a given amount of time and resources. Research organizations normally employ specialized people to explore methods, write code, test, correct and document results. NIKI is designed to make portions of that process repeatable and available to many participating laboratories, while retaining responsibility and independent technical review for consequential results.
NIKI does not need to become an all-knowing intelligence to be valuable. If it consistently produces qualified improvements to specific industrial, scientific or software problems, each useful result can become a separate asset with a known history. Large numbers of those results could make the wider economy more productive. Whether that advantage exists at commercial scale is established through independent comparisons of useful results, costs, failures, human involvement and customer outcomes, not by calling every piece of generated code an invention.
Example anyone can follow
Suppose four sensors on a piece of machinery report possible faults. One sensor may be missing, another may be invalid, and the others may agree. A proposed algorithm must interpret every combination correctly. NIKI first produced a version that incorrectly treated certain missing readings as agreement. The error was exposed by a fixed test. The repaired source, which retained the original chain of evidence, later produced the correct outputs across all 65,536 possible inputs in recorded Windows and Linux WebAssembly execution. This is an example of a real local research and repair chain, not a claim of general-purpose scientific superiority or a completed commercial product.
Verifiable Reality: telling proof from belief
A major problem in AI and digital markets is that different kinds of claims can look equally convincing on a screen. A program says an algorithm works. A test log shows it worked in one environment. Another laboratory independently reproduces the result. A rights holder signs a valid licence. A bank confirms a payment. A regulator issues a written market authorization. These statements have very different meanings.
Verifiable Reality is the evidence-classification approach that keeps those meanings separate. It is designed to give a reader or another system the evidence behind an assertion and the proper degree of confidence in that assertion. A cryptographic hash can verify the integrity of source code; it does not prove the algorithm is useful in an actual factory. An internal pass report can document a laboratory's work; it does not certify an independent institution performed the same test. A signed contract can confer a defined permission; it does not make a disputed claim to unrelated property valid.
For public and institutional adoption, this matters enormously. A manufacturer wants to know which test supports a promised efficiency gain. A public body wants to know whether private data is legally available. An investor wants to distinguish independent valuation from a seller's estimate. A contributor wants to know whether money was actually received before a royalty is shown as payable. Verifiable Reality helps those questions remain answerable without treating AI-generated explanations as evidence by themselves.
The October 2026 research evidence
BTG's technical record includes actual local research, code execution, knowledge reconstruction, Circuit execution and encrypted research-reference delivery. Those records are more substantive than a proposal consisting only of diagrams and written specifications. They also concern specific, bounded experiments, not yet a verified global commercial economy.
One research challenge required an algorithm to decide whether at least three of four encoded sensors reported the same valid reading. There were 65,536 possible input combinations. NIKI's first recorded generated C expression gave incorrect answers for 57 combinations, including cases in which a missing sensor was mistakenly counted as an agreeing measurement. The failure was preserved and the repair process produced a corrected source version with its own recorded provenance.
The corrected source was compiled to a 240-byte WebAssembly module. The recorded Windows Wasmtime execution returned correct results for all 65,536 inputs. A later Debian WSL2 execution using Bubblewrap and cgroup controls also returned 65,536 correct results. The recorded compiled binary hashes matched. The Linux environment ran on the same BTG workstation, so this is a real second operating-environment test, not a claim of reproduction by an independently controlled external institution.
The associated BTDU and ADAM records preserved the original research material and allowed local cold reconstruction. The Recursive Fabric runtime initially executed an evidence-processing Circuit Genome connected with the research chain. Later engineering advanced the demonstration: a recorded local receipt shows the actual repaired NIKI sensor algorithm operating as a typed executable node in a two-node Circuit, followed by an evidence-digest operation. The complete result matched the frozen oracle across all 65,536 inputs. Subsequent internal engineering records describe an immutable DataChip descriptor retained and reconstructed through BTDU, along with targeted and negative-test results. These findings form part of the documented internal engineering record and are distinct from external independent certification.
The record also includes three encrypted research-reference deliveries to three local Windows worker processes with durable acknowledgments and duplicate handling. Those workers were not three separately controlled physical research institutions, and the deliveries did not create legal commercial rights. An earlier downstream suite recorded 312 local regression tests passing after a process-launch correction; a later engineering report records 356 Windows backend regression tests passing as the integration progressed. These are software tests within their stated scopes, not counts of inventions or market transactions.
The relevant historical artifacts are held in the BTG qualification workspaces, including source and binary hashes, execution receipts and research delivery files. These provide a basis for future external reproduction. These development records do not establish independent institutional certification, owner-authorized production DataChip issuance, three separately enrolled physical hosts, a completed customer sale or authorized securities trading. Each is a distinct matter requiring its appropriate evidence and authority.
Why this real engineering example matters to a public reader
It demonstrates the kind of continuity the architecture is meant to preserve. A candidate can be generated, found wrong, repaired, executed as working software, reconstructed from retained knowledge, connected into a larger working Circuit and transferred as a research reference - while each stage has its own record. The more important later economic and institutional claims become credible only when independent organizations and paying customers complete their corresponding stages.
