Klaussa
Indonesian legal corpus
297Kregulations
Pulled continuously from 37 separate government sources.
derived from it
- 3.48M
- 2.57M
- ~99%
AI Research, Engineer, and Product
I acquire terabytes of data
and build the intelligence layer on top of it, cheaply.
I build AI systems over messy legal, government, and research data. They acquire the source material, turn it into usable structure, and answer with evidence attached, at a cost that can work at national scale.
Common projects I took
Gather diverse data then build intelligence layer
I collect fragmented sources, normalize them, and expose the result through an evidence-backed workflow.
Cost follows meaning, not row count.
Repeated ledger semantics are collapsed before inference, so large workloads do not require one expensive model call per row.
Data acquisition
One store per source. Each has its own size, format and release schedule, and none of them line up.
Intelligence layer
The same material collected into one interface, so a decision can be read off a single surface.
Data Scale
The data scale and algorithm implemented on top.
FiskalLink
Ministry of Finance
1.83Mbudget lines
Covering USD 224.4B of public expenditure.
derived from it
- 2,741
- 667:1
- 1,111
Paperbase
AI research corpus
159.8Kpapers
Indexed from ten core venues and arXiv cs.*, and topped up as new papers appear.
derived from it
- 106,263
- 9
- 10
I acquired Triple helix model of innovation
Experiences across Industry, government and academia
I build production systems for industry and government, and research methods that make those systems more useful.
Industry · Klaussa
Founding engineer at a seed-funded legal AI company, about 100 daily users in production
Government · Two ministries
Delivering AI products to the Ministry of Finance and the Ministry of Law and Human Rights, as a startup partner
Academia · 8 papers, 40 citations
Published during undergraduate study; member of SEACrowd
Featured projects
What was broken, and what fixed it.
Ministry of Finance
Tagging a region's budget to a policy theme, line by line.
It turns a plain-language policy theme into a reviewed, traceable analysis of a large budget. Regional and national budgets remain separate because their bases differ.
fiskallink / full run
A theme becomes a standard operating procedure, one reviewer correction spreads to every similar line, and the budget is traced from raw ledger to headline figure.
Delivered interface
fiskallink / city-xxxxx-2025 / stunting
A theme typed in plain words becomes a standard operating procedure, carrying its legal basis and its weight ladder.
Illustrative product mockup: the on-screen figures are sample data and the region names are masked. The impact figures are recorded ones.
Impact
- 1.83M
- budget records reconciled
- USD 224.4B
- public expenditure covered
- 667 : 1
- ledger rows per AI judgment, across 2,741 judgments
- 5 days → 20 min
- analysis turnaround, human review kept
- ~$28K → ~$50
- cost per analysis (modelled)
- 1,111
- tests with enforced architecture boundaries
Delivered
Ports and adapters engine+
Domain logic separated from each ledger and storage backend, so a new source is an adapter rather than a rewrite.
Semantic collapse+
Repeated ledger semantics are merged before any model call, which is what makes one judgment cover hundreds of rows.
Content-hash invalidation+
Resumable processing that recomputes only what changed, so no verdict goes stale silently.
Residency-bound deployment+
AWS Lightsail in Jakarta behind Cloudflare, with heavyweight SDKs replaced by custom SigV4 and TF-IDF to fit a 0.20 MB/s uplink.
Human review queue+
Every judgment lands in a queue a finance analyst accepts or overrides.
Seeded legal-tech company
Indonesian law is scattered across 37 government sites, much of it only as scans.
Klaussa collects all 297K of them and keeps collecting, reads the scans with OCR run on its own hardware, links every citation from one regulation to another, and answers a legal question with the clause each part of the answer came from.
klaussa / full run
One pass through the product: a legal question answered from the collection, the regulations behind it searched and mapped, then a document reviewed and another drafted against the same source.
Delivered interface
klaussa / chat
A legal question is answered from the corpus, with the plan it followed and the articles it relied on.
Drawn product mockup: the company names, people and contract files in it are invented, while the regulations, article numbers and platform figures are real. The impact figures are recorded ones.
Impact
- 297K
- regulations acquired from 37 sources
- 3.48M
- vectors indexed
- 2.57M
- citation edges at ~99% precision
- ~75×
- cheaper per query than the hosted baseline
- ~92%
- of the OCR budget saved with in-house OCR
- ~100
- daily users in production
Delivered
Self-healing acquisition+
Stage-based ETL where every stage is idempotent and resumable, with an isolated coding agent that has shipped six production fixes on its own.
In-house OCR+
Run on a rented 16x RTX 5090 cluster, with low-confidence pages dead-lettered instead of silently indexed.
Citation graph+
An in-text citation algorithm that links each regulation to the ones it amends, implements or is tested by.
Agent harness+
Planner, tool use, supervisor and grounded citation over a self-hosted Qdrant index.
Klaussa-8B+
Llama-3.1-8B with continued pretraining on 1.27B tokens of Indonesian law, then SFT, then RLVR with GRPO.
Own research infrastructure
An agent cannot tell you whether your idea is already published.
An index of AI research that keeps itself current, which an agent queries through nine tools over MCP. The pipeline works down a venue roster, pulls each paper's metadata, fetches the arXiv PDF and extracts the full text, so a phrase buried in a body paragraph is findable. A paper outside the index comes back as a visible stub that one call will ingest.
paperbase / full run
One pass: a query over the corpus, the paper opened at the matching passage, its citation graph walked, and a missing paper pulled in.
Delivered interface
paperbase / search_papers
A regex query over the full text returns ranked hits with the matching phrase in its own sentence, scored and dated, in well under a second.
Illustrative product mockup: the tool names, the result shape and the corpus figures are real, and so are the papers on screen, though they were chosen to show the behaviour and not transcribed from a single run.
Impact
- 159,815
- AI papers indexed
- 106,263
- of them with full text extracted
- 9
- query tools exposed over MCP
- 10
- core venues swept, 2018 onward
Delivered
Resumable ETL+
DBLP roster to OpenAlex and Semantic Scholar metadata to the arXiv PDF to pymupdf4llm full text. A killed run continues from a durable cursor and a per-paper stage ledger rather than starting over.
Conservative dedup+
An alias crosswalk, a normalised soft key and cluster-merge, so the same paper arriving from three providers lands once. Every ingest is idempotent.
Pluggable retrieval+
Trigrep, a lexical trigram and regex engine, is the configured default; FTS5 gives SQLite BM25 with no binary to install. The strategy is a config value, not a rewrite.
Agent surface+
An MCP server exposing nine tools: search, get, read, find_related, list_venue, coverage, references, cited_by and add_paper. It also ships a paper-research skill.
Klaussa · retrieval research
The law that answered the question sat at rank 14.
Indonesian law has whole families of near-identical titles, and a general encoder ranks them on how similar the wording looks, so the one that actually governs can land at rank 14. A 568M-parameter retriever fine-tuned on this corpus puts it first, and answers in about 40 ms on an ordinary CPU against about 500 ms for the hosted API.
klaussa-retriever / full run
The whole argument on one timeline: the query put to both encoders, the buried law surfacing, the two-register leaderboard, and what it costs to keep serving.
Delivered interface
klaussa-retriever / bench
One labelled query embedded by both encoders concurrently over the same 39,153-document index, each arm timed end to end: about 40 ms local against about 500 ms for the API round trip.
Every number, latency and metric on screen is measured by the project's own evaluation kit. The ranked lists are arranged: each row is a real document from the index and the gold document's positions are the measured ones, while the documents filling the other slots were chosen to show the failure class and not transcribed from a run.
Impact
- 14 → 1
- rank of the governing document, this query
- 12.5×
- faster per query, ~40 ms local against ~500 ms API
- 0.496
- nDCG@10 on the agent register against 0.413, n = 803
- 0.880
- nDCG@10 on the citation register against 0.856, n = 545
- 568M
- parameters, BGE-M3 lineage
- ~$5
- per month to serve, one CPU box plus free tiers
Delivered
Fine-tuned retriever+
A 568M bgemix4-w0p75 encoder of BGE-M3 lineage, trained on the Klaussa corpus so that near-identical statute titles are separated by which one governs rather than by surface similarity.
Two-register evaluation+
The same model measured on an agent register (AQUAK, n = 803) and a human citation register (KlaussaBench, n = 545), because a retriever that serves an agent and one that serves a lawyer are not graded the same way.
CPU serving path+
An in-RAM matmul over 39,153 documents, which is what lets a query finish in about 40 ms without a GPU and without a network hop to a hosted embedding API.
Query capture+
Every logged query becomes training data for the next fine-tune, so the register the model is graded on keeps matching the register it is used on.
See the work
My approach and my way of thinking
Always open for connection!
Have a challenging problem to solve, or just want a coffee chat? Feel free to reach out.
Have a challenging problem? Let me (and/or my team) get hands-on with it. We are a team of specialists who love solving challenging tasks.
Open to talking about anything: career, olympiad, opportunities, for any field & any age.
Bring the decision, the data behind it, and what makes it slow or expensive today. You will leave with the first technical question I would investigate and an honest read on whether it is worth building, including when the answer is no.