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 regulators can read it and check that it does what we say. The code is open source under permissive licenses (Apache 2.0; MIT for the pw-learnai notes) — free for anyone to use.
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. Code that anyone can read is code anyone can check — which is the whole point of "verify, don't trust."
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
The public surface has two tiers. The -corefamily is infrastructure for regulated AI practice; the supporting repositories are reference utilities, learning material, or archived ancestors of the current core packages. We link each repository directly because the GitHub organization view may not show every public repo to logged-out visitors.
The -core family
pwos-core
The governance and safety substrate (TypeScript). 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.
Open repositorynexus-core
The capability and tool layer (Python). Classifies the market environment, scores assets against the framework, and defines the tools an AI assistant uses to look at market data.
Open repositorypwplan-core
Open-source, regime-adaptive financial planning UI — PII-free by construction. The third member of the -core family.
Supporting public repos
pw-learnai
An open library of applied AI strategy and AI-assisted coding modules. No certificate, no paywall, no funnel.
Open repositorypw-redact
Earlier public redaction work. The current PII-boundary patterns are represented in pwos-core.
pw-router
Archived routing work. Kept public for provenance; current routing and tool registry patterns live in pwos-core.
What pwplan-core proves in plain English
De-identified means the planning interface receives planning variables without identity fields: no name, date of birth, Social Security number, email, phone, or address. The contract is built so those fields do not exist, and the contract test fails in CI if an identity-shaped field is added. That is why the open planning UI can demonstrate planning workflows without touching real client identity or records.
The open build targets the public nexus-coredemo only. Real client data, audit logging, authenticated subject mapping, and pw-api integration live in a private fork and are out of scope for the public repository.
Reality Check: Demo / case-study tooling. Software, not investment advice; outputs are planning illustrations for review.
What pw-learnai contains
The library groups self-contained modules into Strategy & judgment (5), Organization & delivery (3), and Practice (4), with a separate beginner module and public-data module around the core set. Its differentiator is the bundling layer: modules can be used directly in NotebookLM, Claude Projects, or similar AI notebook workflows.
Contribution criteria are deliberately practical: falsifiable claims, artifacts over essays, and honesty about limits.
What the permissive licenses mean.The -core repositories use the Apache License 2.0; pw-learnai uses the MIT license; supporting repositories carry their own license files. Apache 2.0 and MIT are permissive open-source licenses: anyone may use, modify, and distribute the code — including for commercial purposes — at no cost, as long as they keep the original copyright and license notices (and, for Apache 2.0, the NOTICE file) and note any significant changes. Apache 2.0 also grants a patent license from the contributors, and the code is provided "as is," with no warranty. Protocol Wealth is an investment adviser, not a software vendor — we publish this code as part of how we work and do not sell or charge for it.
Three 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 /frameworkand the systematic-investing pages at /investingdescribe 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. Bothpwos-core andnexus-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. OurOperating Thesisexplains why we believe inspectable, shared infrastructure becomes the standardization layer for AI-augmented fiduciary practice.
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.
What the permissive licenses mean
The -core repositories are released under the Apache License 2.0; pw-learnai is MIT; supporting repositories carry their own license files. Apache 2.0 and MIT are permissive open-source licenses: anyone may use, modify, and distribute the code — including in commercial settings — at no cost, provided they preserve the original copyright and license notices (and, for Apache 2.0, the NOTICE file) and document significant changes. Apache 2.0 also includes an express patent license from the contributors, and the code is provided "as is," without warranty of any kind.
Protocol Wealth is an investment adviser, not a software vendor. We publish this code as part of how we work; we do not sell it, license it for a fee, or offer software support. Any services Protocol Wealth provides are advisory or consulting services delivered as a registered investment adviser — not a software sale.
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.
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 — the foundational plumbing that sits under any niche feature. We publish the reusable pieces of ours.
Capabilities, not products. A starting point, not an end point. Everything here is published transparently under Apache 2.0 / MIT — free to read, run, and build on, with no fee and no field-of-use restriction in the license.
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 two-tier public model: the -corefamily is infrastructure for regulated AI practice, while supporting public repos preserve reference utilities, learning material, and archived predecessors. Firm-specific code, secrets, and client data stay private.
The PII-guard, audit-trail, and gated-tool-registry patterns are vertical-neutral: they can apply to confidentiality-bound professions such as legal, healthcare, and accounting; fiduciary advice is our reference deployment.
Open repositories
| Repo | License | What it is |
|---|---|---|
| pwos-coreOpen | Apache 2.0 | The governance and safety substrate — a 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-coreOpen | Apache 2.0 | The capability and tool layer — a Python hub for regime-adaptive financial analysis: scoring framework, regime detection, MCP tool definitions, and data adapters. |
| pwplan-coreOpen | Apache 2.0 | The privacy-by-construction planning engine — a 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-redactOpen | Public utility | Earlier public redaction utility work; the current PII-boundary patterns are represented in pwos-core. |
| pw-learnaiOpen | MIT | Applied AI strategy and AI-assisted coding modules; content and interactive components, not advisory infrastructure. |
| pw-routerArchive | Archived | Archived routing work kept public for provenance; current routing and tool registry patterns live in 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 thepackages/ 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. Browsesrc/ after the README.
What's inside pw-learnai
Content, not infrastructure. The module index groups applied AI strategy and AI-assisted coding material into Strategy & judgment, Organization & delivery, and Practice tracks, with NotebookLM and Claude Projects bundles for notebook-style review. Start at themodule index.
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. Start with theplanning contract, theassertNoPII tripwire, and thetwo-deployment boundary.
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 /securitydescribe 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, andTHIRD_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.txtfollows 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. Anyone can read, deploy, build on, and improve the code without paying 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. Bothpwos-core andnexus-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.