How we work

Most software is built like a vendor

When a software company sells you a product, they are usually selling features: a list, a dashboard, an integration with your custodian. Features can change. Contracts can change at renewal. Prices can change. When the vendor deprecates something, you have to migrate or live with what remains.

The pattern is familiar. Vendor incentives drift over time. The feature that mattered to you at signup may become less important as the vendor scales. The work you put into your firm becomes tied to choices someone else 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.

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.

Our own Terraform infrastructure pipeline once 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 does not rely on trust in the operator, the engineer, or me. It enforces the commitment 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 use your data for model training"	Zero Data Retention commitments and egress controls at the vendor/workspace level

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

If you are 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 evidence are rarer.

That is what we build and publish.

Why we build in public

Most RIAs treat their software stack like a private asset. We publish the parts that can be inspected, reused, or challenged.

Here's the reasoning:

Compliance gravity makes lock-in painful. Every closed-source vendor creates a future migration cost when incentives drift. Peer firms should be able to inspect and run core compliance primitives themselves.

The work one firm does can benefit every firm. When we write a PII redaction toolkit once, every RIA that uses it gets the benefit. When we define an immutable audit-log pattern, every firm that adopts it saves work.

Auditability is a feature for everyone. A regulator can read the code. A peer firm can read the code. A client can see how the claims are supported. Closed-source vendors can claim anything; open-source primitives carry evidence with them.

Progress should be visible. Public code, changelogs, ADRs, and demos make the work easier to verify and harder to overstate.

How that lands in practice

Open source reduces surprise vendor pressure. Code published under Apache 2.0 can be inspected, forked, and improved. A technically literate advisor, CCO, or peer firm can see what we built instead of relying only on a sales document.

We use the substrate ourselves. The same audit-log and retention patterns support our own SEC-registered RIA practice. If a primitive does not work in practice, we find out quickly because we operate it.

Compensation should not reward complexity for its own sake. Retainer and fee-for-service arrangements can align the advisor with the client's goals rather than the size of the portfolio. AUM can still be appropriate in some contexts; the right model depends on the client situation and the advisory agreement.

Different clients need different work, with the same standard of care. A concentrated founder, a family office, and a self-directed investor do not need the same workflow. The standard is the same: understand the facts, document the advice, and keep a record of who reviewed what.

Transparency includes rough edges. ADRs include rejected alternatives. Changelogs include unresolved work. Public commit history shows the fixes as well as the polished result. The goal is to be auditable, not infallible.

That is what we mean by build in public: publish the parts that matter, keep the record visible, and make the claims testable.

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 rather than 5, why we lock the bucket at the platform level rather than in application code, and 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 rather than classifying at runtime.

The ADRs are how an examiner, another RIA, 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 pwos.app/live. The contents are available to qualified institutional reviewers under NDA; we expect to publish high-level ADR summaries more broadly over time.

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. The PR title and body are written for future readers, not as private engineering shorthand. The rough parts stay in the record.

Every change emits an audit log row. Audit log writes are non-optional and structurally enforced. The row carries the actor, approval chain, masked detail, timestamp, IP, and trace ID. Rows mirror to the WORM bucket for 7-year preservation.

Client-facing marketing material routes through CCO review. Marketing Rule §206(4)-1 review is documented, batched, and visible to our CCO.

The public surfaces get updated. Substrate changes land in the public changelog. ADR counts surface at pwos.app/live. The internal cadence produces the external record.

Three structural commitments you can verify today

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

Client data is not used for model training

Substrate enforcement: Zero Data Retention configured at a dedicated API workspace level and documented contractually.

Adjacent substrate: a PII egress canary across independent surfaces. Each canary fails closed if a high-PII field would leave our control.

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.

Software never makes a fiduciary decision

Substrate enforcement: every client-facing deliverable that uses internal analysis or drafting tools routes through human review. The advisor signs off. The signoff is recorded in the audit log.

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 vendor audit checklist at /factsheets/advisor-ai-vendor-audit-checklist. Twenty structural questions you can run against any technology vendor — yours to edit, republish, or 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 workspace demo and pwportal.app/demo is our client portal demo.

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 security@protocolwealthllc.com for coordinated disclosure-style review or compliance@protocolwealthllc.com for formal attestation requests.

How Protocol Wealth works:

How a recommendation reaches a client