Open Source
Verify, don't trust.
Protocol Wealth is an investment adviser registered with the SEC (the Securities and Exchange Commission, the U.S. federal regulator that licenses and oversees investment advisers). We publish the source code for the tools we build so clients, auditors, and other advisers can read it — and so independent advisers can build on the same rails without licensing fees.
For what this means in plain English — why a fiduciary RIA treats its software as a substrate the profession can inherit — see /how-we-work. For the RIA agent substrate, see /agents. For the canonical strategy document — hubs, licenses, AI-governance posture, and what stays private — see /opensource-strategy.
General is the plain-English version. Detailed has file paths, regulatory context, and the verification checklist.
Why this page exists
Why a CFP wants you to be able to read this
There is a question we get from sophisticated clients more often than you might expect. They have heard us talk about open source. They have seen the GitHub link in our footer. They want to know what it actually means — and what it would tell them if they ever clicked it.
Open source — code published with a license that lets anyone read it and use it for their own purposes — is not an act of generosity. It is how new professional standards have always emerged. Doctors, accountants, and lawyers built their professions on shared, inspectable bodies of knowledge. The advisor profession is in the early phase of doing the same for AI-augmented practice, and we believe the foundation should be in the open.
The reasons
Why we publish the code
We publish because financial services that affect people's money should be inspectable. We publish because regulators should be able to see how AI handles client data. We publish because clients should be able to verify what we built. We publish because other independent firms benefit when the foundation is shared, instead of every firm rebuilding the same compliance scaffolding from scratch.
What we publish is the foundation. What we don't publish is the judgment we apply to it. Our specific advice to specific clients is not in the public repos. Our firm-internal client data is not in the public repos. Our deployment configs, signing keys, and vendor credentials are not in the public repos. We compete on judgment, accountability, and relationships — not on whether our PII scanner is more secret than the firm down the street.
The map
What's open and what's not
Four repositories are public on GitHub at github.com/Protocol-Wealth:
pwos-core
The TypeScript foundation. Keeps AI use safe and auditable for an advisory firm — scrubs personal information, records every AI action to an audit trail, gates which tools an AI is allowed to call.
Star on GitHubnexus-core
The Python financial-analysis engine. Classifies the market environment, scores assets against the framework, and defines the tools an AI assistant uses to look at market data.
Star on GitHubpw-learnai
Notes, not code. How we think about applied AI for fiduciary practices and what we have learned using AI assistants for development.
Star on GitHubpwplan-core
The open planning interface. A regime-adaptive financial-planning UI that renders the nexus-core planning tools, with a PII-free-by-construction contract — no client identifiers ever reach it.
Star on GitHubThree categories stay private. Client data, period. Specific advice to specific clients. Firm-internal infrastructure — deployment configurations, signing keys, vendor credentials, anything that would compromise the firm or its clients if it were public.
If you want to verify a claim we make on this website, the public repos are where you check it. If you want the specific recipe we applied to your situation, that is not on GitHub — it is in the advisory agreement, the IPS, and the work we do with you directly.
How to look
How to read it without running it
You do not need to install anything. GitHub renders all of it in your browser. Three places to start.
Start with the README
Every repo has one. The README describes what the project does and how the parts fit together. Read it like you would the introduction of a book — it is the welcome mat, written for someone seeing the project for the first time.
Compare against the description
Our framework writeup at /framework and the systematic-investing pages at /investing describe what we say the systems do. The open repos are where you check whether the code matches the description.
Use your own eyes
Every claim on this site that touches code is verifiable. If you find something that does not match the description, tell us. We will either fix the code, fix the description, or explain why the apparent mismatch is intentional.
Reality Check
What this is, and what it is not
The hubs are early. Both
pwos-core and
nexus-core are still being
built out — what is in the public repos today is a deliberate
selection, not a one-to-one mirror of what runs internally.
The public mirror is not the runtime. Some security-sensitive code stays private. Auth flows, signing services, and tenant-provisioning logic are kept in private repos even when their generic patterns appear publicly. Assume the public version is the sanitized one.
No support contract is implied. Apache 2.0 and MIT both ship the code "as is." Using any of these projects in your own practice is your decision, made with your own qualified legal and compliance counsel. This is not a turnkey product. It is not investment advice. It is not a recommendation that any other firm adopt these patterns.
It is the foundation we built for our own practice, published in the open so others can learn from it, contribute to it, or build differently. Whether any of it fits your practice is your decision.
Why this page exists
Why we publish source code
Open source isn't an act of generosity — it's how new professional standards have always emerged. Doctors, accountants, and lawyers built their professions on shared, inspectable bodies of knowledge. The advisor profession is in the early phase of doing the same for AI-augmented practice, and we believe the foundation should be in the open.
This follows from how we read the present moment. Our Operating Thesis explains why we believe shared compliance scaffolding becomes the standardization layer for AI-augmented fiduciary practice — and why the firms that contribute to it are the ones that adapt up.
Why an investment advisory firm publishes source code
Financial services that affect people's money should be inspectable, the same way a physician's clinical guidelines or a CPA's tax code interpretation are. Black-box technology in regulated finance is a posture, not a necessity. SEC and FINRA examiners should be able to see how AI handles client data. Advisors should be able to see what their tools actually do. Our clients should be able to verify what we built.
Who benefits
Other independent advisory firms can read, deploy, and contribute to the foundation we've built, instead of every firm rebuilding the same compliance scaffolding from scratch. The firms that contribute back make the foundation stronger for everyone — including their own clients. Our own clients benefit because regulators, partners, and prospective advisors can see exactly what we built and how it works.
What about our competitive edge
The foundation is shared. Our judgment, our specific advice to specific clients, our investment thinking, and our firm-internal data are not. We compete on the things that actually distinguish a fiduciary practice — relationships, judgment, accountability — not on whether we have a better-secret PII scanner than the firm down the street.
For other firms
Why we expect other independent firms to use this
Most independent advisory firms face the same compliance scaffolding work: scrubbing client information out of anything an AI sees, recording every AI action to an audit trail, gating which tools an AI is allowed to call, generating client-ready documents with the right disclaimers. Building this from scratch at every firm is duplicative work that doesn't differentiate any of us.
Sharing the foundation lets each firm spend its limited engineering and compliance budget on what actually distinguishes its practice. The firms that adopt and contribute will benefit more than the firms that watch from the sidelines, the same way merchant houses that adopted Pacioli's double-entry bookkeeping in the 1490s gained an edge over the houses that stayed with abacus-and-Roman-numeral arithmetic.
In a regulated context
Why we publish the code
A fiduciary's claims are only as strong as what someone can check
An investment adviser is a fiduciary. We publish the source code for the systems that run our practice so clients and their counsel can read how PII (Personally Identifiable Information — names, account numbers, anything that can identify a specific person) is handled, how audit trails are written, and how the analysis they're shown was produced. "Trust us" is not an answer we want to rely on.
A regulated alternative to shadow AI
Many independent RIAs (Registered Investment Advisers — fee-only firms that owe a fiduciary duty to their clients) are adopting AI tools faster than their compliance programs can establish monitoring or audit practices for them. That gap is sometimes called shadow AI: tools in production that no compliance program can see. Publishing the source for the pieces an adviser can self-host is intended to offer an auditable alternative — so the choice isn't "use an unmonitored consumer tool or build everything from scratch."
Systems connector, not a replacement
The mental model is what MuleSoft was to enterprise APIs (Application Programming Interfaces — the contracts that let one piece of software talk to another): a connector layer that absorbs the messy work of moving data between systems. For a small fiduciary practice in 2026, that messy work is PII handling, audit logging, vendor adapters, and AI tool registration — table stakes that no advisor should have to build alone, but that every advisor needs to clear before they can ship a niche feature.
Capabilities, not products. A starting point, not an end point. Independent advisers can adopt as much or as little as they want — time, development effort, security review, and audit controls all come transparent and free to build on top of. We don't control the cost, the license, or the roadmap on you after you adopt.
Recognize what already exists
The hubs are about wiring established and novel projects together for a regulated
context, not displacing them. Most of what an advisory firm needs already exists in
open source somewhere; the gap is the regulated assembly. The defensive patent
grant in each hub's PATENTS file — and
Protocol Wealth LLC's own membership in the OIN (Open Invention Network, a
non-aggression patent pool that protects open-source software from patent
attacks) — exists to keep these approaches usable by everyone, not to give us
leverage to take them back later.
And what we keep closed, on purpose
Open source is the credibility surface; the closed parts are the ones where opening them would create harm we can't undo (client data, secrets, vendor contracts). We try to be honest about both — see the inventory below.
Inventory
What's open, what's not
We use a hub model: reusable PW-authored components are released into two Apache 2.0 absorption hubs (one Python, one TypeScript), an open planning UI, plus a small reference repository. Firm-specific code, secrets, and client data stay private.
Open repositories
| Repo | License | What it is |
|---|---|---|
| pwos-core Star | Apache 2.0 | TypeScript hub for compliance-aware AI tooling: PII redaction, audit log, MCP (Model Context Protocol — an open standard from Anthropic that lets AI assistants call external tools and data sources) tool registry, document generation, and planning UI components. |
| nexus-core Star | Apache 2.0 | Python hub for regime-adaptive financial analysis: scoring framework, regime detection, MCP tool definitions, and data adapters. |
| pw-learnai Star | MIT | Notes and reference material on applied AI strategy and AI-assisted coding for advisors; reading material, not a runnable system. |
| pwplan-core Star | Apache 2.0 | Regime-adaptive financial-planning UI (React + Vite) that renders the nexus-core planning tools, with a PII-free-by-construction contract — no client identifiers ever reach it. |
pw-redact,
pw-router) have been archived; their functionality
was absorbed into pwos-core.
These boundaries protect the people whose data we hold; the credibility work happens in what we publish, not in what we don't.
What we keep private (and why)
| Category | Why |
|---|---|
| Client data | Non-public personal information for clients and prospects; never published under any circumstance. Stored in tenant-isolated databases under SEC Regulation S-P. |
| Secrets and credentials | API keys, OAuth secrets, signing keys, Workload Identity bindings; rotated on a schedule, kept in Google Secret Manager, never in any repository. |
| Firm-specific runtime services | The deployed services that run our practice (advisor surface, client portal, backend spine, onchain indexer, strategies engine, infrastructure-as-code) are private; they contain firm-specific business logic, vendor wiring, and references to client data. Reusable parts get released into the hubs. |
| Vendor contracts and integrations | We publish what vendor contracts let us publish. The adapters that wrap third-party APIs (custodial, KYC, sanctions, blockchain data) — they stay in private repos because those contracts often forbid redistribution. |
| Internal compliance documents | Firm-specific policies, supervisory procedures, and analytical thresholds (e.g., specific signal weightings) are governed material; available to regulators and to clients on reasonable request, not to the general public. |
Navigate
How to read the code
You don't need to run the code to read it; GitHub renders everything in your browser. Start with Overview if you want the plain-English tour, switch to Detailed View if you want exact file paths.
Start with the README
Every repo has a README.md at the top. It's
the welcome mat: what the project does, what's in it, and how the parts fit
together. If a repo also has a CLAUDE.md,
that's a guided tour written for AI assistants — it works just as well for human
readers and tends to be the most up-to-date map of the codebase.
What's inside pwos-core (TypeScript)
The pieces that keep AI use safe and auditable for an advisory firm: scrubbing
personal information out of anything an AI sees, recording every AI action to an
append-only log, registering the tools an AI is allowed to call, and generating
client-ready documents. Read the README first, then browse the
packages/ folder.
What's inside nexus-core (Python)
The financial-analysis side: figuring out what kind of market environment we're in,
scoring assets against the framework, defining the tools an AI assistant can use
to look at market data, and the adapters that pull that data in. Browse
src/ after the README.
What's inside pw-learnai
Notes, not code. How we think about applied AI for fiduciary practices and what we've learned using AI assistants for development. Read in any order.
What's inside pwplan-core
The open planning interface: a regime-adaptive financial-planning UI that renders
the nexus-core planning tools. It carries a PII-free-by-construction contract — no
client identifiers ever reach it — so the screens are inspectable without touching
anyone's data. Browse src/ after the README.
If you want to compare against what we claim
Our framework writeup at /framework, the systematic-investing pages at /investing, and the security posture at /security describe what the systems do; the open repos are where you can check whether the code matches the description.
Verify
How to verify our claims
License + attribution
Each repo has a LICENSE file at the root;
hubs additionally carry NOTICE,
PATENTS, and
THIRD_PARTY_LICENSES.md per Apache 2.0
attribution requirements.
CI status
CI (Continuous Integration — automated checks that run on every code change) runs lint, typecheck, and tests on every pull request via GitHub Actions; statuses are visible on each repo's Actions tab. Public CI badges are planned but not yet wired into the READMEs.
Security disclosure
SECURITY.md in each hub points to
[email protected];
/.well-known/security.txt
follows RFC 9116 (the internet standard that defines how a site advertises a
security contact).
Signed releases and SBOMs
Planned, not yet shipped. When releases begin, they'll be signed with Sigstore and ship a CycloneDX SBOM (Software Bill of Materials — a machine-readable inventory of every component a piece of software is built from). This page will be updated when those are real.
Defensive patent + Open Invention Network
Protocol Wealth has filed three USPTO (United States Patent and Trademark Office)
provisional patent applications with defensive intent — pwos-core
#64/034,215, nexus-core
#64/034,229, and pwplan-core
#64/082,241 — meaning we've legally committed
never to sue another firm for using the patterns these applications disclose. The
applications exist to prevent someone else from patenting the same patterns and
restricting their use.
Other firms can read our code, deploy it, build on it, and improve it without paying
us a licensing fee. (Provisional applications are pending placeholders, not issued
patents.) The PATENTS file in each hub carries
the same non-aggression terms. Protocol Wealth LLC is a signed Open Invention Network
(OIN) 2.0 Licensee in its own name; see our patent
disclosure page for the filings and drawings.
Reality Check
Limits and caveats
The hubs are early. Both
pwos-core and
nexus-core currently hold scaffolding and
documentation; component releases land progressively. Don't read public size as a
proxy for what we run internally.
The public mirror is not the runtime. Code released into the hubs is a deliberate selection from private repositories, not a one-to-one mirror of production. We don't auto-publish private commits.
Security-sensitive code may stay private. Auth flows, signing services, and tenant-provisioning logic are kept in private repos even when their generic patterns appear in the hubs; assume the public version is the sanitized one.
Pull requests welcome, external maintainers not yet sought. We accept issues and patches; we're not running a community-governed project in v1. DCO sign-off (Developer Certificate of Origin — a one-line attestation that you have the right to submit your patch) is required on contributions.
No support contract is implied. Apache 2.0 / MIT both ship "as is"; using these projects in your own practice is your decision, not a recommendation, and is not investment advice. Adopt at your own discretion and consult your own qualified legal and compliance counsel before relying on any of these projects in production.
Forward-looking items. References on this page to "planned" capabilities (signed releases, SBOMs, public CI badges) reflect current intent. They are not commitments, and timelines may change. This page is updated as those items ship.
What this is not. This is not a turnkey product for advisory firms to deploy without engineering and compliance review. It is not investment advice. It is not a recommendation that any other firm adopt these patterns. It is the foundation we've built for our own practice, published in the open so others can learn from it, contribute to it, or build differently. Whether any of it fits your practice is your decision, made with your own qualified counsel.