AI Needs the
Right Experience.

Teach it what your team needs to check.

An exchange funds a wallet used to pay customers’ withdrawals. An AI helping review that payment needs the history around it.

Earlier payments show whether the size, timing, and recipient fit the wallet’s routine. Balances show how much the transfer changes what remains.

Wallet roles add another part of the explanation. Exchanges can use different addresses for deposits, withdrawals, reserves, and activity in different jurisdictions.

Moving funds between those wallets may support customer withdrawals or a security procedure. Your team’s records and policy establish the purpose and required review.

The chain records what moved. Your team supplies the policy and the judgment about what should have happened.

TrackBTC builds balances and connected histories from Bitcoin’s records. We group addresses linked by spending evidence to examine their activity together.

We call these wallet groups. Organization names and wallet roles require separate supporting evidence.

That is what we mean by an experience: a specific situation, a defined task, and the evidence needed to teach or assess it.

Explaining recorded behavior, deciding what needs review, and forecasting later activity require different answers to check.

Different histories should lead to different assessments.

Consider two anonymous examples from published monthly reports. One reserve became active. Another wallet retained its Bitcoin.

An AI exercise can ask the model to describe each change and cite the supporting records. The answers can then be checked against measured history.

A reserve starts moving.

An exchange-associated reserve sent no BTC in October 2025. During November, it sent roughly 32,909 BTC.

The exercise tests whether a model connects payments with the change in reserves. The receiving wallet’s role helps distinguish withdrawal funding, storage changes, and other activity.

A shift toward exchange activity can indicate potential distribution. A transfer alone does not establish a sale.

A treasury keeps what it received.

A treasury-linked wallet received about 26,916 BTC in January 2026. By the end of September, it had sent no Bitcoin across its recorded history.

A treasury team could use this task to test whether a model distinguishes funds remaining in storage from funds moving through a wallet.

Both examples ask the model to explain a completed period. Their questions, permitted records, and expected findings are visible.

A forecast made in January would be a different task. September’s records would belong in the later check, outside the model’s January information.

These are separate wallet histories from published reports, verified on 2026-10-19. Small amounts received later round away in the treasury chart. Read the source evidence.

Do not give a January assessment September’s knowledge.

An organization identified in September may own an address that was active in January. The old transaction does not make that later identification January knowledge.

Two dates matter: when an event happened and when the relevant information became available.

Point-in-time state describes the recorded situation at a chosen moment. A learning example must also establish which facts the model could have known then.

The input cutoff is the latest information allowed into the model’s assessment. For a January review, later discoveries stay outside that input.

Using later knowledge in an earlier assessment is called data leakage. It can make a test look more successful than a real decision with limited information.

scikit-learn’s guidance explains how unavailable information can inflate evaluation results.

Our completed-month Operations reports keep month-end address membership fixed across earlier comparison periods. That measures how the same selected addresses behaved over time.

It does not reconstruct which addresses or organization names a reviewer knew earlier. A past-decision task needs a separate check of that knowledge.

Find the situations your team wants the AI to handle.

A large archive includes ordinary activity, significant changes, and difficult cases. The useful selection depends on the question your team wants to answer.

For payment review, include familiar recipients and expected transfers alongside changes in size, timing, and destination.

For reserve monitoring, include funds staying in place alongside funds leaving storage. A model needs examples of both to explain the difference.

Similar starting situations with different outcomes are also useful. They help reviewers ask which differences the model needs to recognize.

A sender’s share of incoming Bitcoin, for example, may grow across periods. The source payments identify the change; operator records establish what those payments represent.

The AI layer is being designed to find and assemble these situations from the history. Its purpose is to focus review and learning on relevant cases.

Keep ordinary cases in the evaluation. A model that calls every payment unusual can create work without helping a team identify meaningful changes.

Use recorded cases to teach and test an assessment.

The same recorded history can support several kinds of learning. Each format adds something different to the underlying transactions.

These are the outputs we are designing the AI layer to assemble. They require reviewed answers, recorded demonstrations, or a defined test environment.

For teaching, an expert label means a reviewed answer or category attached to an example. The reviewer’s criteria must be explicit.

A worked sequence, or agent trajectory, records what a system saw, which tools it used, its actions, and the results.

Bitcoin transfers do not contain those tool-use steps. They need recorded demonstrations or a test environment that produces them.

Preference data adds judgments about which answer is better. Rewards define what the learning system should favor under the agreed task.

Keep measured outcomes separate from expert judgments about appropriate action.

Levine and colleagues’ offline reinforcement learning tutorial examines learning from previously collected behavior and the challenges it creates.

Replaying recorded events follows the history. Testing an action that was never taken requires a defined environment and validated assumptions about its effects.

The reversible runtime in our state-engine article remains an architecture direction. It would extend how applications revisit earlier states and explore alternatives.

Show your team which answers it can rely on.

Can the model find the relevant payments? Does its assessment follow your policy? How much additional review does it create?

Agree those questions with your team, then compare model versions against the same historical cases.

A treasury team can check whether an assessment explains changing reserves. A security team can check whether it identifies the records needed for review.

An exchange team can check whether it distinguishes movements within its own wallet infrastructure from payments involving other services.

A known failure can become a regression case: a repeatable check that a later model still handles that situation correctly.

Those checks show whether a specific problem returns. Separate, untouched test cases assess how well the model handles situations excluded from its development.

Keep related versions of the same historical episode together when separating training from testing. Otherwise, a familiar event can appear to be an unfamiliar challenge.

Training and evaluation need deliberate separation. scikit-learn’s guidance explains how test information can otherwise influence model development.

The result should be a record your team can explain: which cases it checked, what the answers established, and where further review remains necessary.

The same approach can serve other recorded workflows.

A payment task connects earlier balances and rules with authorization and settlement. A workflow task connects tools and permissions with an action and its result.

Industrial operations connect commands with the equipment’s changing condition. Each domain needs its own recorded state, task, and outcome definitions.

These are architectural applications of the approach. Bitcoin is our production data foundation.

The history is built. The AI layer adds the learning task.

The State Transition Engine constructs dated balances and connected activity. TrackBTC uses that foundation to produce Operational Reports.

We are building the AI-specific layer separately. It adds situation selection, permitted information, reviewed answers, and evaluation criteria.

Building one usable case requires more than collecting transactions. The records must fit the question, observation period, and wallet group being examined.

For a past-decision exercise, the builder must also check when the relevant information became available. Expert answers need review criteria and a record of their source.

The database supplies assembled history for that work. Researchers can begin with dated balances and connected payments, rather than resolving them again for every experiment.

In the 10 September 2026 rebuild, a timed construction phase reached a peak near 16 million internal state-building operations per second.

The count covers records processed during construction. It does not measure agent throughput or model training speed. Read the historical benchmark’s units and scope.

Bring a question your team wants the AI to answer.

Choose withdrawal funding, treasury movements, or internal wallet routing. We agree the relevant records, review criteria, and useful results together.

TrackBTC provides reports and public findings. CWOS is our first-party decision platform, with direct access to the complete internal intelligence foundation.

Its AI workflows are in development. An evaluation needs an agreed scope, including any integration or development required.

The final results report documents what your team checked, what the evidence established, and which questions remain open.

That gives the people leading the evaluation a concrete account of their contribution and a basis for deciding what should happen next.