This is the reflective half. Why we work this way, what it cost to learn, and where it went wrong.

If you want the hands-on version — write a hypothesis, check it, run the loop — that is The HDD Handbook, and it starts from nothing.

New to the hands-on track? Start with Your First Hypothesis, in One Sitting — thirty minutes, and you finish it with a real prediction on the record.

The essays

Ten pieces, about 76 minutes end to end. They stand alone — read whichever one the title makes you curious about.

The method

Knowledge

Field notes

How we work

Expeditions, Not Sprints

We don't run sprints. We launch expeditions — hypothesis-driven units of work with clear success criteria, tracked on a kanban board. Each expedition has:

  • A hypothesis to validate or refute
  • Success metrics defined before work begins
  • A captain (human or AI agent) responsible for execution
  • Test coverage across three tiers before it can merge

The metaphor is deliberate. An expedition discovers something. A sprint just burns time.

Hypothesis-Driven Development

Every piece of work starts with a testable claim:

H801.1: CQ-guided extraction produces ≥12 unique predicates per document, compared to ≤6 from unguided extraction.

We define the hypothesis, build the minimum implementation to test it, measure results, and record findings — regardless of whether the hypothesis is confirmed or refuted. Failed hypotheses are as valuable as confirmed ones.

Three-Tier Testing

We are a heavy TDD/BDD shop. No feature merges without test coverage at all three tiers:

Tier Type What It Tests
T1 Unit Tests Individual functions and classes in isolation
T2 Integration Tests Component interactions, fixture integrity
T3 Live tests The running system, driven through its own CLI, demonstrating the capability

The critical insight is Tier 3. We do not just test that the code works — we test that the running system can actually do the thing, driven through its own command line the way a browser test drives a UI:

# T3 pattern: CLI-first, no internal API imports
result = run_being_cmd("study", being_id, document_path)
assert result.returncode == 0

result = run_being_cmd("report", being_id, "--format", "json")
report = json.loads(result.stdout)
assert report["y1_count"] >= expected_minimum

No feature is complete until the running system demonstrates the capability.

Multi-Agent Development

The NuSy project is built by a fleet of agents — AI developers working in parallel, coordinated through a shared kanban board and Git:

Agent Platform Role
DGX1 / DGX2 NVIDIA DGX Spark (GB10) ×2 GPU training, inference, eval experiments
M5 MacBook Pro M5 Development, code review, architecture
Mini Mac Mini M4 Development, testing, infrastructure
Air MacBook Air M5 Development, code review, documentation

Agents pick up expeditions, execute them, submit PRs, and review each other's work. The human captain directs priorities and makes architectural decisions. The agents do the engineering.

Knowledge as Code

Definitional knowledge — domain vocabularies, thresholds, safety rules, hypothesis definitions — lives in Yurtle format: a Markdown file with a few lines of structure at the top, in a syntax called Turtle.

The file stays a file: you can read it, review it in a diff, and open it on a machine with none of our tooling. The structured lines are also a knowledge graph — a set of three-part statements (this thing · has this property · with this value) that a machine can query without parsing prose.

This means:

  • The system can read its own configuration — it is data in the graph, not values buried in code
  • Knowledge is auditable — versioned in Git (graph-native), human-readable, diff-able
  • Changes are safe — modify thresholds without redeploying code
  • Everything is queryable — over all definitional knowledge

The principle: if it's knowledge, it's data in the graph. If it's procedure, it's code (Rust/Arrow).

Open Development

Our codebase, research, and expedition history are open. Every blog post on this site links to its source Yurtle file on GitHub. The research notes distill what we've learned from building NuSy — the successes and the failures.

We believe in radical transparency: if your AI can't show its work, you shouldn't trust its answers. The same applies to the people building the AI.