Scroll to open
Painless change management for core systems.
Splotch is the knowledge graph on top of your core systems. The graph provides the foundation for both humans and agents to trust when it's time to make a change.
Companies are held hostage
by their core systems.
0%
Of ERP implementations fail to meet their objectives. (100% of them take too long.)
The system is a black box.
The people who own it can't see the components, rules and automations that actually run the business, so every change starts blind.
That makes change slow, expensive and risky.
Teams spend more time confirming nothing will break than they do making the actual fix, limiting their ability to implement strategic business goals quickly and effectively.
And there's no reliable source of truth.
When a change ships, there is no permanent record of what happened or why. The next change starts with even more complexity and less context.
A platform to map and execute system change.
Splotch sits across your core systems, shows you how your system currently works, helps you identify where it doesn't and turns business goals into system changes with confidence, always keeping a record of what changed and why.
01
Discover
Our ingestion engine opens the black box, mapping your system visually, then indexing each component to documentation that anyone in the business can read (not just the people who built it).
02
Build
It creates a "diff" between what your system does now and what you want it to do, producing a change plan that's already scoped and sequenced to account for dependencies.
03
Govern
It gives you the record you never had, a full version history for the system itself, so you always know what changed, who approved it, and how to undo it.
See how it works.
A map that becomes the guardrails.
Splotch builds a durable, current map of your systems and the business logic layered on top of them, giving both humans and agents a trusted layer to act on.
Claude and GitHub weren't built to see the whole system.
Splotch works directly with Claude, GitHub, and whatever else is already in your stack. The knowledge graph fills in the relationships between components that those tools can't see on their own, then uses this analysis to make sure that your tools respect your system's schema and address every affected component of any changes they make. Inside the Splotch interface, you get a human-friendly graph that helps you follow along with what the AI is doing, so you can visualize, govern, and collaborate on everything that's changing.
Here's what's missing if you're working in your stack alone, and what changes once the knowledge graph sits underneath it.
| Capability | Your stack today | With Splotch |
|---|---|---|
| Business logic | Not visible | Mapped and current |
| Dependencies & blast radius | Not visible | Shown before anything changes |
| Edit configurations | Manually, risking messing things up | Splotch shares possible knock-on effects before making config changes |
| Create & edit customizations | Manually coded, or Claude Code by the system integrator | Directly in Splotch or via Claude Code, using our MCP to give full context before coding |
| Versioning | Nothing for configs; code maybe in GitHub, maybe not | Everything is versioned and can be rolled back without effort |
| Approvals for changes | No mechanism; maybe via email or meeting transcript | Logged in system, so it's clear who authorized which changes |
| Documentation of all customizations | None | Created automatically from code; always up to date |
Draft comparison, being verified with our design partners
See everything a change touches before it moves.
Without a knowledge graph, every change, whether an agent makes it or a person does, risks a downstream impact nobody saw coming. Splotch shows you the blast radius before anything moves. You see what the change touches directly, and everything further out that depends on it.
GitHub has always versioned your code. Splotch versions your business processes.
Splotch becomes that record, tracking every change, what it touched, who signed off, and why. That memory survives long after someone leaves the company, and it means your team can try things it would never have risked before, because every change can be traced, versioned, and rolled back if it doesn't work.
“
This is how ERPs should work.
Andrew Skidmore
4 Creeks