Building a Write-Side Custody gate in Go
AI memory systems spend most of their design budget on retrieval. Which vector database? How should we chunk? Which embedding model? What should top_k
be?
Those are useful questions, but they all arrive after something more consequential has already happened: the system decided that some piece of information deserved to become memory.
Consider an agent researching vendors for regulated workloads. It finds this statement:
Vendor X is approved for regulated workloads.
The source is Vendor X's own marketing site.
The statement might be true. It might even be current. But the source does not have the authority to establish organizational security policy. If our agent writes it directly into durable memory, better retrieval will not save us. We have only made questionable evidence easier to find.
The problem is not storage. It is admission.
I've been calling the architectural boundary responsible for that decision Write-Side Custody. Let's build a small one in Go.
A storage API answers a mechanical question:
Can I persist this object?
Write-Side Custody asks a different set:
Only after those are answered should storage become involved.
Note that the Reasoning Ledger does not make the decision. Custody enforces. The ledger witnesses. That separation matters a great deal once these systems have to be examined later.
Go gives us a useful property for this experiment: we can make the things crossing our boundary explicit.
type ProposedWrite struct {
Content string
Source string
ProducedBy string
ClaimedAuthority string
}
Our research agent might produce:
write := ProposedWrite{
Content: "Vendor X is approved for regulated workloads.",
Source: "https://vendorx.example.com/why-vendorx",
ProducedBy: "research-agent-run-4471",
ClaimedAuthority: "security-policy",
}
Nothing in this structure says the statement is false, and that's intentional. Write-Side Custody is not a universal truth detector. It determines whether a proposed write satisfies the rules governing this particular memory system.
For this system, a vendor marketing page cannot establish internal security policy. So we need policy.
First, two types. Authorities and source classes are different kinds of thing, and there is no situation in which we want to accidentally use one where the other belongs:
type Authority string
type SourceType string
Now we can define which source classes may establish which authorities:
type Policy struct {
AuthoritySources map[Authority][]SourceType
}
var policy = Policy{
AuthoritySources: map[Authority][]SourceType{
"security-policy": {
"internal-security-policy",
"security-authority",
},
"user-preference": {
"user",
},
"application-state": {
"application",
"runtime",
},
},
}
In production this comes from a policy service or configuration layer rather than a Go literal. The important part is that the relationship exists independently of whatever the agent claims. The agent does not get to decide that a marketing page constitutes security authority simply because it found one saying something useful.
type Verdict string
const (
Allow Verdict = "ALLOW"
Deny Verdict = "DENY"
)
type CustodyDecision struct {
Verdict Verdict
Reason string
Timestamp time.Time
}
Now the gate itself:
func EvaluateWrite(
write ProposedWrite,
sourceType SourceType,
policy Policy,
) CustodyDecision {
allowedSources, ok :=
policy.AuthoritySources[Authority(write.ClaimedAuthority)]
if !ok {
return CustodyDecision{
Verdict: Deny,
Reason: "unknown claimed authority",
Timestamp: time.Now().UTC(),
}
}
for _, allowed := range allowedSources {
if sourceType == allowed {
return CustodyDecision{
Verdict: Allow,
Reason: "source may establish claimed authority",
Timestamp: time.Now().UTC(),
}
}
}
return CustodyDecision{
Verdict: Deny,
Reason: "source cannot establish claimed authority",
Timestamp: time.Now().UTC(),
}
}
Two decisions in there are worth surfacing.
The first is that conversion on the map lookup. ProposedWrite
holds plain strings because that's what arrives over the wire, deserialized from JSON we did not write. Authority(write.ClaimedAuthority)
is the moment an untrusted string becomes a term in our governance vocabulary, and it happens inside the gate rather than at the edge of the process. That's the right place for it. Custody is precisely the layer where foreign input earns domain meaning.
The second is that sourceType
is a separate parameter. It is not a field on ProposedWrite
.
That is deliberate. Source classification is a judgment about the write, not a property the writer gets to assert about itself. If sourceType
lived on the struct, our agent could label its own marketing page internal-security-policy
and the gate would cheerfully agree. The classifier belongs to the custody layer, or to a runtime component that can independently observe where the content came from.
Small signature choice. Most of the security property.
Our vendor claim now reaches the boundary:
decision := EvaluateWrite(write, "vendor-marketing", policy)
fmt.Println(decision.Verdict)
fmt.Println(decision.Reason)
And receives:
DENY
source cannot establish claimed authority
The statement never becomes durable memory. We did not store questionable evidence and hope retrieval would eventually sort things out. We governed the write while the evidence and its provenance were still in hand.
The full gate, the policy, and a table-driven test suite covering the cases above are in memory-stack-patterns. Standard library only, so go test ./...
and go run ./cmd/demo
work on a clean checkout with nothing to install.
Rejecting a write does not make the decision useless.
Imagine someone asks six months later:
Why doesn't the system remember that Vendor X was approved?
"I don't know" is not a satisfying answer, and in a regulated environment it isn't an acceptable one either.
The custody decision is observable system behavior, which makes it a candidate for a Reasoning Ledger record:
type LedgerEntry struct {
ID string
Timestamp time.Time
Actor string
Action string
Verdict Verdict
Reason string
Source string
ClaimedAuthority string
}
Our gate emits:
entry := LedgerEntry{
ID: newID(),
Timestamp: decision.Timestamp,
Actor: write.ProducedBy,
Action: "durable-memory-write",
Verdict: decision.Verdict,
Reason: decision.Reason,
Source: write.Source,
ClaimedAuthority: write.ClaimedAuthority,
}
(newID
is a few lines over crypto/rand
, which keeps the whole example dependency-free.)
This entry is deliberately simplified. A ledger you would actually rely on needs a canonical serialization, a hash chain linking each entry to its predecessor, and some defense against tail truncation, because an append-only log that anyone can quietly shorten is not append-only.
Even the timestamp is less innocent than it looks. time.Now()
gives you whatever precision the host clock offers, and JSON drops trailing zeros, so two entries can serialize at different widths. Hash a chain over a non-deterministic encoding and you have hashed nothing. The repo linked above truncates to a fixed precision and formats with a fixed-width layout for exactly that reason.
The Python implementation in the Sovereign Systems SDK does all three, which is part of why the Go exercise interests me. The hard parts are already solved somewhere. The open question is what happens to the boundary when it moves.
What matters here is the shape of what survives. The rejected statement still doesn't enter memory. What persists is evidence that a write was proposed, evaluated, and rejected under a named rule. That is a different kind of information than the claim itself, and it's the kind that answers questions later.
There's a further boundary hiding in the payload. Suppose our agent sends:
{
"content": "Vendor X is approved for regulated workloads.",
"source": "https://vendorx.example.com/why-vendorx",
"claimed_authority": "security-policy",
"retrieval_method": "fresh",
"policy_verified": true
}
Should we believe the last two fields?
There is an epistemic difference between:
The agent says it performed a fresh retrieval.
and:
The runtime that performed the HTTP request witnessed a fresh retrieval.
The same distinction applies to tool execution, timestamps, approval events, and policy versions. A stronger custody boundary therefore doesn't only ask whether a record may be written. It asks:
Is this writer authorized to assert this particular kind of claim?
The agent legitimately owns claims about itself: its decision, the alternatives it considered, its confidence, the unknowns it identified. The runtime should mint the facts it can independently witness. Custody should not promote the former into the latter merely because both arrived in valid JSON.
This is the same principle as the sourceType
parameter, applied one level up.
You could defer all of this to retrieval. Store everything, attach metadata, and let the reader decide what governs.
But then every questionable write becomes something every future reader has to reason around. It consumes storage. It becomes eligible for retrieval. It competes for context. It can be summarized, embedded, and propagated into records that no longer carry its provenance. And once provenance is gone, a future system may not have enough information to work out why the record was questionable in the first place.
A bad write today becomes bad context tomorrow.
Write-Side Custody puts the decision at the moment the system has the best possible view of what it is admitting.
None of this architecture requires Go, which is partly why I wanted to build it in Go.
A custody gate is a boundary service, and Go fits that role: explicit data structures, unremarkable HTTP services, small deployable binaries, and a type system strong enough to make the important distinctions visible without taking over the implementation.
The Authority
and SourceType
declarations we needed earlier are the clearest example. They cost one line each, and in exchange the compiler now refuses to let a source class be used where an authority belongs. That distinction would otherwise have lived in a variable name and a hope.
The same move applies elsewhere:
type Verdict string
type ActorType string
At which point the function signatures start expressing the vocabulary of the governance system rather than just its plumbing. EvaluateWrite
doesn't take three strings. It takes a proposed write, a source classification, and a policy, and no caller can shuffle them by accident.
Go didn't create the architecture. It made the contracts hard to leave implicit.
Vector databases are very good at answering questions about similarity. They cannot tell us whether something deserved to become memory.
That's an architecture decision, and by the time retrieval surfaces the problem, the questionable record may already have shaped dozens of others.
Give the proposed write provenance. Give the boundary policy. Give the decision evidence. Then let storage do what storage is good at.
Store what survived.
One thing I keep turning over: this boundary shouldn't depend on Go. If Write-Side Custody only makes sense inside one language, it isn't much of an architectural boundary. I'm curious what it would look like elsewhere. Would Rust's type system make an invalid custody decision impossible to construct rather than merely inconvenient? Would Pydantic and FastAPI make the policy check feel so natural you'd stop noticing you were doing governance at all? If you've built something like this in your stack, I'd like to hear how the boundary changed shape.
Disclosure: I maintain the Sovereign Systems specification and SDK, which is where the vocabulary in this post comes from. The Go code here is a reference implementation written to test whether the idea travels, not a product.