Moaticle
Ink wash of a river circling a rocky ridge, with a low crossing between the banks

Assemble evidence.Test moat candidates.

The Moaticle moat builder traces observations and failures to their sources to design the next experiment. Build a qualification rule or results index, then compare it with the strongest alternative given the same evidence and permissions.

  1. Record evidence as particles

    Record observations, failures, actions, outcomes and counterexamples one at a time. Each particle carries a source location, a hash and the conditions in which it applies.

  2. Build an asset you can use

    Put the relevant particles in execution order. Use the resulting plan to build an asset, such as qualification rules or a searchable index of results.

  3. Test copies and source outages

    Give the strongest alternative and a full replica the same job. Measure whether the replica matches the result and where the asset loses coverage when a source or its updates stop.

One starting point, three outcomes

A fictional cultural center needs a way to test its multilingual visitor notices. The engine links the proposal to a previous failure, the original records and the conditions for a fair comparison.

Open the cultural center example

A test plan for multilingual notices

Evidence
A French notice, a correction record and a comparison protocol from Corvel.
Asset to build
A test kit for multilingual notices with a fixed comparison and rejection criterion.
When a source is missing
Remove the Corvel source. The engine stops and identifies the missing original.

Pick a case and conditions in the workbench to see which evidence the engine assembled and which counterexamples it kept. Run the local engine to build an experiment plan and ledger from your own sources.

How the builder works

Start with who needs to do what. One person can delegate implementation and comparison runs to agents and still trace a decision back to its sources, failure criteria and strongest counterexample.

  1. Freeze the job and failure criteria

    Define the target, task, success metric and minimum effect. Record the result that would make you drop the claim.

    Engine
    The ledger ties the hypothesis revision to candidate and alternative hashes, case inputs and experimental criteria.
    Operator
    Choose the comparator, data and permissions, time and budget. Check the comparison conditions before running the trial.
  2. Record evidence you can trace

    Each particle records one observation or failure under stated conditions. Use the same format for actions, outcomes and counterexamples.

    Engine
    Checks the source SHA-256, location within the JSON and observation date. Identical source bytes can belong to one source family.
    Operator
    Prepare authorized source material and explain what each observation represents. Confirm consent to use personal material.
  3. Assemble the sequence and counterexamples

    A single plan shows which evidence you need first and under what conditions an earlier failure may recur.

    Engine
    Checks conditions and prerequisites, orders the steps and includes counterexamples that apply. Keeps source references for counterexamples outside the current conditions and lists the particles affected by each source outage.
    Operator
    Specify the particles, controls and next measurements for the job. Test whether substitute sources actually work.
  4. Build the asset for the next job

    Execute the plan to build an artifact, such as qualification rules, a searchable results index or a kit that lets another person repeat a task.

    Engine
    For a results index, freezes predictions for the new cases first. Records the evaluated and updated assets separately, then links new observations to their sources.
    Operator
    An agent or operator implements and runs assets that need domain tooling, such as Corvel’s qualification rules.
  5. Compare a replica on fresh cases

    Use known cases for regression checks. Seal new cases separately and run the strongest alternative and a replica with equal access to data, code, history and permissions.

    Engine
    Records comparisons, asset removal, replication cost and measurements after time has elapsed. Checks verifier signatures against original measurements and case inputs.
    Operator
    Arrange independent execution. Inspect task-specific measures such as cost, time, missed violations, false rejections and unavailable results.
  6. Decide and hand off to the next round

    Record ties and new failures as inputs to the next round. Design the next trial around what erased the gap or which source the asset depended on.

    Engine
    Keeps older rulings and counterexamples. New counterexamples and expired evidence trigger review. Recover the results index by checking the backup hash and its cited sources.
    Operator
    Review the evidence and approve or hold the claim. Keep the ledger head hash separately so the history can be checked again.

Measurements and worked examples

Inspect measurements for purpose-built qualification rules and a compatibility index. The synthetic workbench examples show how to use the same workflow to plan a new task.

Corvel Forge L8 · Turn new failures into qualification rules

Local simulator measurements · Test RTL

The team used the public functional contract to turn failure reports into qualification rules for subsequent deliveries. Follow-up trials gave the replica the same reports, implementation and history, plus equivalent test signing permissions.

In the new-case test, the fourth batch was rerun with a higher cycle limit. Corvel and the replica with the complete implementation each missed four of the eight new violations.

In a regression on those known violations, the new rules caught all eight. The comparison running the prior rules missed four. The 19-rule qualification capsule added 15 rules and passed five separate qualification cases.

The trials ran on one Mac with Icarus and test keys. A comparison of the added rules on newly sealed cases remains open.

Open the evidence

CPython · An index of compatibility observations

Five actual installations · Measured on one machine

The team gathered 100 SQLite and standard-library observations to predict what would work in the next Python environment. The resulting index exposes the 40 latest entries by signal and distribution path, with locations in the original sources.

The built index scored 20 of 20 in the last round. A full copy matched it in each round. The alternative used a separate process to run the probes directly on the same public runtimes, without the index. It reproduced all 80 observations over four rounds.

Removing the most consequential source reduced the last score to nine of 20. The ledger recorded all four rounds as refutations of the moat claim.

All five installations ran on one Mac in version order. The cost of obtaining the target environments and performance over a real update interval require separate measurements.

Open the evidence

Personal and nation brand · Apply the method to different jobs

Synthetic inputs · Experiment plan replay

One example prepares a kit so the next collaborator can repeat a task. The nation brand example addresses multilingual operating notices at a fictional cultural venue. Both supply sources, conditions and steps for observations and failures.

The assembler returns a plan and the counterexamples that apply to each job. The venue example borrows Corvel’s comparison method with equal data and permissions. Inspect which particles and actions need rechecking when the Corvel source is unavailable.

The examples reach the ready-for-trial stage. Visitor and collaboration outcomes require measurements from an actual run of each task.

Open the evidence

Run it locally

Moaticle 0.3.0 runs on Python 3.11 or later. The local web app, CLI and Aja MCP server can connect to the same SQLite ledger. Installation artifacts include MIT-licensed source, an installable wheel and an Agent Skill.

Install