Building the system, I am focusing on 10 questions I have about the world around me. A mechanical interest in understand a holistic picture as to why things happen.

FEC, SEC, Legislation, BLM (the government org, not the advocacy org), GSA, and various OIG orgs are among the data sources I’m ingesting. There are state level agencies sprinkled in there, such things as business data.

I can currently ingest a lot of it. A day or two ago I was ingesting quarterly SEC bulk data. On my desktop it is more limited but between Having 3 very different data pieces, joining them with my DSL gumlang language and compiling an 11 million line csv to then put it in Clickhouse I clocked it at ~14 minutes. So the breakdown total was processing around 742K pieces of data a minute.

There is room for improvement, but it was a good real world reminder of the importance of Big O. Algorithms matter a lot for time and energy costs.

What is Gumpla conceptually?

Above I said I “compiled facts”. That means little, what are facts here?

Facts are:

• a subject

• a predicate (donates to, does business with, legislated on)

• a value ($100, 100 documents, 100 connections etc)

• time

• confidence

• provenance

• properties

Example

Apple Inc. reported assets 364,980,000,000 USD on 2025-03-31

The point being conceptually gumpla revolves around facts.

Conceptual shift to facts and interpretability

While I outlined facts above, I am aware “fact” can be a loaded term. It is the most relevant concept to what I’m doing.

The facts pertain to the data alone. Facts are gathered to bring about “interpretability”.

During test ingestion of FEC and SEC data sources I’ve come across wild data. You can read about how official data sucks here: "why official data sucks"

I decided that dropping the wild data points I found was a fools errand. Defining what is actually dirty in data is a tough problem. Sure, outliers are easy to find. You only need to establish standard deviations and find which points are outside it.

The problem though is deeper, not every piece of dirty data would necessarily be an outlier. Outliers themselves may not be bad data points. More important though, these outliers still tell me things.

Take the 14 person bio company claiming to have earned 4x apple during a <$20M IPO.

Is it an intentional misleading?

Is it a mistake?

The data colors the dataset in which it exists. I’ve found what is better is to see how many colors I can elicit from this portrait. Facts surrounding the company in which I can interpret it better.

Bad data still tells me a story. And it’s only a problem if I don’t have context in which it exists.

The Architecture

Initially I called this project Oliver, then Gumshoe, then into settling on Gumpla, a play on gumshoe + gunpla.

Over the iterations I came on the shape below, its a sketch, I diagramed it on Linux and I didn’t have that adobe niceness.

Not the prettiest, however I feel it conveys the general meaning and shape. In this document I want to go over the rational and pieces of it.

Gumption and Gumlang

Gumption

Gumption is the data query dsl I wrote to query both Clickhouse and Tantivy. Below is a robust example:

//
// Montana PCA Provider Investigation
//

family pca_providers {
    subject.entity_type = organization
    subject.topic = pca_provider
    subject.jurisdiction = MT

    observed_at between 2019-01-01 and 2024-12-31
}

family audited_providers {
    use pca_providers

    mention.source in [
        mt_legislative_auditor,
        cms_audit,
        oig_hhs,
    ]
}

family high_billers {
    use pca_providers

    predicate = billed_medicaid
    value_number >= 500000
}

family sanctioned {
    use pca_providers

    predicate in [
        sanctioned_by,
        investigated_by,
        cited_in_audit,
    ]
}

//
// Profile
//

pca_providers -> profile {
    include = [
        facts,
        mentions,
        relationships,
    ]

    depth = 2
    limit = 100
}

//
// Billing statistics
//

pca_providers -> facts {
    predicate in [
        billed_medicaid,
        registered_as,
    ]

    value_number >= 100000

    group_by = subject_id
    metric = sum(value_number)

    sort = metric desc
    limit = 50
}

//
// Mentions
//

audited_providers -> mentions {

    interval = year

    sort = observed_at desc

    limit = 200
}

//
// Relationship graph
//

pca_providers -> flows {

    predicate in [
        owned_by,
        registered_agent_of,
        shares_address_with,
    ]

    depth = 2

    group_by = object_id

    metric = count()

    sort = metric desc

    threshold = 2
}

//
// Timeline
//

sanctioned -> timeline {

    interval = quarter

    group_by = predicate
}

//
// Compare populations
//

compare high_billers against audited_providers {

    by = subject_id

    emit = [
        shared,
        only_left,
        only_right,
    ]

    limit = 100
}

//
// Statistical outliers
//

high_billers -> outliers {

    metric = value_number

    method = zscore

    threshold = 2.5

    limit = 25
}

//
// Rendering hints
//

render {

    default_view = timeline

    color_by = topic

    allow_drilldown = true

    show_confidence = true
}

This investigation defines a reusable population of Montana Personal Care Assistance (PCA) provider organizations and performs several analytical views over that population.

The investigation:

• Defines reusable families representing provider populations and derived subsets.

• Summarizes Medicaid billing activity and organizational registrations.

• Collects audit and oversight mentions from multiple public sources.

• Explores ownership and organizational relationship networks.

• Builds chronological timelines of audits, investigations, and sanctions.

• Compares high-billing providers against those appearing in oversight reports.

• Identifies statistical outliers in Medicaid billing activity.

• Specifies default rendering behavior for interactive exploration.

The result is a complete investigative workspace describing both the operational characteristics and oversight history of Montana PCA providers.

Big, I know.

Gumlang

Gumlang is the DSL to define facts from documents. Below is an example I use to ingest bulk SEC data.

Bulk SEC data comes with multiple files, the one I omit is pre.txt.

//Name the data sources and alias them
#{num}[num.txt]
#{sub}[sub.txt]
#{tag}[tag.txt]

// it is a fact of the measurement type name "sec_reported"
fact measurement.sec_reported {
    //$sub{name} -> sub is the file, name is the field and it gets put in the subject field
    subject: company "sec_company:{$sub{cik}}" $sub{name}
    predicate: reported
    object: financial_concept "sec_concept:{$num{tag}}:{$num{version}}" $tag{tlabel}
    value_number: $num{value}
    value_unit: $num{uom}
    value_date: $num{ddate}
    props: [$num{qtrs}, $num{segments}, $num{coreg}]
    //establish where the fact came from
    provenance: [$num, $sub, $tag]

    //fields in which these documents are joined
    $num{adsh} == $sub{adsh}
    $num{tag} == $tag{tag}
    $num{version} == $tag{version}
}

This was a complex part and a real world example showcasing the importance of Big O.

Early versions of gumlang execution we based on repeatedly scanning documents for joins. In essence I was doing loops in loops to scan documents. This resulted in around 35K facts within 20 minutes.

Awful timing. Nowhere near what i needed to ingest files with millions of lines.

I instead opted to perform joins by building hash indexes over lookup sources before compilation begins. Rather than repeatedly scanning reference datasets for every input row, each lookup source is loaded once into an in-memory hash map keyed by its join fields.

During compilation, joins became constant-time hash lookups instead of repeated linear searches through source files. This shifts the execution model from repeating work to pre-computed indexing, reducing the overall computational cost.

In the wild, this change had a ~600–700× improvement in throughput without changing the overall compiler architecture.

I went from creating ~35K facts in 20 minutes to producing ~1M facts a minute. Overall throughput including all steps rose dramatically.

This isn’t the optimization ceiling, but it proves the architecture is good.

Gumlang will need to be extended to define more facts or forms in the future. Ideally I don’t want 3 DSLs. I also don’t want to introduce yaml configuration as the error surface on yaml is greater than my compiler for this use case.

Gumware

Gumware is the gui front end, the driver seat to the system in a sense. I initially wrote one in Next.js. It worked well enough.

I ultimately didn’t want to maintain it because I found js/ts to be spaghetti in many ways. Looking at it made me irrationally frustrated.

Plus the dependency hell I found in npm and its contemporaries to be brutal.

I found my dependency graph to be a tangled web which in some cases included what I felt were intrusive telemetry. Especially with deck.gl. I fumbled around testing Godot because I wondered if a game engine would provide a better user experience.

I decided against that.

I went to slint. I then realized the target market for it may be slimmer because I’m asking for an install to desktop which has it’s own downsides.

Dioxus is where I landed. It isn’t the most mature, but serious organizations use it so I don’t have too many concerns of it just evaporating.

Gumware flows to the api which in essence is just an axum webserver which can control gumd.

I don’t have any recent pictures of it because the UI is still in flux.

Gumd

Gumd ingests data targets. Targets can be bulk downloads. Targets can be trails of unstructured data like web pages. Right now the trails exist as a yaml file which defines a chron like job to retrieve documents. You can do one off’s too. Gumd is rust. It uses sqlite as not only a store but a FIFO like queue to send jobs.

It sends jobs to a deno playwright worker (of which there are a few). I decided I needed to integrate deno because of playwright.

Unfortunately a lot of webpages use js. There is fantoccini in Rust, there is a chromium crate. None have the maturity of playwright.

I decided against using python because of the data chunking abilities and if I had to choose to either do Typescript or Python I choose Typescript. I also chose Deno because of the security implications around a pure nodejs implementation. Deno is more security aware.

Though I’m very aware dependencies can still hose my system. It to me seems more prudent to have deno.

Deno Workers + Gomitm

Deno workers are the data grabbers. They exist to grab structured and unstructured data from jobs via gumd.

Deno workers can do steps.

These steps, or “job specifications” have deno do things like click buttons, log in, go to pages to get data.

Jobs aren’t limited to single captures. This is a manual process because trying to grab webpages is a pain. Users would be encouraged to do recon through something like Caido and see what valid workflows are before drafting job specifications.

Deno workers then send data to the gomitm proxy. The proxy does a lot under the hood that I don’t need to configure.

I like the idea that the deno workers running through the proxy can block trackers among other things.

Chunking out through the gomitm proxy also allows me to stop ddosing attempts. Having gomitm also gives me a single endpoint for multiple deno workers.

You likely realized I’m using golang instead of the python mitm crate. I was using the python mitm proxy at first. Outside of again just not wanting to work with python, I felt more at home with the design and capabilities of a golang proxy over a python one.

Eventually I will be working on an in house proxy called gumitm in Rust, but that is a ways out.

Capture Core

When the gomitm proxy receives flows and sessions through the deno workers, it relays that data to the system’s capture core.

Capture core assembles data coming from the gomitm proxy, structured and unstructured data.

Data here has two paths.

Path 1: large files

I don’t want to spool big files to pieces on the disk. It’d be too long and ultimately dumb. So instead I stream large files into minio through .part pieces.

While I have to keep a certain amount of pieces in memory, I’m not sitting and creating a 20 million line file through pure spooling. Parting it out into minio only really works with large files as there are data size requirements. Once minio has the data, the pad then gets a letter basically giving the minio key and

“you gotta enrich this data buddy”.

Path 2: not large files

Files that aren’t large do get spooled in a sense in memory by getting written to a rolling warc writer.

I have written the warc implementation myself. This is an unfortunate evil as streaming single pieces of webpages into minio directly sucks and I need warcs.

I haven’t seen a good way to stream warc writing into minio. There would be coordination complexity. Ideally I keep warc sizes ~80mb, keeping full sessions together.

Capture core also tees off sessions into extraction core via an envelope message. I can have this as a parallelized process.

Extraction Core + NER/OCR

Extraction core extracts data from unstructured data. Web pages, metadata, OCR, pdf ingestion, form ingestion. Right now form ingestion like SEC 10-K forms are yaml. The plethora of form types do present and interesting problem which gumlang somewhat fixes. In the future the form ingestion logic will likely exist as an extension of gumlang as stated above.

Forms or the push to be able to ingest arbitrary data is an interesting problem and hell. I see myself drifting into a configuration landscape I’m not thrilled about. However, hearkening back to my intro the questions I want answered unfortunately are disparate data sources. I also have a lot more I want to point the system at (threat feeds, historical campaign, etc..). Right now gumlang works on unstructured data mainly through gazetteers. On top of gazetteers I have implemented NER.

Onnx NER and sentimental analysis

I landed on using onnx inference model. Namely the bert base model. I needed NER initially for SEC def14a forms. Those forms are unstructured, however they are important as they are an incredible source of officer information. The need for entity extraction ended up extending far past the initial SEC forms. Entities in documents give me contextual understanding when paired with provenance and sentiment.

Sentimental analysis right now is gazetteer based, mainly. An array of words attached to document tone and confidence. I chose this route mostly because i needed some more deterministic functionality.

Last, I chose ONNX over spaCy because I didn’t want to spin up a python service where I’d need grpc and tonic. Keeping it better in the Rust ecosystem was a no brainer.

Pad

The pad is the space where the execution of gumlang actually happens. Pad executes compiled gumlang on documents. Currently pad pieces things out to a csv, in the future it will stream batches into clickhouse directly.

Pad is central because all data runs through it for fact aggregation. Pad’s rules are basically “always produce facts even if all data sources aren’t new”.

Basically, if you get one new document in your fact set, produce new facts. Pad executes on unstructured data too, mostly based on gazetteers.

Pad performs no operations outside of the scope of fact production.

No OCR.

No NER.

It takes in data, matches provenance and writes facts based on compiled gumlang.

Clickhouse

Clickhouse is where the analytical processes actually happen. Initially I thought maybe to put them in Rust, but it came down to having Clickhouse do what it does best.

Base analytical points in Clickhouse

1. Depth

- Graph traversal depth. What is connected to Acme Inc.”

2. Entropy

- Measurement of uncertainty or concentration. Basically to measure diversity in data. What is random?

3. Frequency

- Simple counts of facts

4. Cardinality

5. Temporal Density

- How activity changes over time

6. Velocity

- Velocity, not the same of frequency in a density sense

7. Centrality

- Analytical approximations like most referenced organization or most shared address, or most common officer

8. Outliers

9 Correlation

- correlating officers to organizations to other places in sets of data I have.

10 Confidence

- Weighted aggregation to denote how confident I am in certain aspects

11. Completeness

- how complete an entity is in terms of its holistic interpretability

12. Coverage

- The amount of evidence that supports something

13. Information Gain

- does this fact/observation reduce uncertainty?

The schema in Clickhouse is on flat facts table. Ideally in the future there would be two Clickhouse instances: one analytical and one on the hot path that sync data. I landed on a single table as Clickhouse is columnar and huge join sets on it aren’t as performant. If I place everything in one place I’m better able to derive data from it quickly. Will this shoot me in the foot? Maybe. Its an unorthodox approach to the problem space, but I’m willing to experiment.

Clerk and Tweak

Clerk and tweak both have to deal with Tantivy. Tantivy will be a multi index search engine for the data. The clerk is basically the interface to use tantivy.

Tweak basically drives the analytical pieces of Clickhouse and updates Tantivy indexes based on new information gained from the analytical processes in Clickhouse.

Snoop

Snoop is the auditing surface for the system. Just logs and other useful information.

Conclusion

The whole system ideally runs in a single binary composed of tasks which pass around tokio channels. So far I don’t have a reason to distribute it. I don’t want to distribute it. Parallel tasks just passing data through channels is ideal. That said there are unfortunately a few places I needed to externally containerize. It is the cost of doing business instead of a need to look sophisticated.

I have made great progress with the system so far. While I yearn to just look at data, I unfortunately built something robust.

I got it to the point where I was mapping geographical positions of campaign donations over temporality. It was originally built with Neo4J because it felt like the right fit, but it wasn’t a good experience for 100’s of millions of enteries. Bolt doesn’t handle that volume well. So I eventually ditched it. I needed a lot of data, and I needed the analytical database to handle it which was clickhouse. The focus on columnar data in clickhouse helps me more than the row based focus of other databases. But I grew and realized I needed to query/search all the disparate data I had.

pywb was way too tedious and arcane. It didn’t work for what I needed, and to add to that it is python to which I’m not a fan.

I started on gumpla (play on gunpla but with gumshoe). It started as a config driven system to build entities, aliases, topics, topic groups, and facts. I build out a “pad” to join different data sets, then I built out functionality to create an insertable csv artifact that had all the components needed to have graph like functionality within clickhouse. I established an onnx ner pipeline to derive entities from unstructured data and feed them into the same pipeline.

Before my realization I was able to work with about 56M rows on my desktop. Not enterprise, but its a lot to me.

I was happy to start playing with the data until I realized how much straight up bullshit exists in official data. Not even plausible bullshit. Straight up absurd bullshit.

My first encounter was finding a $100M political donation from a committee that was null/bunk/didn’t really exist. This committee and subsequent donation reports were from an eccentric man in a Carolina. To give context, Elon Musk donated $30M. This man reported he donated $70M more than Elon musk from his residential address in a middle class neighborhood. So it turns out you can just file whatever number you want. With that I was intrigued by the guy and his story. He evidently not only had a penchant for making bogus committee filings and subsequent absurd donations, but he was also really interested in geothermal properties. And yes, he filed bogus bids to the bureau of land management. Its harmless, and I’m happy he has a hobby. But it really screws my numbers and faith.

So, my thoughts then were “surely the SEC has way more intergrity!”

Nope.

After ingesting the bulk num, pre, tag, sub files for the 4 quarters in 2025 I ran across another anomaly: MDB Capital Holdings apparently earning three times Apple's quarterly income. In fact, in the SEC data MDB earn 4X what Apple did. Wow, this is interesting! Kinda..

I traced it a $419 billion dimensional XBRL fact attached to a 14-person biotech startup that raised $17 million in its IPO. The problem started to really form. I needed to stop fighting bad data and derive context that explains its meaning. MDB Capital Holdings, the numbers needed a lot of context to figure out if they are meaningless or actively misleading. This ran me down a huge rabbit hole of XBRL. I guess its an active problem. But XBRL is too niche and I’m not an economist or whatever.

Every data set I touch turned out to have absurd anomalies. Anomalies you would think would be caught and corrected. Bad assumption on my part. For all my faith that the SEC makes the suits tremble, they’re completely fine being like “Your 14 person company earned $300B more than apple? Sounds legit.”

Why fight to clean it? Cleaning it is a losing battle in not only the sense that its a fools errand to catch it all, but also that I’m losing data in the cleaning process.

All of these absurdities tell me different things about the data I’m ingesting. In the case of the FEC data it tells me I should give committee context. The SEC data, I realized I needed a lot of XBRL context that can be enriched with the additions of quarters and 10-K filings.

I spent a LOT of time writing my pipelines to ingest datasets.

That is the wrong goal.

Datasets exist in a vacuum. Numbers have meaning. Topology has meaning outside of where it is seen.

I started writing my ingestion pipelines around facts, better yet, questions. The data needed to answer those questions.

Take MDB Capital Holdings, instead of building the database around the data set it exists in, I built out what makes MDB Capital Holdings make sense. What filings make any of this make sense. What contextualizes their absurd reporting to a commission who evidently cares so little that they just lean into the bogus data.

The FEC data surrounding the $100M hotshot: what is this committee, what filings does it appear in? Easier question in this context, but it illustrates a point.

These are multi-domain questions and facts. I could tell you that Winklevoss Captial Management donated $21M over 3 days for a crypto initiative, dwarfing anyone in Delaware. But it is meaningless without the context of motivation and topology. What was the initiative? What was a temporal cousin? Who did they donate to? The best question behind it comes to what payoff that may have come from it. I’m not a rich man but I have a hard time believing anyone just burns that.

With these absurdities, provenance became first class. If I see these numbers, and I report on these numbers, people will point out the absurdity. I cannot afford to not establish provenance. Provenance establishes integrity, design, and reason. It also establishes baselines of where good data actually comes from.

Most important I started with methodology. Build around how I intend to work. I wrote down 10 questions, somewhat open ended and at face value ambitious. Building out schema and configurations around the data to derive facts to answer these questions was far easier than it was to think abstractly. A tangible path forward was birthed from understanding that my system needs to focus on making things interpretable. Giving context over whatever idea of truth I was trying to cultivate.

Once I establish the platform around interpretability, I stopped the vigorous pruning and just took stock of the bush I was looking at.

Bullshit tells a story too, sometimes bullshit makes the smell of truth more noticeable.

How it started out is that I emailed my congress men and women about an important issue. Much to my chagrin, the response was basically “I do what I want, sorry bro”. And I thought “well they don’t listen to me, I wonder who they would listen to?”

That one thought was the catalyst to what started as a platform to map campaign finance.

Then I mapped campaign contributions (I only chose Pelosi because I needed to test a Cali dataset and I’m not clued into politics in general. Pelosi was only who I knew from California).

Above is basically mapping donations to Nancy Pelosi’s campaign.

And I found odd things, like odd committee names (again, just needed Cali to test)

I found it exciting to work with the data. From campaign finance I learned a lot of things like:

1. About 80% of the donors from states I looked at are retired/unemployed

2. Women who donated to Republican causes were more likely to list themselves as homemakers if out of work. Their counterparts donating to Democrat causes listed themselves as unemployed

3. Generally the highest donors listed themselves as unemployed

4. FEC data is cumbersome. They use a format from the 90s, they don’t give you headers, they give a committee master you have to link. If I didn’t know government better I’d assume they are intentionally opaque

5. I learned that I needed to gate keep it since I made it trivial to find and correlate PII that requires an undertaking to really searchable

What was really cool? The outliers. The retired woman who donated almost 9K times in the last year, sometimes 30 times a day, all small amounts. I’ve found donors blowing so much money but who had a profile that made no sense. I’m a gossip girl and I love theory crafting.

I ended up getting hooked.

Little did I know, the local first work bench would bloom into something like this:

It turned into scope creep as far wiser people than me would say.

I’m 250 files and 12k lines code, 4-5 language span into a solo project.

I feel the weight of it. Every decision, every refactor, I feel it. Having castles made of sand is the tough part. Adding new functionality in a modular system? Simple. Rust for me is easy. Golang is simple because I had to learn it. Python though, is always a test of grit.

Always one more thing all the time.

The pictures above was an old version. I realized I needed to go to slint to do what I need. So yea, all that work got trashed, and yea, that front end work is hard. I stomped my feet and threw my tantrum. But I got a roadmap.

So where did I land?

Cartridge system - a north star.

Cartridges that are pre-built for portability and visibility are central to gumshoe. Loading up 5 million line tables in neo4j and traversing connections that have complex connections is tedious. Like folding laundry. So I decided I would move data into different cartridges (or views). Typically for my use case by state, and flows in and out of the state of data points.

Provenance - the big dipper

And investigative platform needs provenance. In the old days you could just be like “trust me bro” but we’ve all gotten hoodwinked one too many times. So data sets have provenance. Web investigations are all warc driven. I’ve set up a system to collect full webpages in warcs for pywb and outbackcdx. I need to cross my t’s and dot my i’s. If I’m not squared away I look bad.

Data Agnostic - Orion’s belt

In general when I build systems I have idiosyncrasies where I have to make it as general and as extensible as possible. It’s who I am. I look at something and wonder “how can I use this one thing for as many things as I can?” The sentiment stems from laziness more than frugality or planning. I don’t want to write a lot to add to something. I don’t want to restructure everything. So my work reflects a level of effort invested into making sure I can do all those things. Sometimes an inordinate amount of effort.

Aesthetics - Venus

I like aesthetics in my GUIs. I don’t enjoy something that is painful to look at (like Python). So I’ve invested a lot of time into color. Nice colors. Colors that would make you think I had taste. Aesthetics don’t generally stop there, aesthetics to me encompass the whole experience. So I use what I make. If it’s tiring, I failed.

Last I want to talk about the ethos I kinda adopted in this process. I started reading “Scouts Mindset” and it went over a lot of what my natural neuroticism does for me: being objective about myself and the world around me. Above I wrote about outliers, things, people and places that don’t make sense in the data. That confusion is essentially my ignorance and bias in action (likely). Public data is public, sure. But not a lot of people go through the effort to correlate and map it in the ways I did. I keep the mindset that the data is just interesting. I can theory craft, sure. But it stops at me understanding I have no conclusion to come to. As a human when I do I realized I needed to exhaust ever charitable explanation and steel man something. My world is shaped by my experience. So I need to realize people are very different from me.

Also, I realized things need guardrails sometimes. As a developer and builder of many things I often forget that I sometimes make things that are dual use. This turned out to be something I have to put some gates up on. The 99% of people would be fine, but that 1% is where we pick a whole bouquet of oopsie-daisies.

I’ve invested a lot of work into Gumshoe, this article is just my thoughts on it so far. My plan is to come on here and just walk through interesting things I’ve found. No conclusions, just data and what I’ve learned from it. Shell companies, trust sprawl, linkages to campaign finance. I’m able to explore all sorts of things with Gumshoe.

That said, once gumshoe is finished, it’ll be open the the more seasoned investigators or researchers. Hopefully what I use would be useful to small teams or a lone wolf with good gear. This started as a project of accountability. To take data that is disorganized, opaque and scattered and make it into a cohesive picture for us to really know what is happening in the world.