Sandstone Theory- What It Means to Be Set in Sandstone

Jarryd Strydom
June 9, 2026
There is a phrase we keep coming back to at Sandstone: set in stone.
It usually carries a negative connotation — rigid, immovable, resistant to change. But there is another way to read it. Something set in stone isn't fragile. It doesn't shift under pressure. It holds.
The legal departments we admire most have that quality. They are not rigid — they adapt constantly to new regulations, new business models, new commercial realities. But underneath all that adaptability, there is something solid. A foundation. A shared way of working that doesn't depend on any one person, any one tool, or any one institutional memory living inside someone's head.
That is what it means, to us, to be set in Sandstone. And over the past several months, through the Sandstone Theory series, we have been building out the case for what that foundation actually requires.
Theory #1: The Architecture Is the Problem
We start with a simple observation: legal departments were not designed — they accumulated.
Intake arrived through six different channels. Triage happened wherever someone noticed the message first. Context lived in a CLM, a shared drive, an email thread from eight months ago, and the memory of someone who left the company in January. Work got executed across a patchwork of tools that had never been designed to work together. Legal operations, in other words, had systems, but they were separate.
The result was a function that was deeply embedded in the business but structurally fragmented from within. And fragmentation has a cost — not just in efficiency, but in strategic positioning. A legal team perpetually reconstructing context is not in a position to get ahead of risk. It is too busy catching up to the last request.
The argument in Theory #1 was that AI-native is not an adjective you apply to existing infrastructure. It is a structural commitment. An AI-augmented team speeds up tasks against a broken architecture. An AI-native team has an entirely different architecture — one where intake is unified, triage is automated, context is attached to every matter, and workflow execution draws from living institutional knowledge rather than starting from scratch every time.
The four layers — intake, triage, context, work execution — have to work in harmony. When they do, legal is fast, consistent, and genuinely strategic. When they don't, talented people compensate for structural gaps, and the structural gaps win eventually.
Theory #2: Legal Should See Less Work
The goal of a well-run legal department is not to handle more work efficiently. It is to handle less work altogether.
Not because legal should abdicate responsibility — but because a surprising proportion of what reaches legal's inbox was never a legal question in the first place. Procedural queries. Policy lookups. Requests that fall cleanly within established guardrails but land in the legal queue because there is nowhere else to send them.
More than 40% of inbound Q&A volume across organizations using Sandstone consists of procedural questions: How should I handle this? What template do I use? Who needs to approve this? These are operational workflow questions incorrectly categorized as legal requests. They matter. They should be answered immediately, consistently, and with confidence. They should not be creating a backlog in legal's inbox.
The deeper point is about what happens when legal knowledge gets operationalized rather than just stored. Static policy documents go stale and get ignored. Manual answers to recurring questions don't scale. What scales is a living knowledge management system: one where approved answers compound over time, where guidance stays connected to the underlying policy, and where employees get contextual answers in the tools they already use.
This is how a General Counsel moves their team from gatekeeper to enabler — not by doing more with less, but by building systems that prevent unnecessary work from entering the queue in the first place. The filtering step itself becomes automated. Legal is reserved for matters that actually require legal judgment.
Theory #3: Context Is Relational, Not Documentary
The third piece reframed something that most legal technology has gotten wrong for years: the contract is not the center of the universe.
Contract lifecycle management systems were built around the premise that if you could manage contracts well — standardize workflows, centralize documents, control approvals — you had solved the operational problem. And they solved part of it. But the modern in-house legal function has grown far beyond the boundaries of any single agreement.
Behind every contract sits a much broader reality. Who is the counterparty, and what other entities are connected to them? Are there regulatory risks or prior incidents embedded in that relationship? Which employees, departments, and business functions are affected? How does this agreement interact with obligations that exist elsewhere — in procurement, compliance, finance, or HR?
That context does not live in the CLM. It lives across a CRM, a procurement system, an HR platform, a compliance record, and a pile of email threads. Legal teams piece it together manually, every time, for every matter. The result is fragmented visibility and reactive decision-making — not because lawyers aren't capable of strategic thinking, but because the systems they work with are optimized for retrieval rather than understanding.
The argument is that the next generation of legal infrastructure needs to do more than just store documents well. It needs to surface how things connect — relationships between counterparties, dependencies between obligations, interactions between commercial and regulatory risk. Because the most valuable legal insight rarely lives inside a single document. We call software that enables this Legal Relationship Management (LRM).
The most important legal insights rarely live inside any one document. They emerge from understanding how documents, entities, obligations, communications and regulations interact. We call this new category of software Legal Relationship Management (LRM).
What All Three Have in Common
Read together, these three pieces converge on a single diagnosis: legal departments are structurally under-equipped for the role they are increasingly being asked to play.
The architecture is fragmented, so context has to be reconstructed manually rather than surfaced automatically. The intake model is porous, so unnecessary work reaches legal before anyone has a chance to filter it. The data model is documentary, so relational intelligence — the kind that actually informs strategic decision-making — has to be assembled by hand from disconnected systems.
None of these are criticisms of the people doing the work. They are observations about the infrastructure underneath them. And they explain why so many talented legal teams still find themselves operating reactively, perpetually behind, perpetually justifying their existence to a business that wants a partner and keeps getting a bottleneck.
The fragmentation doesn't just slow legal down. It keeps legal from becoming what it could be.
What Being Set in Sandstone Actually Means
We chose the name Sandstone deliberately. Sandstone is a sedimentary rock — it forms over time, through the accumulation and compression of smaller elements into something structurally coherent. It is not the hardest material. But it is the foundation that holds.
A legal department set in Sandstone has that quality. Its institutional knowledge doesn't walk out the door when someone leaves, because it is captured in living playbooks rather than living in someone's head. Its intake doesn't collapse under volume, because routing logic is embedded in the system rather than dependent on a senior lawyer noticing the right Slack message. Its context doesn't have to be reconstructed from scratch on every matter because the relationships among people, companies, obligations, and prior decisions are visible in one place and connected by design.
This is not a vision for a distant future. It is the structural shift that the best legal departments are already beginning to make. And it compounds. Every matter handled on a solid foundation makes the foundation stronger. Every approved answer reduces future workload. Every relationship mapped makes the next one easier to navigate.
The teams that are building on this foundation now are the ones that will look back on this moment as the point when legal stopped being a cost center — a line item debated at budget time, a legal spend to be managed down — and started being a competitive advantage.
That is what it means to be set in Sandstone.