About

About jearhe (0verme), the systems I build, and the principles behind this blog.

I am jearhe, also known as 0verme online. I live in Hangzhou and work around data infrastructure and trustworthy AI applications.

What keeps me interested is not simply making a system more capable. It is making the system understandable, recoverable, and worth maintaining after the first demo. My recurring question is: how can a complex system stay explainable, and how can automation remain controllable when it fails?

Make complex systems smaller. Put AI inside verifiable boundaries.

The three threads I follow

Data infrastructure

I write about lineage, metadata, semantic modeling, observability, and data asset workflows. The emphasis is on the decisions behind a system: integration boundaries, deterministic behavior, diagnostics, and the operational cost that appears after launch.

Trustworthy AI applications

I am interested in AI as an interpreter and collaborator—not an unaccountable decision maker. That includes prompt and usage observability, structured outputs, confirmation boundaries, idempotency, privacy, and the deterministic services that should sit behind a model.

Independent products and engineering practice

Small products are a useful way to test an idea honestly. I document how I reduce scope, choose boring dependencies, keep deployment reversible, and turn one-off experiments into tools that can improve through steady iteration.

What I am building

• lineage-viewer — a zero-runtime-dependency Web Component for deterministic, embeddable data-lineage diagrams.
• LarkLedger — a ledger where AI interprets messy input while deterministic application services validate and commit every action.

These projects are active experiments rather than finished claims. Their limits, unfinished edges, and changes of direction are part of what I want to record here.

How I write

• Start with a real constraint or failure mode, not a trend.
• Explain the trade-off and the option I did not choose.
• Separate measured facts from estimates and personal judgement.
• Include enough implementation detail for the result to be checked.
• Revisit old conclusions when the project changes.

You will find architecture notes, implementation details, product boundaries, and occasional retrospectives. I do not publish private prompts, credentials, client data, or project details that should remain private.

Elsewhere

The broader project map lives at overme.cn. Source code and open experiments are on GitHub, and shorter observations appear on X.

For a thoughtful question, a correction, or a possible collaboration, email hello@overme.cn.