Case studies

03 · Broker-neutral investment intelligence

MarketPulse

Designing an evidence-governed research system before committing to product implementation.

Product question

How can AI-supported investment research remain attributable, reproducible and under the user’s authority?

Company context
Founder, Point Zero AI
My role
Requirements, architecture governance, validation and phased implementation direction
Current status
Phase 0 complete · Gate 3B pending
Development approach
AI-supported implementation under founder-directed requirements, testing and validation.
MarketPulse controlled implementation roadmap
Phase 0 is complete. Gate 3B remains a founder decision; later product implementation is not yet authorised.

01 · Problem

The problem at the centre

Investment research is fragmented across sources, tools and time. AI can accelerate synthesis, but without provenance, contradiction handling, history and clear responsibility boundaries it can produce confidence without accountability.

How can AI-supported investment research remain attributable, reproducible and under the user’s authority?
Target user

Everyday investors who want more disciplined research and decision review while retaining every final investment decision.

Product direction

MarketPulse is being defined as a broker-neutral AI Investment Intelligence Agent. Its controlled Founder MVP is an evidence-led research workspace built around attributable sources, living theses, risk visibility, validation, audit history and reproducible reports.

Primary constraint

No trade execution, order submission, brokerage credentials or money movement.

02 · Product Direction

A product boundary before a feature list

MarketPulse is being defined as a broker-neutral AI Investment Intelligence Agent. Its controlled Founder MVP is an evidence-led research workspace built around attributable sources, living theses, risk visibility, validation, audit history and reproducible reports.

Documented

Product direction

Broker-neutral research and decision support with a permanent user-authority boundary.

Approved

Founder MVP architecture

Browser experience, FastAPI modular monolith, PostgreSQL system of record and governed content storage.

Approved

Provider boundaries

Provider-neutral adapters, durable jobs, least-privilege controls and explicit cost hooks.

Approved

AI assurance

Structured outputs, independent validation, evidence links and visible uncertainty.

Tested

Phase 0 foundation

Compatibility probes, configuration, architecture rules, deterministic fakes, test runners and local CI.

Deferred

Product workflows

Research, thesis, report and interface implementation remains outside current authority.

03 · Process and Contribution

How I directed the work

  1. 01

    Defined the product’s responsibility boundary: brokers execute, MarketPulse informs and the user decides.

  2. 02

    Structured the PRD, engineering specification and authorised build specification as linked controlled volumes.

  3. 03

    Approved architecture decisions covering modularity, persistence, providers, durable work, AI validation and reproducibility.

  4. 04

    Created gated implementation and test registers that distinguish approved plans from authorised work.

  5. 05

    Validated the exact Phase 0 toolchain and synthetic foundation before requesting authority to build product workflows.

Implementation Approach

I used AI to support research, documentation, architecture exploration and Phase 0 implementation while keeping requirements, approvals and build authority explicit. No later product phase was treated as implemented simply because it was designed.

Testing and Validation

Phase 0 is supported by 18 verified build tasks and 11 authorised test records using synthetic, local and provider-disabled evidence. Gate 3B remains a founder decision before named Phase 1 work begins.

Process Growth

MarketPulse shows the clearest change in my process: from feature-led building toward governed requirements, architecture decisions, phased authorisation, test gates, privacy boundaries and disciplined scope control.

04 · Testing and Validation

What supports the current status

Verified from the current local build and test suite.

18 / 18

Phase 0 tasks verified

Compatibility and deterministic foundation only.

11 / 11

authorised test records passed

Synthetic, local and provider-disabled evidence.

130

build specifications

Approved as a plan; later execution remains unauthorised.

110

test specifications

Approved as a plan; later execution remains unauthorised.

Current status

Phase 0 is complete and the full local gate passes. The result is a verified technical foundation and a Conditional GO recommendation for founder review—not a claim that the Founder MVP product is operating.

05 · System

How the system supports the experience

Simplified from current source structure and architecture records. Sensitive implementation detail is intentionally excluded.

MarketPulse staged product direction
The product direction separates the approved Founder MVP from documented candidates and deferred scope.
MarketPulse approved Founder MVP architecture
Approved architecture: browser client, modular monolith, governed data, provider adapters and reproducible outputs.
MarketPulse Phase 0 and future phase roadmap
The roadmap labels completed evidence, pending founder review and unauthorised future phases.

06 · Key Decisions

Boundaries that shaped the product

  • No trade execution, order submission, brokerage credentials or money movement.
  • No live providers, real sensitive founder data or non-loopback access in Phase 0.
  • The wider PRD remains under founder review; approved architecture does not imply an operating platform.
  • Gate 3B still requires a founder decision before any named Phase 1 work can begin.

07 · Lessons Learned

What I will carry forward

01

Architecture approval and implementation are different states. Good product communication makes that distinction visible.

02

For consequential AI, evidence lineage, contradiction handling and reproducibility belong in the product model—not in a disclaimer.

03

Scope discipline can be a form of velocity: validating the riskiest assumptions early avoids building on an unproven stack.

Technology

Tools used in the build

Technologies used in the current implementation.

React 19TypeScript 6Vite 8FastAPIPython 3.14PostgreSQL 18PydanticSQLAlchemyPlaywright
Next case studySystem Guard AI