rossdata.dev: making an ERP nobody documented legible — in public

An independent project. Standard, vanilla Ross only — never a customer's system.

The problem

Ross ERP is a capable manufacturing system running quietly inside a lot of food, beverage, chemical, and supplement plants. It is also, to put it gently, under-documented. The people who knew it best are retiring. The official reference is thin. And the working knowledge that keeps a Ross shop alive tends to live in one or two people's heads, a folder of Crystal reports, and a SQL query someone wrote in 2013 and everyone is now afraid to touch.

Every serious piece of work I do on Ross starts the same way: where does this data actually live, and what connects to what? Which table holds the field on that screen. Which screens write to it. Which web service exposes it. Which of the 1,840 tables you have to join to answer a question a plant manager thinks is simple. On most projects, half the effort is just re-deriving the map — again — because nobody wrote it down the first eleven times.

So I decided to write it down. All of it.

The idea

The premise was straightforward, if slightly unreasonable in scope: take the entire standard Ross ERP 8.0 schema — the FIN and MAN modules — and make it legible. Not a PDF. Not a wiki that goes stale the day it's published. A set of living, queryable references that answer the "where does this live and what touches it" question in a click instead of an afternoon.

And then the part that makes people raise an eyebrow: put it on the public internet, where anyone can open it.

That last decision was deliberate. A data dictionary locked in my own toolbox helps me. A data dictionary anyone can open helps the whole Ross ecosystem — and, not incidentally, it's the single most credible thing I can point a prospective client at. Anyone can say they know a system cold. It's harder to say it while linking to all 36,230 columns of it.

What I built

rossdata.dev is not one thing; it's a small family of tools over the same underlying model, each answering a different flavor of the same question.

• A data dictionary — every table, column, key, and relationship, searchable, with types, nullability, foreign keys, descriptions, valid-value lists, ER diagrams, field-level lineage, and one-click exports to CSV, JSON, and DDL. The reference manual Ross never shipped.
• A knowledge graph — the schema as an interactive, force-directed map: objects as nodes, relationships as edges, with path-finding between any two objects and grouping by module. This is the one that makes "how does sales connect to inventory connect to the ledger" a visible thing instead of a tribal legend.
• A facility explorer — the user-facing application menu, reversed into a catalog of 2,327 screens, reports, and programs, each cross-linked to the tables it actually reads and writes.
• A program explorer — 3,327 catalog programs cross-linked to their database references. Roughly 24,000 program-to-table links, so you can ask "what code touches this table" and get an answer instead of a shrug.
• A web services reference — 233 SOAP/Connect services with typed parameters and field mappings, for the integration work that always, eventually, needs them.
• A public REST/JSON API and an MCP server — because the most useful documentation isn't the kind a human reads once; it's the kind your systems, your dashboards, and your AI tools can query directly. The API is open and CORS-friendly. The MCP server lets an AI assistant answer schema questions from the real structure instead of confidently making one up. ("Ask Ross" — plain-English questions against the model — is the next piece.)

All told: 2,165 objects, 8,252 distinct column names, 195 audit-twin table pairs, and a lot of evenings.

Why standard-only

One guardrail matters enough to state plainly. rossdata.dev documents standard, vanilla Ross — the shape every install starts from. It contains no business data, no customer records, and no one's custom tables. I don't document a client's system in public, ever. Their instance is theirs; the public map is only the vanilla one everybody already shares.

What it's actually for

On the surface, rossdata.dev is a reference. Underneath, it's a demonstration of a way of working: take a system nobody documented, reconstruct its real structure, and turn that structure into something both people and machines can use. The Ross schema was the hardest available proof-of-concept — 1,840 tables is a lot of yaks to shave — but the method isn't Ross-specific.

Which is the actual offering. Your Ross install isn't vanilla; almost none are. Point the same toolchain at your schema and your application dictionary and you get a private data dictionary, knowledge graph, REST API, and MCP server built around your data — behind your login, not the public one. Same idea, aimed at the system you actually run.

And Ross is only the first patient. The same treatment — reconstruct the structure, make it legible, make it queryable — applies to EMF interfaces, integration flows, and other legacy systems whose documentation is a rumor. (A companion project pointed squarely at EMF process documentation is on the way.)

Tech stack

The standard Ross 8.0 schema (FIN + MAN) as the source of truth, modeled and cross-linked into a data dictionary, a facility and program catalog, and a web-services reference. A knowledge-graph layer for relationships and path-finding. A public REST/JSON API and an MCP server over the same model, so the documentation is available to code and to AI tools, not just to a browser.

Running Ross and tired of re-deriving the map every time? I've already drawn it — the standard one is at rossdata.dev, and I'll build you the private version of your own. Let's talk →

Next case study: CFB Automation →