Source notes
Arbor v2
How this project works, the decisions behind it and its known limits. Ask quotes and cites these passages when it answers.
Notes reviewed 20 September 2026
Explore the projectProduct
Product
A private research system built to make its evidence and decisions traceable. Arbor v2 is a separate-generation rebuild focused on research integrity, reproducible datasets and tightly governed execution boundaries. Its value in this portfolio is the engineering: source lineage, validation, durable work and auditable decisions.
The problem it solves
A research result can become misleading when its dataset changes underneath it, repeated observations are mistaken for independent outcomes, or a test uses information that was not available at decision time. A running process is also not proof that a system performed the intended action safely.
The experience
The system builds and validates canonical datasets, runs bounded research jobs, records what inputs and assumptions produced a result, and keeps execution authority separate from research output. Public portfolio material intentionally describes these controls rather than private strategies or operational performance.
Availability
Arbor v2 is private research. It is not a released product, and there is nothing to install or use.
Engineering
Backend and architecture
Python modules and typed contracts separate canonical data, research, validation, portfolio decisions, execution and accounting. The data plane uses versioned RAW, SILVER and GOLD layers with DuckDB and Parquet. Research reads a selected, eligible canonical dataset through a shared reader rather than naming a growing raw file. A durable SQLite/WAL job framework records work and lineage. Execution has a single capability-bearing boundary with required guards and a journal.
Technology by responsibility
Core: Python, Typed contracts. Data: DuckDB, Parquet, Versioned canonical datasets. Operations: SQLite/WAL jobs, Execution journal, Structural boundary tests.
Data, trust and failure behavior
The canonical reader distinguishes certified GOLD data from lower-level quote history. Missing coverage is a named failure rather than a silently empty study. Execution couples a decision to an intent and preserves a trace in its journal. Live authority depends on both configuration and an owner-set expiring control. This page describes architecture only; it does not draw on private account data or trading activity.
Canonical, reproducible inputs
The reader asks for a dataset capability and minimum independent-event coverage. A completed build is not automatically a quality-certified build.
Independent outcomes, not inflated rows
The coverage model distinguishes repeated market observations from independent outcomes. Sample volume alone is not evidence of predictive reliability.
One execution authority
The executor requires a matching decision and intent, attribution, duplicate protection, exposure checks and an explicit live decision. Refusals are also terminal facts to record.
Default to no live action
Two independent authorization conditions are required for live execution. Missing, invalid or expired owner authorization leaves the system in dry-run mode.
Decisions
Preserving research provenance
Canonical readers use eligible, versioned datasets and distinguish independent outcomes from repeated observations. Quality certification is a separate assertion from successful file creation. Trade-off: A strict evidence boundary can block a study rather than return a convenient partial result. That friction is useful when the alternative is silently changing the meaning of the experiment.
Making authority impossible to forget
Execution guards are required constructor dependencies rather than optional conventions. A single order capability and structural checks constrain which modules can reach that boundary. Trade-off: Safety also depends on deployment, input integrity and tests. A well-designed gate does not by itself show that every runtime or historical caller goes through it.
Limits
Known limits
Arbor v2 makes no claim of profit, autonomous uptime or successful current live trading. It is not the older Arbor implementation: neither a v1 metric nor the age of a Git commit counts as v2 evidence. This page stays at the level of architecture.
Questions Ask answers from here
Is Arbor v2 a released trading product?
No such claim is made here. It is presented as private research and active development, with public-safe architecture only.
What is the important engineering lesson?
A reproducible input, an accepted quality check and an authorized action are different facts. The system gives each its own boundary and evidence.
Why not show uptime or financial performance?
Those outcomes have not been established. The age of a repository or a running process cannot establish them, and private operational details do not belong in the public knowledge base.