T3 Research Intelligence

A portfolio intelligence system combining Wyckoff principles, quantitative analysis, T3 market signals, cited web research, and private holdings for disciplined decisions in Vietnam’s stock market.

Comment

Why I built it

I am neither a professional investor nor a software engineer. I entered the Vietnamese stock market less than a year ago with little knowledge, experience, or a repeatable decision-making process.

I quickly discovered how easy it is for retail investors to react emotionally: buying because a stock is rising, selling because it is falling, and examining individual tickers without managing the portfolio as a whole.

I experienced that problem myself. I also saw how AI could help someone in my position build a more disciplined process. That led me to create jamesdo.vn - initially as a personal system, and eventually, if it proves useful, as something other retail investors can use.

The question I wanted it to answer was not simply:

"What happened in the market?"

It was:

"What changed, why does it matter to the positions I hold, and can I trace the evidence behind the analysis?"

What it looks like in practice

Before building this workflow, making a decision about one holding meant opening my broker app, financial-data sites, news tabs, and foreign-flow data, then trying to connect everything manually.

For a portfolio of several stocks, that could take about an hour and still produce a decision driven partly by feeling.

T3 Research Intelligence brings that information into one workflow. For each holding, the Build Week extension can show:

  • the current research status;
  • public events and source records;
  • the exact T3 data batch connected to the research;
  • whether the research was newly retrieved or reused;
  • and a private interpretation based on my own holdings and plan.

Public market research and private portfolio data remain separate. A research snapshot can be reused across a portfolio and a Top 10 watchlist, while cost basis, quantity, profit and loss, notes, and personal plans remain isolated per user.

What it does

T3 Research Intelligence connects three layers:

  1. T3 market context - market, sector, and security signals produced by the existing T3 pipeline.
  2. Shared research - structured public-market research tied to a specific T3 data batch and reusable across workflows.
  3. Private portfolio analysis - user-scoped holdings, cost basis, profit and loss, plans, and interpretation.

The central design rule is:

Shared research must never contain private portfolio data.

This boundary is enforced on both writes and reads. Unknown fields are rejected by default, and a deep scan blocks private-field names at any nesting level.

Mutation tests insert private sentinel values through the full pipeline and verify that they appear neither in the shared database nor in logs.

Research results are identified not only by ticker, but also by market, T3 batch identity, coverage policy, provider, and version information. This prevents research created under one data batch or policy from being silently reused under another.

The resolver follows a fixed sequence:

memory cache -> durable snapshot -> join an identical in-flight request -> call provider -> validate and normalize -> persist -> publish

Research availability fails open: if web research is unavailable, the underlying T3 portfolio analysis can still run.

Security and integrity controls fail closed: unsafe URLs, prompt injection, private-data leakage, malformed output, and failed persistence are rejected rather than published.

External research is always treated as untrusted. Provider-supplied citations remain UNVERIFIED until the underlying URLs and evidence are independently bound and checked.

How I built it with Codex and GPT-5.6

As a non-technical builder, I organized the work like a construction project.

  • GPT-5.6 helped turn my product ideas and operating rules into detailed technical specifications, phase plans, and acceptance criteria.
  • Codex acted as my supervising engineer and implementation partner. It challenged the architecture, inspected each phase, converted assumptions into failure cases, wrote adversarial tests, found defects, implemented corrections, and built verification tooling.
  • Claude Code assisted with bounded implementation tasks under those specifications.
  • I remained responsible for the product vision, privacy boundary, acceptance criteria, and final pass-or-fail decision for every phase.

The workflow was:

specify -> challenge the architecture -> implement one bounded phase -> test -> audit -> rework

A new phase started only after the previous phase passed its review.

Some phases required many iterations. The core resolver reached acceptance only after fourteen review rounds, with every round documented in the repository.

The most important lesson was:

"No exception" does not prove that data was written correctly or remained intact.

One review found that a database operation could return no error even though the expected data had not actually been preserved.

That lesson led to tests of exact persisted state, schema drift, restart recovery, identity separation, database failure, malformed provider output, unsafe URLs, prompt injection, and private-data leakage.

Codex's most important contribution was not simply producing code faster. It converted design assumptions into executable failure cases and required evidence before a phase could pass.

What is verified

A clean local run of the submission branch on July 21 completed:

  • 696 automated tests
  • 695 passed
  • 0 failed
  • 1 intentionally skipped real-provider end-to-end test
  • ESLint passed
  • TypeScript checking passed
  • Production Next.js build passed

The automated suite verifies, among other things:

  • 10, 50, or 100 simultaneous requests for the same research identity collapse into exactly one mock-provider call;
  • repeated portfolio analyses reuse the same durable research snapshot;
  • reuse after a simulated process restart causes zero additional provider calls;
  • shared snapshots cannot contain private portfolio fields;
  • malformed or unsafe provider output is rejected;
  • persistence failures cannot be reported as successful research.

These are local and mock-provider results, not production-performance claims.

Current limitation

The Build Week layer is fully exercised locally with a deterministic mock provider, but the controlled real-provider path is not yet production-verified.

One paid provider run reached the integration boundary, but its output was rejected by the normalizer. The fail-closed design persisted and published nothing rather than accepting data it could not validate.

I therefore do not claim production hit rates, latency, or successful real-provider persistence. The public-production feature remains disabled until controlled validation succeeds.

What was built during Build Week

T3 and jamesdo.vn existed before OpenAI Build Week.

The market-data pipeline, authentication, portfolio management, and earlier analysis functions are pre-existing work and are not being submitted as new competition work.

The Build Week contribution is the new Shared Web Research and Portfolio Intelligence layer, developed during the Submission Period.

The repository distinguishes the frozen pre-event baseline from the new work through:

  • dated phase manifests;
  • baseline snapshots;
  • commit history;
  • Codex session evidence;
  • and docs/web-research-v3/BUILD_WEEK_DELTA.md.

This documentation allows judges to identify exactly what existed before the competition and what was added during Build Week.

What I learned

As a non-technical builder, I learned that AI-assisted software development is not only about asking an AI to generate code.

The more reliable workflow is to define boundaries, challenge assumptions, implement one controlled phase, test failure cases, inspect persisted evidence, and refuse to advance when the evidence does not support the claim.

I also learned that different concerns require different failure behavior:

  • losing optional research is acceptable, so research availability can fail open;
  • leaking private data or publishing unpersisted research is not acceptable, so integrity and privacy controls must fail closed.

This architecture-first, evidence-gated workflow is now part of how I build.

What's next

  1. Complete a controlled real-provider run that proves persistence, reuse, sanitized telemetry, and evidence binding.
  2. Verify citations by fetching their URLs, recording redirects, checking trusted-domain boundaries, and binding the retrieved content to the relevant ticker or company.
  3. Evaluate whether the research layer improves decision consistency under a defined review protocol rather than making investment-return claims.
  4. If the system proves useful, make it available to other retail investors.
  5. Extend the architecture beyond Vietnam using its market-aware research identity and bilingual interface.

T3 Research Intelligence is a research and decision-support system. It does not guarantee investment outcomes or replace independent financial judgment.

Built With

Share this project:

Updates