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 registers and oversees investment advisers). We publish source code so clients, auditors, developers, and regulators can read it and check our public descriptions. The six active repositories use permissive licenses (Apache-2.0, MIT, or dual Apache-2.0 OR MIT-0).
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 authenticated encryption and threshold recovery, see/opensource/encryption. For the contract-level system map across all six active repositories, see/opensource/architecture. 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
Six active repositories publish governance, capabilities, planning, agent-control, learning, and encryption layers. Three archived repositories preserve earlier utilities and integrations for provenance. We link each repository directly because the GitHub organization view may not show every public repo to logged-out visitors.
Source-grounded guides for active repositories
System of systems
See the contracts around a private host
One accessible map connects learning, agent control, governance, analytical capabilities, planning, and optional artifact encryption without claiming production wiring.
Open the architecture map →
Governance
pwos-core
PII, audit, gated tools, workflows, and reusable safety primitives.
Inspect claims and sources →
Capabilities
nexus-core
Financial research APIs and MCP-compatible analytical tools.
Inspect claims and sources →
Planning
pwplan-core
A thin planning UI with an explicit identity boundary.
Inspect claims and sources →
Agent control
pwcli-core
Intent, policy, runtime, approval, redaction, and receipt contracts.
Inspect claims and sources →
Learning
pw-learnai
Modules, labs, exercises, bundles, and browser-only learning tools.
Inspect claims and sources →
Encryption
shard-core
Authenticated encryption and threshold recovery.
Inspect claims and sources →
The -core family
pwos-core
The governance and safety substrate (TypeScript). Publishes inspectable packages and reference patterns for PII tripwires, audit evidence, registered tools, workflows, documents, and related safeguards. Adopters must configure and verify the controls they use.
Open repositorynexus-core
The capability and tool layer (Python). Publishes documented APIs and MCP-compatible analytical tools. Their outputs are research inputs for review, not advice, trade authority, or control over client assets.
Open repositorypwplan-core
Open-source planning UI with an explicit request contract and a defined direct-identifier tripwire. The tripwire is not proof that arbitrary text or combined variables cannot identify a person.
Open repositorySupporting 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
The typed planning contract omits named identity fields such as name, date of birth, Social Security number, email, phone, and address. A separate tripwire rejects a defined list of direct-identifier keys. That is an inspectable control, not proof that arbitrary free text or combined variables cannot identify a person; the public demo is restricted to fake or de-identified inputs.
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
Six active repositories cover governance, capabilities, planning, agent control, learning, and encryption. Three archived repositories preserve earlier work for provenance. 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 the planning contract/ABI consumed by pwplan-core. |
| 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 | A regime-adaptive financial-planning UI (React + Vite) that renders nexus-core planning tools through a typed contract and direct-identifier tripwire. The public demo accepts fake or de-identified inputs only. |
| pwcli-coreDetail page → | Apache-2.0 OR MIT-0 | Agent control-plane contracts for intent, policy, runtime adapters, approvals, redaction, provenance, and content-minimized run receipts. |
| shard-coreDetail page → | Apache-2.0 OR MIT-0 | Authenticated-encryption and threshold-recovery primitives with documented cryptographic and operational boundaries. |
| pw-redactArchive | Archived | 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. |
| pw-aaveArchive | Archived | Earlier public integration work retained for provenance. |
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. Its typed contract omits named identity fields and its tripwire rejects a defined set of direct-identifier keys; the public demo is limited to fake or de-identified inputs. 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.