← The work

Case study · BYRIS · 2026

Every field graded by the evidence behind it

BYRIS is a company census of 1,170 Indonesian exporters. A claim only exists when collected evidence backs it, so the 1,170 companies carry 71,349 rows of proof.

1,170companies in the census
71,349evidence rows behind them
848documents, 14,049 pages
106supplier pairs across 74 companies
Diagram of the BYRIS data path, from archive and extraction to Postgres, matcher, API and desk
A claim travels from a PDF page to a score on the desk

The problem

Indonesian exporters exist mostly as PDFs, brochures and unmaintained web pages. Matching a buyer to a supplier today runs on WhatsApp and memory. The obvious fix, scrape it all into one database, fails on the first catalogue: a price on page 14 of a 2019 PDF is not a price. If the product shows it as a fact, the product lies.

What I built

Built for a trade-matching initiative for Indonesian exporters. I owned the collection pipeline, the schema, the matcher and the desk.

  • A Python collection service with a platform registry, bounded runs and source health checks, scheduled through n8n on an OVH host
  • PostgreSQL as the single source of truth, with lineage views from raw candidate field to extraction row to evidence row, so every number on screen traces to the page it came from
  • An evidence-tier model, official listing, reviewed web evidence, unverified, enforced in the interface: an unconfirmed stock figure never renders like a confirmed one
  • A Go event-driven matcher that watches upload directories and generates candidate supplier pairs with explicit reasoning: input and output, bundle, pallet support
  • A SvelteKit census: company explorer, eight industry groups over sixteen sectors, intersecting filters, provenance inspector
  • An MCP task bridge so ChatGPT can drive the local agent queue

Three decisions

  1. Postgres views instead of a CSV pipeline

    Every consumer has to speak SQL, and in exchange there is one source of truth with no export drifting from it. The views are the spec.

  2. Evidence over completeness

    Missing data stays UNKNOWN, country fields included. The census is smaller than it could be, and every row in it is true.

  3. Loopback-only, read-only API until authentication exists

    No stranger can click a live demo. The alternative was an unauthenticated database on the open internet, so the demo is a recorded walkthrough.

Evidence

848 documents and 14,049 pages reduced to 69,597 raw candidate fields and 71,349 evidence rows. 106 complementary supplier pairs across 74 companies. 31 Bun tests, Go tests and isolated PostgreSQL scenarios, including a validator that caught a source total disagreeing with its own output. The desk also runs as a 729 KB static snapshot of real data, so the interface can be reviewed without the database.

Each candidate on the desk opens onto the rows behind its score, and the pair carries its reasoning: input and output overlap, bundle compatibility, pallet support. The matcher can be argued with, which is the point.

What is not proven: the scores have no precision measurement against a labelled set, so nobody has counted how often the top candidate is the right buyer. The 324 companies with no pages are a known gap, not a rounding error. And the live desk is loopback-only, so this page is the public proof.

What I would do next

A reviewer queue for the 324 companies with no pages, so the census grows where the evidence is thin. Then a public read-only demo behind authentication, because the strongest project on this site is currently unprovable to a stranger.

← Back to the work · ramasanjaya3302@gmail.com