One shard per individual
A patient, an employee, a policyholder, a customer. Their records sit in a shard that belongs to them, reachable only by the roles you name, and removable the day the obligation ends.
Paddock · Shards
Knowledge you can govern
Knowledge you can govern
like records
Every Paddock shard is a complete index of its own. One per patient, per client, per matter, per year, per topic. You can permission a shard, freeze a shard, hand a shard back, or delete a shard, and show the log for every one.
The Principle
Your AI should not memorise your data
A fact that lives inside a model's weights cannot be deleted, cannot be dated, and cannot be permissioned. It sits there for every user, forever, and the only fix is retraining. That is a governance dead end, and most AI stacks are walking straight into it.
Paddock is built on the opposite principle: the model stays stateless, and your facts live in shards.
The model brings the reasoning. The shards bring the knowledge. Because the two never mix, every fact in the system keeps an address: which shard it sits in, who can reach that shard, which dates it covers, and when it must go.
That single design decision turns the hardest questions in AI governance into ordinary records management. The right to be forgotten stops being a research problem and becomes a delete operation. Need-to-know stops being a prompt instruction and becomes an access rule the query physically cannot cross.
A filter can leak. A separate index cannot return what it does not contain.
| Fact in the weights | Fact in a shard | |
|---|---|---|
| Delete it | Retrain the model | one operation |
| Permission it | Cannot | per-shard rule |
| Date it | Cannot | as-of query |
| Show it is gone | Cannot | erasure log |
The Mechanism
Every shard is its own index
Not a tag. Not a filter over one big store. Each shard is a self-contained index with its own files, its own search, and its own address. Draw them around whatever your obligations are drawn around.
One shard per client or matter
A legal matter, a client engagement, a deal room, a project. The shard opens when the work opens and follows the engagement's lifecycle, not your database's.
One shard per domain
Product lines, sites, fleets, disciplines. A question is routed to the shards that hold the answer, so a query about one line of business is answered from that line's evidence alone.
One shard per period
Quarters, revisions, policy years. Ask as of a date and Paddock answers from what was true then. Freeze a period and it becomes tamper-evident history. Retire a period and it is deleted on schedule.
One shard set per customer
Serve many customers or business units from one deployment with hard walls between them. Nobody's query reaches anybody else's shard, because there is no shared index to reach through.
Fences within fences
A tenant holds topics, a topic holds periods, a period holds people. Shards nest, so the structure of your index can mirror the structure of your obligations exactly.
Lifecycle
Four operations your auditor will love
Because a shard is a real, separate thing, it supports the operations regulators actually ask about. Each one is a single action with a log entry, not a project.
01
Permission it
Access is granted shard by shard, to roles you define. A clinician sees their care team's patients. A deal team sees its own data room. The wall is structural: a query from outside the grant has no index to search, so there is nothing to leak.
02
Freeze it
Lock a shard at a moment that matters: the day the policy renewed, the day the report shipped, the day the incident occurred. Frozen shards answer as-of questions and are tamper-evident, which is exactly what a dispute, a legal hold, or an investigation needs.
03
Hand it back
A shard is portable. When a client leaves, give them their index, complete, and keep nothing. When a contract requires data to come home at the end, the end is an export, not an argument.
04
Delete it
A patient withdraws consent. An employee departs. A retention clock runs out. Remove the shard and everything Paddock holds on that person, documents, index, and every derived structure, is deleted in one logged operation. There is no shared store for fragments to hide in. Copies in your source systems and backups follow your own retention policy; Paddock's share of the obligation is done, and the log shows when.
An erasure request spans every system you run. Paddock's part stops being the hard part: one logged operation an auditor can check.
Where This Lands
Draw the shard around the obligation
Every regulated industry already has a unit it must isolate, retain, or destroy. Make that unit the shard, and the AI inherits the compliance model you already run.
A shard per patient
Care teams query the patients in their grant and nobody else's, which is minimum-necessary access made structural. Consent withdrawn means the shard is deleted, and the deletion is a log line you can produce.
A shard per matter
Ethical walls by construction: the team on one side of a conflict cannot query the other side's matter, because the index is not reachable from their role. Matter closes, shard is archived or destroyed per the retention schedule.
A shard per deal, a wall per desk
Material non-public information stays inside the deal shard. Research and trading query different shards of the same firm's knowledge, and the separation between them is inspectable rather than asserted.
A shard per compartment
Need-to-know maps one-to-one onto shard grants. A query carries a clearance, and the shards it can search are exactly the compartments that clearance names. Air-gapped, on your hardware, nothing outbound.
A shard per revision
"What did the manual require on the day of the incident?" is answered from the frozen shard for that date. Policy wordings, maintenance revisions, and effectivity by airframe stay queryable exactly as they stood.
A shard set per client
One deployment serves every client with hard walls between them. Offboarding is clean: hand the client their shards and delete your copy on the day the contract ends.
A shard per deal room
The clean team queries the deal shard through the deal. If it closes, the shard merges into the acquirer's estate. If it collapses, the shard is destroyed, and with it every answer it ever grounded.
A shard per employee
Personnel files, reviews, and grievance records live per person. An investigation is scoped to its shard. A departure triggers erasure on schedule, and the index itself enforces the schedule.
A shard per licence
A licensed dataset sits in its own shard, and the AI can use it while the licence runs. When the licence expires the shard is removed: no new answer draws on it, and the removal date is on the record.
No Trade-Off
Governance that costs you no accuracy
The obvious worry: split the library into shards and surely the answers get worse. We measured it, because that is how we work.
On our benchmarks, sharded retrieval matches the whole-library baseline.
A question is routed to the shards that bear on it, and the answers that come back are as good as if the entire library had been one index. Isolation between shards held in the same tests: a query granted one shard returned nothing from any other, every time. Separation is not a mode, it is the architecture.
So the choice between an AI you can govern and an AI that answers well is not a choice. You draw the fences your obligations require, and the answer quality your teams rely on carries through.
| Answer quality, sharded vs one index | matched, measured |
|---|---|
| Cross-shard leakage under test | zero |
| Routing | A query only touches the shards that matter |
| Scale behaviour | Adding a shard never disturbs the others |
These are measurements, not positioning. Ask and we will walk you through them, then rerun the same tests on your data before you commit.
Run It Your Way
On your metal, in your cloud, or on ours
The shard model is identical in every deployment. What changes is who racks the hardware.
Air-gapped appliance
Everything on hardware you control, down to a single Mac appliance. Zero outbound traffic. The shape regulated and classified environments need, and the one we specialise in.
Your VPC, as code
Containers your platform team drops into its own stack as infrastructure as code. Your cloud account, your region, your keys. Shards live on volumes you own and can point at the residency the rules require.
Managed, still fenced
We run it, you use it. Every tenant is its own shard set with the same hard walls, the same per-shard permissions, and the same one-operation erasure. Start here in days, move on-premise later without changing the model.
Start on SaaS, land on your own hardware, or mix the two. Shards are portable, so the decision is reversible.
We Use It Daily
Our own research runs on it
Paddock's first production tenant was us. Our research programme keeps years of experiments, findings, and literature in a sharded Paddock library that our team and our AI agents query before any new work begins.
Shards
Draw the fences your obligations require
Tell us what you must isolate, retain, or destroy. We will map it onto shards and stand up a governed answer engine on infrastructure that suits you.