Product-minded AI systems for real needs hiding inside messy workflows.
I find overlooked workflow pain, clarify the real need underneath it, and turn it into trustworthy products for reading, decision-making, execution, and proof.

AI Engineer @ Casium · University of Washington

Open the showroom • Start with the front row • LinkedIn • Pinned six • Read the map

Based in Seattle, WA (PT). I build AI product systems for people stuck in noisy inputs, real decisions, and workflows that need inspection before trust. The pattern is always the same: find the underestimated need, then turn it into something people can actually use, review, and rely on.

If you only open four projects, start here. They are not a podium. Together they are the fastest way to understand what I actually build.

• Overlooked needs inside messy workflows.
  I pay attention to the part most tools leave unresolved: the real need hiding underneath noise, fragmentation, and repetitive manual work.

• Products, not just features.
  I do not just assemble technical capabilities. I try to turn recurring pain into systems people can actually adopt, trust, and return to.

• Decision clarity under real constraints.
  Many of my products start where the stakes are real and the surfaces are confusing. I care about helping people make better calls, not just see more data.

• Execution that can survive inspection.
  If a workflow matters, it should be reviewable, explainable, and recoverable. I do not like systems that ask for trust before they earn it.

• Industrial systems under real pressure.
  At Casium, that has meant building source-grounded AI workflows and reliable long-running systems where speed matters, but trust still matters more.

• Boundary-honest AI.
  My background in AI ethics and fairness keeps pushing me toward systems that are powerful without becoming sloppy, opaque, or overclaimed.

The pinned six are not a popularity chart, and they are not identical to the front row. They are the current proof set: the six projects that currently make the thesis legible on the live profile.

1. OpenVibeCoding
   This is the clearest proof that I care about governed execution, not just model output.
   It earns its place by showing how requests, delegation, proof, replay, and recovery fit into one operator-grade workflow.

2. Switchyard
   This is the runtime layer underneath visible products.
   It earns its place by proving I do not just build polished surfaces; I also build the shared access and routing layer that keeps those surfaces honest.

3. OpenCampus
   This is the strongest example of a boundary-honest decision workspace under real constraints.
   It earns its place by showing that serious AI products are not only for builders; they can also help people decide safely when the stakes are real.

4. DealWatch
   This is the browser-facing proof that evidence-backed decisions can feel immediate and practical.
   It earns its place by turning noisy product pages into a clearer buy / watch / pass call instead of one more alert stream.

5. openui-mcp-studio
   This is the clearest delivery-side proof in the portfolio.
   It earns its place by showing how a brief becomes a reviewable workspace change instead of a one-shot generated mockup.

6. SourceHarbor
   This is still the clearest reader-first flagship in the portfolio.
   It earns its place by showing how raw source streams become reading-grade outputs that a human would actually keep.

These flagship products look different on the surface, but they keep reusing the same engineering spine underneath:

• TypeScript monorepos with pnpm workspaces
  I keep building products as multi-surface systems, not one-page demos. The web app, extension, desktop shell, packages, and proof tooling usually live in one shared workspace so contracts do not drift apart.

• Python service layers with FastAPI, Pydantic, and exact contracts
  When a product needs APIs, orchestration edges, or agent-facing surfaces, I keep coming back to typed Python services that make the boundary explicit instead of leaving it as vague backend glue.

• Product-facing interfaces built to carry system depth
  I use web surfaces like Next.js and browser-first shells when the hard part of the system needs to become something a normal person can actually navigate, inspect, and keep using.

• Browser proof and repeatable inspection with Playwright
  When a workflow touches the browser, I do not want hand-waved demos. I want proof, repeatability, and a way to inspect the exact path that ran.

• Truthful agent/runtime access through MCP and HTTP surfaces
  I keep exposing the same system truth through MCP, APIs, and repo-local tooling so builders and operators are not forced to work through fake assistant shells.

• Proof, replay, recovery, and boundary-honest execution
  Across these products, the recurring rule is the same: the run should be inspectable, the dangerous step should stay bounded, and recovery should be designed in instead of added as an apology later.

That is why this portfolio behaves like one product universe with many doors, not many unrelated repos that happen to share an owner.

If you want the shortest mental model, use these five verbs:

• Want the full portfolio atlas? Open the xiaojiou176-open showroom.
• Want the strongest first four doors? Start with SourceHarbor, OpenCampus, OpenVibeCoding, and Switchyard.
• Want the browser-facing side first? Open Shopflow, DealWatch, or multi-ai-sidepanel.