How we work

A plain-English guide to what Protocol Wealth means when we say "substrate," "build-in-public," "ADR," and "structural over disciplinary."

Most software is built like a vendor

When a software company sells you a product, they're selling you features. A sortable list. An AI assistant. An integration with your custodian. The features can change. The contract can change at renewal. The price can change. And when the vendor decides to deprecate something, you have to migrate, or live with what they decide to keep building.

We've worked across enough of these systems to notice the pattern. The vendor's incentives drift over time. The features that mattered to you at signup become less important to the vendor as they scale. And the work you put into your firm becomes increasingly tied to choices the vendor made for reasons that have nothing to do with you.

A substrate works differently

A substrate is the layer underneath your application that enforces commitments regardless of what anyone tries to do on top of it.

The plain-English version: a substrate is the thing the rules run on, not the rules themselves.

Think of it as the difference between:

Policy: "We won't delete audit records for seven years." A rule that people promise to follow.
Substrate: A storage bucket that cannot delete records for seven years, even if our own CISO with full admin access runs the delete command.

Earlier today our own Terraform infrastructure pipeline tried to reduce the retention period on our audit-archive bucket by 1.75 days. The bucket refused. The Cloud Storage API returned an error: "Cannot reduce retention duration of a locked Retention Policy." Including for me, the CISO of the firm. That's a substrate working as designed.

The substrate doesn't trust the operator. It doesn't trust the engineer. It doesn't trust me. It enforces the commitment in code that runs whether or not anyone is paying attention.

Why this matters for protecting your data

Every software system makes promises about how it handles your data. Privacy policies are full of promises. Marketing pages are full of promises. Vendor questionnaires are full of promises.

The question we ask is this: what part of this promise is structural, and what part is policy?

Policy promise	Substrate equivalent
"We don't sell your data"	Database encryption with keys the vendor doesn't control
"We delete data on request"	Automated deletion pipeline with audit-log evidence
"Our staff can't access your account"	Cryptographic access controls that even staff can't bypass
"We retain records for 7 years per SEC rules"	A storage substrate that refuses to delete records for 7 years
"We don't send your data to third parties for AI training"	A contractual Zero Data Retention configuration enforced at the AI vendor's workspace level

Policy promises survive only as long as someone enforces them. Substrates enforce themselves.

If you're an RIA, a CCO, a treasury operator, a founder, or anyone who handles regulated data — the structural question matters more than the policy promise. Vendors who give you both are rare. Vendors who give you the substrate AND the auditable proof of it are even rarer.

That's what we built. That's what we publish.

Why we build in public

Most RIAs treat their software stack like a private asset. We treat ours like a substrate that the rest of the industry can inherit.

Here's the reasoning:

Compliance gravity makes lock-in painful. Every closed-source vendor an RIA uses creates a future migration cost when the vendor's incentives drift. Our partner firms shouldn't pay that cost. They should inherit a substrate they can run themselves.

The work one firm does benefits every firm. When we write the PII redaction toolkit once, every RIA that uses it gets the benefit. When we figure out the right shape for an immutable audit log, every RIA that adopts the pattern saves the months of engineering it would otherwise take.

Auditability is a feature for everyone. A regulator examining our books-and-records can read our code. A peer firm evaluating us can read our code. A client deciding whether to trust us with their financial life can read our code. Closed-source vendors can claim anything; open-source substrates carry their evidence with them.

The next 24 months compound visibly. Today we have one engineering substrate green-CI'd and four public surfaces. In 12 months we expect to have a published library of ADRs, a documented partner-firm licensing path, and a substrate any RIA can run in their own GCP project in an afternoon. That trajectory only works if it's visible.

The shape of what's emerging in advice

Bob Veres has been writing for three decades about what the financial advice profession is becoming. A few of the lines that have shaped how we think about Protocol Wealth — quoted from his recent writing:

The first major AI scandal in financial services will come when somebody engineers AI to give advice that leads back to the sale of products that are not in the best interests of their customers.

Advisors will become coaches with expertise — expertise in navigating the challenges we all face financially and otherwise. If a client is achieving his or her goals through the advice relationship, that will inspire unbreakable loyalty.

The performance statement of the future will have clients articulate what they want to happen in their lives, and the statement will list goals achieved and progress on the others. As goals are crossed off, new ones will be articulated.

Nobody will ever again refer to independent financial advisors as a "channel."

Visibly acting on the altruistic values of a profession will attract a higher number of clients.

This is the profession we're building Protocol Wealth toward. The substrate is the technical posture; the open source is the commercial posture; both serve the underlying conviction. A few things worth saying out loud about how that lands in practice:

Open source means no surprise vendor pressure. When the substrate is published under Apache 2.0 with a defensive-patent grant, no future investor can demand we pivot toward product sales to recoup acquisition cost. There's no acquisition price; there's no vendor. The community can fork. The community can contribute. The community can hold us accountable to the same patterns we hold the substrate to. Any advisor, any peer firm, any technically literate CCO can read what we wrote, run it themselves, and improve it — and we inherit those improvements alongside them.

Practitioner and builder. We use this substrate in our own SEC-registered RIA practice, every day. The same audit log captures our own client-facing AI sessions. The same WORM bucket holds our own books-and-records. If a substrate primitive doesn't work for us as the operator, we know within a week — not after a partner firm has spent six months adopting it. Practitioner-first development is the negative-feedback-loop that keeps the substrate honest.

Retainer and fee-for-service as the default conviction. AUM-only compensation creates structural pressure to over-recommend, to bundle, to sell. Retainer and fee-for-service align the advisor's economics with the client's goal, not with the size of the portfolio. AUM still makes sense in some growth-phase contexts where it's actually a less expensive option than a flat retainer — that's a structural call we'll make per-client situation, not an ideological one. The default tilts toward the compensation model that doesn't reward complexity for its own sake.

Treat people differently to treat them the same. Personalization without transparency is what AI vendors sell. Personalization with transparency is what an advisor builds — every client gets the depth of attention their situation actually needs, and the substrate captures who saw what when, so the personalization is auditable rather than opaque. The same standard for everyone, applied to the actual specifics of each person.

Profitability through community, not despite it. The conventional wisdom is open source bleeds margin. The substrate posture is the opposite: open primitives + licensed institutional logic + retainer-plus-profit-interest economics produces stable recurring revenue without the vendor lock-in dynamics that eventually drive clients to evaluate alternatives. No price-hike anxiety. No "oh by the way, we're sunsetting that feature" emails. The profitability comes from the community, not from the moat.

Willingness to be wrong, on the record. Substrate transparency includes the rough edges. The 4-day red on our infrastructure pipeline that resolved this morning is in our public commit history. The ADRs include the alternatives we rejected. The CHANGELOG includes the dependencies we haven't yet upgraded. The structural posture is to be auditable, not to be infallible — and that distinction matters more in advice than in software. We want to be challenged. We want the patterns tested. The community of operators who care about this is small enough that the only way to grow it is to make participating worthwhile.

The shape of what's emerging requires advisors who treat the substrate as inheritance, not as competitive moat. Building this for ourselves alone produces a moderately better RIA. Building it for the profession produces the infrastructure underneath what Bob calls the fulfillment society — where people are more personally aware of their purpose on earth, and the advisor's job is helping them get there.

This is what we mean when we say "build in public." It's not marketing. It's the substrate posture expressed as a commercial model, and it only works if the community is the moat.

What an ADR is

An ADR (Architecture Decision Record) is a short structured document — usually a single page — that captures one engineering decision and the reasoning behind it.

Each ADR has four sections:

Context — what problem forced the decision; what constraints applied
Decision — what we chose
Alternatives considered — what we rejected, and why
Consequences — what trade-offs and downstream effects this creates

We have one ADR for every material substrate decision. The ADR for our retention substrate explains why we chose 7 years vs. 5; why we lock the bucket at the platform level vs. via application code; why we use leap-year averaging in the retention math. The ADR for our PII tagging system explains why we tag at the schema level vs. classifying at runtime; why we vendor byte-equal copies across BFFs vs. importing from a shared library.

The ADRs are how an examiner, a partner firm, a peer advisor, or a journalist asks "why did you build it this way?" and gets a one-page answer. The count is visible at /live. The contents are available to qualified institutional reviewers under NDA; broader publication of high-level ADR summaries is planned over the next 90 days.

How we actually work

The cadence is simple:

A substrate decision gets written down as an ADR. No code change happens against a material design surface without an ADR. This forces explicit reasoning before implementation.

The code change ships as a pull request. Auto-merge enabled on green CI. The PR title and body are written as future readers will read them, not as private engineering shorthand. The 4-day-old red on our infrastructure pipeline that resolved this morning is in our public commit history; we don't hide the rough parts.

Every change emits an audit log row. Audit log writes are non-optional and structurally enforced. The row carries the actor, the principal chain (which advisor authorized which AI session that invoked which tool), the masked detail, the timestamp, the IP, the trace ID. Rows mirror to the WORM bucket for 7-year preservation.

Every client-facing communication routes through CCO sign-off. Marketing Rule §206(4)-1 review is a discipline we maintain on a batched cadence; the workflow is documented and the review queue is observable to our CCO.

The public surfaces get updated. Substrate changes land in the public substrate changelog. New ADR counts surface at /live. The cadence is what's visible to the outside world; the internal cadence is what produces it.

Three structural commitments you can verify today

We make three commitments structurally rather than as policy. Each is verifiable.

Client data never reaches an LLM training process

Substrate enforcement: Anthropic Zero Data Retention configured at a dedicated API workspace level. Anthropic's ZDR posture is contractually documented at the workspace level.

Adjacent substrate: a PII egress canary reimplemented byte-identical across three independent surfaces. Each canary fires fail-closed if a high-PII field would leave our control. The independent reimplementations mean the layers cannot share a single bug.

Audit records survive every kind of operator failure

Substrate enforcement: a Google Cloud Storage bucket-level retention lock on the audit-archive bucket. Locked 2026-05-02 at a retention period of 7 × 365.25 days (leap-year averaged). The lock is irreversible for the duration of the retention window.

Empirically validated 2026-05-19: our own Terraform infrastructure pipeline tried to reduce retention by 1.75 days. The bucket refused. The lock holds against the firm, not just against rogue actors.

AI never makes a fiduciary decision

Substrate enforcement: every AI-touched client deliverable routes through a human-in-the-loop review queue. The AI assists; the human signs off. The signoff is recorded in the audit log; the principal chain captures who authorized which AI session.

What this means for you

Three concrete actions you can take today:

Read the substrate. github.com/Protocol-Wealth/pwos-core is Apache 2.0; no NDA, no contact form. Read the audit-log primitives; read the PII redaction toolkit; decide whether you'd want this running in your firm.

Use the advisor's AI vendor audit checklist at /factsheets/advisor-ai-vendor-audit-checklist. 20 structural questions you can run against any AI-enabled vendor — yours to edit, republish, hand to clients.

Watch the changelog. /changelog is the public substrate changelog. If we ship something compliance-interesting, you see it. If we ship something rough, you see that too. Build-in-public both ways.

See the substrate in action. pwos.app/demo is our advisor IDE demo (auth-bypassed; OS-licensing prospects see this) and pwportal.app/demo is our client portal demo (auth-bypassed; retail prospects see this). The substrate concepts above all show up in the surfaces.

A note on what this is and isn't

This page describes our engineering substrate and how we work. It does not describe our investment philosophy, performance, or advisory services. Anyone evaluating Protocol Wealth as an investment adviser should read our Form ADV Part 2A at adviserinfo.sec.gov/firm/brochure/335298.

The Marketing Rule §206(4)-1 framework treats engineering substrate transparency as separable from advertising of advisory services. We hold to that separation deliberately. The substrate transparency surfaces (/security, /changelog, /factsheets, /live, /how-we-work) describe what we build. They do not describe how to invest with us.

If you want to discuss the substrate, schedule via calendly.com/d/ct3f-pwd-qgm/protocol-wealth-team-discovery. If you want to verify a specific claim on this page, email [email protected] for coordinated disclosure-style review or [email protected] for formal attestation requests.

How Protocol Wealth works — a plain-English guide

How a recommendation reaches a client