← Research overview

Case study / 03 / Discretionary day trading

Edge Lab

Edge Lab is my day-trading research and journaling tool for discretionary decisions. It preserves the plan and chart context before the result, records the choice to trade or stay out, and supports a review of the process separately from the outcome.

Ask about early access

Looking for a clearer way to plan and review discretionary decisions? Tell me what your current journal is missing.

Private build. Public access and pricing are not available yet.

Status
Working private day-trading research tool
Platform
Native macOS / Python / local-first
My role
Product direction · Research architecture · AI orchestration · Implementation · Verification

Built around the trader's day

Plan it. Record it. Learn from the decision.

For discretionary day traders who want a complete, reviewable record of their reasoning.

01 / Before the outcome

Preserve the plan and context.

Bind the observation and chart context to the original plan. Keep what was known at the time available for later review.

02 / Every decision counts

Journal the choices to stay out, too.

Record a trade, pass, cancellation, or no-trade decision. A useful review includes more than memorable completed positions.

03 / After the decision

Review process before outcome.

Examine the reasoning and execution before revealing the result. Add corrections and lessons while preserving the original history.

Live observation, replay practice, and historical research keep separate evidence. Independent AI criticism works from a bounded packet; the trader retains authority.

01 / The problem

Context is part of the evidence.

A trading journal can record what happened without preserving why a decision made sense at the time. A chart loses its context, a note gets rewritten, and the result can shape the review. Edge Lab keeps observations, plans, decisions, and later reviews connected so a discretionary trader can return to the reasoning that actually existed.

02 / The design judgment

The hard part was deciding what the system must refuse to blend.

Plans, observations, executions, outcomes, and model opinions can relate to one another without becoming interchangeable.

03 / My role

AI contributes. I own the boundary.

I designed the product, research protocol, evidence model, model boundaries, macOS workflow, and verification gates. I also own the final judgment: AI can challenge a record, but it cannot rewrite one, merge research modes, or certify its own conclusion.

04 / Evidence architecture

Every useful derivative points back to preserved source material.

A capture moves through explicit transformations while the center of the system remains append-only. Each stage adds context or review; none is allowed to impersonate the original observation.

PythonSwiftAppKitSQLiteUnix domain socketsContent addressingRO-Crate 1.3Multi-model reviewBounded retrievalDeterministic testing
Evidence graphAppend onlyHuman authority at the center
  1. 01CapturePreserve the observation
  2. 02BindAttach identity + lane
  3. 03RetrieveAssemble a bounded packet
  4. 04ChallengeRecord independent criticism
  5. 05DecideKeep authority human
  6. 06PreserveExtend the evidence graph

05 / Uncommon engineering

Eight mechanisms that make the system more than a journal or model wrapper.

01

Append-only correction chains

A correction must extend the current record tip. Prior versions and reasons stay intact, so a cleaner narrative can never replace the history that produced it.

02

Content-addressed provenance

Canonical captures, compact visual derivatives, context packets, and review artifacts retain verifiable lineage. Reuse begins with byte and identity checks, not a familiar filename.

03

Bounded multimodal context

Models receive a small, lane-bound, snapshot-bound packet with explicit source pointers. The system retrieves what is relevant instead of dumping an unlimited private history into context.

04

Exact evidence separation

Live, Replay, and Historical evidence are independent lanes with independent gates. One mode cannot silently qualify, repair, or provide missing facts for another.

05

Outcome-blind process review

The judgment, rationale, invalidation, and confidence can be frozen before protected outcomes become visible. Process quality and result quality remain separate questions.

06

Auditable model disagreement

Independent model criticism produces structured finding IDs and evidence requests. Agreement is not treated as truth, and the model that proposes a fix cannot certify that fix in the same pass.

07

Capability-scoped model relay

A private owner-only Unix socket gives the independent reviewer one narrow workflow instead of a general local API. Tokens are channel-specific, responses are bounded, and every preserved critique is tied back to exact source bytes.

08

Release-bound runtime trust

The macOS shell binds the running Python service to the signed source and dependency manifests, exact process identity, a one-launch session, and the installed build. Stale or mixed releases fail closed instead of being adopted.

06 / Cross-model control plane

Independent review without general system access.

Sol owns the research and integration path. A second model receives a bounded adversarial commission through a workflow-specific capability, and every finding is accepted, rejected with evidence, or left visibly open.

07 / Native release integrity

The interface proves which code is actually running.

The signed app verifies source and dependency inventories, launch identity, local session, process ownership, and build identity before trusting its service. Installed behavior is checked separately from source tests.

08 / Failure semantics

Missing, stale, and partial are first-class states.

No absent observation becomes a zero. No incomplete review becomes a pass. No corrected artifact silently replaces its predecessor. The product keeps uncertainty visible because that is part of the evidence.

09 / Assurance model

The controls are designed around specific failure modes.

Software verification is reported separately from research validity. A clean release can prove that controls behaved as specified; it cannot prove a private hypothesis or future result.

LayerPropertyRefuses
RecordAppend-onlyRewriting history
EvidenceContent-addressedSilent artifact drift
ContextBounded + snapshot-boundContext substitution
SeparationIndependent lanesEvidence contamination
ReviewOutcome-blindResult-driven scoring
RuntimeEvent-drivenContinuous idle work
Model relayUnix socket + scoped tokenGeneral local access
ReleaseSigned + build-bound runtimeMixed or stale execution

10 / One-way disclosure

The portfolio proof cannot query the private workspace.

Edge Lab has a separate code-only exporter with a fixed public allowlist. It emits a content-addressed assurance card and Research Object metadata without constructing the private store, reading a journal, or reusing a private identifier.

The public artifact explains architecture and control claims. It deliberately carries no session evidence and makes no claim of research success.

11 / Public boundary

The engineering is visible. The research stays private.

This case study explains the trader workflow and the engineering behind it. Real sessions, chart images, instruments, vendors, dates, hypotheses, strategy logic, account data, private hashes, outcomes, and performance remain outside the site.

Public surfaceWorkflow + engineeringOperator data withheld

Product direction

Built for my research. Exploring what comes next.

I am exploring Edge Lab's potential as a product for other discretionary traders. The focus is a useful planning, journaling, and review workflow. It is a working private build today; a commercial release, pricing, and broader availability have not been announced.

Watch the portfolio film
12 / 4Maximum pointers / visual files per model packet
0 pollingContinuous client work while idle
2 reviewersIndependent, structured model criticism
BoundSigned source, dependencies, process, and installed build