Personal Portfolio
Work

Turning “will it fit my machine?” into set intersection

Matchpoint Intelligence · 2024–2026 · Python, AWS Step Functions, Lambda, SQS, DynamoDB, Neptune, Gremlin, OpenCypher, CDK, Bedrock · Sole Developer

Problem

A buyer looking at an attachment has a singularly important question that is not answered in the industry: will it work on my machine? Heavy equipment has no fitment standard like automotive’s ACES and PIES. We had 4,586 machine configurations and 37,638 product variants: about 173 million possible pairs. Most of the industry just doesn’t even have a catalog and is largely driven by tribal knowledge and phone calls. Hand-kept fitment tables can’t keep up, and they certainly couldn’t say why a pair fits or doesn’t fit. This is also a mechanical interaction - it adheres to the laws of physics. So it stands to reason that a physics-based approach would solve this problem (and expose entirely new categories of information).

First principles

Physical-world fitment follows the laws of physics, which can be derived to three mutually exclusive physical relationships. Further, each relationship is only relevant to a specific part of a complete product - not the entire thing. So we can extrapolate the responsible components, standardize their relevant specifications, and calculate subsets and supersets of compatibility from each:

  • Connect: does the machine’s interface match the attachment’s mount?
  • Power: can the hydraulic flow and pressure of the machine power the attachment’s motor?
  • Lift: can the machine lift the attachment’s weight?

So compatibility is set intersection. Each machine group g needs a subset Req(g) of the three relations, and

Compatible(g) = ⋂ { R_f : f ∈ Req(g) },   R_f ⊆ Configurations × Variants

Approach

I split machines into components and configurations, and products into variants. Step Functions fan out the three relations in parallel from component facts. Every edge keeps its margins (flow, pressure, lift), so each “fits” carries its reason. Results bulk-load into Neptune and Neptune Analytics. Upstream, an LLM reads spec sheets into facts, and validator functions reject any fact that fails a check. Doing it this way allows for a self-healing architecture (changing any machine recomputes for all attachments from that machine, changing any attachment recomputes for all machines from that attachment), and allowed for sharding and high-concurrency (component-based subsets i.e. power, lift, connect are mutually exclusive, so can run in parallel. Each “side” is mutually exclusive, so machines and attachments can run in parallel). Used Neptune Analytics for reads for latency, Neptune Graph for traversal calculations with bulk loads – database of 25M nodes and 100M edges had single-run speed of <1 minute for entire recompute of one machine or attachment. Apps and agents got the answers over REST, MCP and a CLI, all generated from one OpenAPI contract.

The five figures below show the full design, as specified for the Dev environment.

The data journey, as specified for Dev. Inlets: a document fetcher for manufacturer pages and PDF spec sheets, public-source acquisition including portal submissions, and store webhooks, catalog runs and CSV files through provider adapters. Vehicle-Graph (LLM extraction with citations, seven validation layers, operator overrides, publication by pull request) and Product-Enrichment (persistent product ids, fields with provenance and confidence, ProductSourceRecord@v1) standardize the data under shared paired schemas. Machines land in an S3 vehicle bucket and products in the ProductMetadataExtensions table. A DiffDetector and Planner schedule only the affected work, including operator direct fits. The Compatibility Engine computes power, lift and connect edges, then fit edges, and a single writer loads Neptune Database and Analytics with a receipt per load. Compatibility-View, Agent Data Access (REST, MCP, CLI) and the store projection serve the results. The loop: fit results settle back into the product table, whose stream rebuilds each product’s Bloom filter, and a change analyzer ignores the write-back so it never retriggers compute.

Building the machine graph with set algebra. A profile per family (tractor, tractor loader arms, loader) supplies the registries every stage reads. Canonical facts become vertices and properties, and vertices are filtered into sets by label: VE vehicle, AHS hydraulics, RH rear hitch, LA loader arms, TFK kit, AI interfaces, with THI the hitch interfaces and LAI = AI ∖ THI. Optional sets add the empty element, S_z = S ∪ {∅}. Loader-arms configurations are LAC = LA × TFK_z × MSL × BASE × LAI, which is 1 × 2 × 2 × 3 × 1 = 12 for one real arms model. Tractor configurations are C = VE × AHS × RH × LAC_z × CFG, so the count is VE · AHS · RH · (LAC + 1) · CFG, where the +1 is the tractor without a loader. Each tuple becomes a Configuration vertex with edges by rule: vehicle, hydraulics and rear hitch exactly once, loader arms zero or one times, and none for ∅. Registry UUIDs keep ids stable across rebuilds.

Paired schemas: each rule pairs a machine component field with a product variant field. can_power hydraulic: the machine’s flow_rate_max must fall within the variant’s minimum and maximum hydraulic flow, and its system_pressure may exceed the variant’s max_operating_pressure_psi by no more than 5%. can_power PTO: engine_hp within the variant’s minimum and maximum tractor horsepower. can_lift: variant weight no more than the rated lift capacity, meaning the 50% rating on wheeled loaders, the 35% rating on tracked loaders, or the loader-arm or 3-point hitch capacity on tractors. can_connect: one of 22 registered interface and mount pairs, 18 direct and 4 through an adapter, joining 24 shared interface nodes to shared mount nodes. A configuration fits a variant when power passes and any required connect and lift paths exist; margins stay on the power and lift edges, and a direct fit beats an adapter fit. One version set pins the schemas, rules, pairs, registry and Bloom format together.

Recompute only what changed. A change to a machine component or a product variant fires an object event or table stream. The DiffDetector diffs the subgraph before and after and names the edges to drop and the facets to recompute. The Planner, in Step Functions, syncs the graph, resolves ids, builds shards and launches the engine; bulk recompute releases a tenant’s variants into the same queue in 1,000-variant chunks. Requests group into cohorts of up to 120 shards, flushed every 10 seconds, with five running at once. The minor phase computes power, lift and connect edges in parallel, one shard per facet and seed, 120 at a time. The single writer loads them into Neptune Database and Analytics, checks both hold the same edges and writes a receipt, and only then does the major phase build fit edges per variant or configuration. Postflow settles fits into the product table, syncs vehicle records to the store and tells the read model the plan is complete. For example, new hydraulics on a machine recompute only that component’s power edges and the fits through them.

Where the data lives. Systems of record: tenancy and access (tenants, clients, sites, users, entitlements, provider bindings), product identity (a ppid per tenant product and an rpid per reference product, each minted once), the enrichment workspace, machine registries (config_id, canonical facts, evidence, overrides) and the customer registry. Materialized: the product table with its stream, the vehicle bucket written only by publication, and each tenant’s assortment. Graph: Neptune Database and Analytics holding the same edges, with ledgers for version sets, write receipts, bulk admission and direct fits. Projections: Compatibility-View, the store projection (a Bloom filter per product and vehicle records per store), the agent read model behind REST, MCP and CLI, and the analytics lake in S3 and Iceberg. Provider adapters ingest on one side and project on the other, chosen by each tenant’s capability manifest with no default, and imports point one way: platforms, ecommerce, provider-core, compat-core. Each record has one owner, and everything downstream can be rebuilt from the records.

A slice of the compatibility graph: a machine configuration links to its rear hitch, loader arm and auxiliary hydraulics; the rear hitch and loader arm each have a can_lift edge to a product variant, the rear hitch’s interface connects to one of the variant’s mounts, and the configuration has a COMPATIBLE edge to the variant

Skills I taught myself

  • Graph modeling and Neptune (Gremlin, OpenCypher bulk loads). Fit is a relation, and a graph stores relations directly.
  • AWS orchestration (Step Functions, SQS, Lambda, DynamoDB, CDK), to compute the relations in parallel.
  • LLM fact extraction with validators (Bedrock), to turn spec sheets into facts a check can reject.
  • Heavy Machinery Specifications learned from operating Attachments King and selling the equipment myself.

Result

25M nodes, 100M edges and 13.99M validated compatibility edges. The code is private; I can walk through the design on a call.

Next → Storefront fitment filter