Aikido

A research and execution system built around one recurring constraint: decisions that can move money must be reproducible, inspectable, and recoverable.

4subsystem dossiers
Rustaccount + evaluator authority
PIThistorical decision inputs
livedesired-state convergence

End to end / one pass

From question to verdict

Aikido is not one strategy. It is the machinery that controls how a research idea becomes evidence, then—only if it survives—executable intent.

  1. 01
    Search

    Ask a bounded question over causal market facts. Fast screening finds candidates; exact replay decides which ones survive.

    candidate + evidence
  2. 02
    Freeze

    Compile the decision-time inputs, cutoff, identity, and lineage into an immutable policy-state pack.

    published input
  3. 03
    Decide

    Policy reads the frozen pack and current state, then asks for target exposure. It does not claim a fill.

    requested intent
  4. 04
    Realize

    Runtime reconciles intent with the broker and moves observed state toward desired state using one account model.

    execution report
  5. 05
    Judge

    Exact account-path evaluation, evidence gates, and confidence rules decide what the result is allowed to mean.

    verdict or retraction
system map / 01

Follow the truth boundaries

Choose a stage. The record below shows its job, authority, surviving evidence, and the failure it is designed to contain.

01 / market facts

Causal inputs, before any claim

Job
Prepare bars, features, sessions, and predicate truth without importing information from the future.
Authority
The versioned market publication and its recorded cutoff—not a mutable dashboard view.
Evidence left behind
Dataset identity, publication ID, time range, feature requirements, and provenance.
Failure boundary
Changed source data, hidden lookahead, or a result that cannot say which facts it used.
related dossier: When a Result Is Allowed to Count →
02 / research

Spend exact compute where it can matter

Job
Enumerate, prune, screen, rank, and exact-verify candidate ideas while retaining the evidence needed to reproduce them.
Authority
Canonical exact evaluation is authoritative; the fast screen only decides where expensive evaluation goes.
Evidence left behind
Search configuration, candidate counts, exact evaluations, trades, daily results, and cache lineage where available.
Failure boundary
Brute-force combinatorics, approximate outcomes promoted as truth, or a leaderboard with no reconstructable run.
related dossier: The Predicate Sweep →
03 / frozen input

Publish what was knowable then

Job
Compile decision-time facts, cutoff, identity, hashes, and allowed context into an immutable policy-state pack.
Authority
The published pack is the policy input. Live warehouse reads are outside the decision contract.
Evidence left behind
Manifest, content hashes, lineage sidecar, cutoff, pack identity, and publication pointer.
Failure boundary
A historical decision silently reading revised or future information from a mutable store.
related dossier: When a Result Is Allowed to Count →
04 / policy

Express intent without inventing a fill

Job
Map the frozen pack and current policy state to requested target exposure.
Authority
Policy owns desired exposure. It does not own broker state, fills, account equity, or realized outcome.
Evidence left behind
Decision inputs, selected policy identity, requested exposure, and the trace connecting the request to its pack.
Failure boundary
Strategy logic quietly absorbing execution mechanics and producing results that cannot be replayed under the same contract.
see the policy contract in the architecture summary →
05 / runtime

Converge observed state to desired state

Job
Bind contracts, reconcile broker truth, submit only the required delta, and update one account-state model from events.
Authority
Observed broker state, fills, and the shared account kernel own realized position and account truth.
Evidence left behind
Requested targets, broker observations, commands, acknowledgements, fills, ledger transitions, and execution reports.
Failure boundary
Retrying a delta command into a doubled position, or two protection owners fighting over one live position.
06 / evaluation

Decide what a result is allowed to mean

Job
Replay realized account paths, apply evidence gates and confidence rules, and issue a verdict that can later be retracted.
Authority
Exact runtime/evaluator output owns deployability claims—not a research screen, constituent score, or short-window summary.
Evidence left behind
Resolved configuration, trades, daily path, equity, metrics, provenance, matched trials, and promotion status.
Failure boundary
A scalar score outrunning its evidence or remaining promoted after its authority boundary changes.
related dossier: When a Result Is Allowed to Count →

The map is an index, not a claim that every migration seam is finished. The architecture summary records the current and target surfaces separately.

Subsystem records

Four dossiers

supporting records / 02

Smaller failures worth keeping

24 GB

The shared-cache lifetime mistake

The source object was shared; 48 derived strategy subsets were not. Processing and releasing one subset at a time changed the memory bound.

1% CPU

Workers waiting on workers

Nested Rayon in one Phase-4 path left 27 workers nearly idle. Flattening that work graph changed a three-hour stall into minutes.

−150

The protective-order runaway

A practice incident exposed mixed protection ownership and made “one position, one authority” a runtime rule.

Implementation frame

What this page claims

These records describe implemented subsystems, recorded corrections, and known limits in the audited repository revision. They do not publish strategy parameters, private results, account configuration, or operational credentials.