Patriot University Documentation
Building Patriot University: A Case Study in Human/AI Collaboration
Correction [2026-08-01]: Updated the entity graph edge count to the correct figure.
Date: June 2026 Author: Peter Westerman, with AI collaboration (Claude, Anthropic)
How to Read This Document
This is an educational case study — a behind-the-scenes look at how one person, working with AI, built a product that would normally require a cross-functional team of specialists.
Every section is structured so the reader can map the AI’s contribution onto a role they already understand: architect, data engineer, researcher, editor, legal analyst, project manager.
The throughline is simple: AI does not replace human judgment. It amplifies human direction. The builder still needs to know what to build and why. AI handles the how — and it handles it at a speed and breadth that changes the economics of product development.
What Is Patriot University
Patriot University is a civic news aggregator, civil rights resource, and political accountability platform. It gives citizens, journalists, lawyers, researchers, and organizers access to structured knowledge about constitutional rights, voting procedures, accountability records of public officials, and investigative methodology.
We aggregate reporting from credible news organizations alongside court records and official documents. We publish opinion and analysis based on the news we cover. We provide practical resources for civil rights, voting rights, and civic engagement.
We are also building a public knowledge graph — a cross-referenced, evidence-tiered record of how public officials and public figures have acted. We build it so independent journalists can draw on it in their own reporting, and so a future truth-and-reconciliation effort has a factual foundation for holding public officials who promoted autocracy and authoritarianism accountable for what they did — through their documented actions, not their protected speech.
The information compounds over time rather than scrolling off a feed. The platform currently operates on WordPress (public knowledge base and AI chatbot) and a Python-based backend (AI rights advisor, investigation tools, research search). Mobile and desktop apps are planned.
| What it contains | Details |
|---|---|
| Knowledge base documents | Publishable Markdown files |
| Accountability profiles | Public officials and public figures |
| Investigative tools catalog | 176 tools (OSINT, FOIA, financial tracing, verification) |
| Voting jurisdiction guides | 56 (all 50 states + DC + 5 territories) |
| AI methodology skills | 71 skills across 10 subject families |
| AI editorial team personas | 57 specialists in 7 divisions |
| Board of Advisors | ~90 expert reasoning lenses |
| Learning paths | 22 (9 role-based, 13 use-case playbooks) |
What makes this notable is that one person directed the build — with AI doing the work that would otherwise require a team of engineers, researchers, data architects, editors, and legal analysts.
The Human in the Loop
Peter Westerman is a senior product leader with 35 years in B2B media — subscription products, audience data, information products, events, and research. He is not a software engineer by title, but he has built and directed technology products across his career.
Three aspects of this background were essential to this project:
Domain expertise in information products. B2B media companies build structured knowledge products — databases, directories, research services, event guides.
The architecture of Patriot University — taxonomized content, cross-referenced entities, tiered access, editorial governance — is the architecture of a B2B information product applied to civic accountability. That is not an AI insight. It is operating context.
Social network analysis. Peter’s background includes work with social network mapping — understanding how entities relate to each other, how influence flows through networks, and how to visualize those relationships. When the project needed an entity-relationship graph with community detection and centrality metrics, he wrote the requirements.
The AI selected the tools (igraph, Leiden/Louvain algorithms, betweenness and eigenvector centrality) and built the implementation. But the requirement — that accountability profiles should be nodes in a queryable graph, not standalone documents — came from the human’s experience with network analysis.
Editorial judgment. The single most important human contribution is the one AI cannot provide: deciding what gets published.
Every accountability profile on the platform passes through a human editorial gate. AI drafts, researches, scores, and recommends. The human decides whether the evidence meets the standard, whether the tone is proportionate, whether inclusion is warranted, and whether a claim should be published or held.
These three capabilities — information-product architecture, network analysis, and editorial judgment — are the enabling ingredients. AI amplified them.
How Decisions Actually Got Made
The collaboration follows a consistent pattern, which repeated across every major component of the build:
- The human sets direction. Peter identifies a problem, names the requirement, and often specifies the general approach — based on domain experience.
- AI analyzes the landscape. Claude examines the existing codebase, the available tools and platforms, and the constraints — then proposes an architecture or solution, explaining its reasoning.
- The human approves, modifies, or overrides. Peter reviews the proposal. Sometimes he accepts it. Sometimes he redirects it. Sometimes he injects a concept or reference the AI would not have surfaced on its own.
- AI builds. Claude writes the code, the configuration, the content, the documentation — whatever the approved plan calls for.
- The human reviews and corrects. Peter reads the output, catches errors, adjusts tone, fixes factual claims, and decides what ships.
This is not how most people imagine AI-assisted development. It is not “type a prompt and get a product.” It is iterative, conversational, and grounded in human expertise at every decision point.
A pattern that recurs across the build sessions: the human writes a plan document, then directs the AI with “Implement the plan as specified. Do NOT edit the plan file itself.” The plan is a contract — the human’s requirements, frozen. The AI executes against them but cannot change the scope. This is how scope control works in a one-person-plus-AI team: the human writes the spec, the AI builds to it, and any scope change requires the human to revise the plan first.
Here is how that pattern played out in practice, across the major decisions that shaped the platform.
Choosing Obsidian as the Knowledge Management Platform
What the human brought: Peter selected Obsidian — a Markdown-based knowledge management tool designed for networked notes — as the authoring environment. This was a platform decision based on his understanding of what a civic knowledge base needs: local-first files (no vendor lock-in), bidirectional linking between documents, plain-text format (version-controllable in Git), and compatibility with an AI-assisted editing workflow.
What AI built on that decision: Claude built the customizations that turned Obsidian from a note-taking tool into a structured publishing platform. That included a canonical frontmatter schema (16 fields governing slug, category, SEO metadata, status, evidence tiers, and cross-references), a validation pipeline, and a set of conventions — like slug wikilinks for cross-references — that let the knowledge base function as a queryable graph rather than a folder of files. See Knowledge Graph and LLM Wiki Architecture for the full architecture.
Why this matters: The human knew what kind of tool was needed. AI figured out how to configure it.
Choosing WordPress as the Publishing Endpoint
What the human brought: Peter selected WordPress as the public-facing publishing surface. This was a practical decision — WordPress powers a large share of content sites, has a mature plugin ecosystem, and was already running the site.
What AI built on that decision: The integration between Obsidian (local Markdown) and WordPress (public knowledge base) did not exist. Claude analyzed both environments in detail — the local file structure, the WordPress REST API, the Echo Knowledge Base plugin’s custom post type, the AI Engine plugin’s embedding pipeline, the Yoast SEO metadata fields — and designed and built a complete sync engine.
This was not a trivial integration. The AI produced a 546-line planning document the “Content Workflow Re-engineering Plan”) that analyzed two architectural options, recommended one, and laid out a seven-phase implementation with acceptance criteria for each phase. The human reviewed the plan, approved the direction, and the AI built all seven phases.
The plan presented two architectural options: Option A (move the source of truth into WordPress, build a custom authoring plugin) versus Option B (keep local Markdown as the single source of truth, build an automated sync engine to push content to WordPress). Claude analyzed both, laid out the pros and cons, and recommended Option B — because moving authoring into WordPress would orphan the FastAPI backend, lose git versioning, break the Cursor rules system, and require re-implementing the entire skills library in PHP.
Peter reviewed the analysis, agreed with the recommendation, and approved the plan. That is the collaboration pattern in miniature: AI does the analysis; the human makes the call.
The role-mapping: In a traditional team, this would be the work of a systems architect (analyzing the two platforms), a senior engineer (building the sync engine), a DevOps engineer (deploying the WordPress plugins), and a project manager (phasing the work). One AI did all four roles, with the human making the strategic calls.
Injecting the Karpathy LLM-Wiki Concept
What the human brought: Peter introduced the concept of Andrej Karpathy’s “LLM Wiki” — the idea that a knowledge base designed to be consumed by large language models should be structured differently from one designed for human readers. It should have consistent metadata, explicit cross-references, and machine-readable categorization.
What AI built on that decision: Claude designed and implemented the LLM-Wiki layer: a structured frontmatter schema, bidirectional related: fields enforced by an automated sync script, slug wikilinks that resolve differently depending on the rendering surface (WordPress permalinks for the public site, API paths for the backend, relative links for local authoring), and a link graph that tracks which documents reference which others — enabling cascade re-rendering when a cross-referenced document changes. See Knowledge Graph and LLM Wiki Architecture for details.
Why this matters: The human supplied the concept. AI turned the concept into engineering.
Social Network Mapping
What the human brought: Peter drew on his background in social network analysis to define the requirement — accountability profiles should not be isolated documents but nodes in a relationship graph. The graph should support community detection (which groups of people cluster together?), centrality metrics (who is most connected?), and visual exploration.
What AI built: Claude selected igraph as the graph library, implemented three community-detection algorithms (Leiden, Louvain, and Label Propagation), computed social-network-analysis metrics (betweenness centrality, closeness, eigenvector, PageRank, k-core, constraint), and built a Cytoscape.js visualization that readers can explore interactively on the published site. The graph currently has over 5,300 typed edges.
The role-mapping: Network analyst (the human) + data engineer and visualization developer (AI).
Content Taxonomy
What the human brought: Peter built the initial content taxonomy — the category hierarchy that organizes the knowledge base. This is editorial architecture: deciding that voting rights content should be organized by jurisdiction, that accountability profiles should be browsable by role and affiliation, that investigative tools should be structured by methodology family.
What AI enriched: Claude expanded the taxonomy into a machine-readable YAML file, reconciled two competing category systems that had accumulated in different parts of the codebase, built validation rules to prevent miscategorization, and implemented multi-category support when profiles needed to appear in more than one browse path.
Accountability Profiles and the Scoring System
What the human brought: Peter developed the core concept of accountability profiles — structured, evidence-based records of the documented conduct of public officials. He set the editorial principle that these should be factual documentation, not opinion — grounded in court records, official proceedings, and credible journalism. See Accountability Profiles — Standards FAQ for the full standards reference.
What AI built: Claude designed and implemented the assessment and scoring infrastructure:
- The Democratic Malice Assessment (DMA) — a five-level scoring system that distinguishes ideology (legitimate policy disagreement) from malice (intentional subversion of democratic mechanisms). The scoring includes an Ideology-vs-Malice Gate: three of five distinguishing factors must be met before a score is assigned.
- The Accountability Profile Pipeline — a five-stage composition sequence: profile building, private-citizen inclusion gate, evidence verification, malice scoring, and a sanity-check audit.
- Evidence tiers (Documented, Credibly Reported, Alleged, Excluded) with escalation requirements — higher-severity claims require higher-tier evidence.
- A Federal Judge Inclusion Gate with five specific criteria, because judicial profiles carry additional legal and institutional sensitivities.
- A Sanity Check — a five-level audit (factual accuracy, proportionality, legal exposure, systemic consistency, hostile-scrutiny stress test) that every profile must pass before publication.
A concrete example of the iteration: AI initially named the scoring system the “Evil Evaluator.” Peter corrected it to “Malice Evaluator” — because “evil” is a moral judgment, while “malice” is a legal and analytical term with a specific meaning in defamation law and democratic theory. That single naming correction reflects the difference between AI’s default instinct (dramatic labeling) and the human’s editorial discipline (precise, defensible terminology). The AI then incorporated the Sullivan-doctrine defamation-law framework into the skill, adding legal protections the human’s naming correction had signaled were needed.
Why this matters: The human said “we need structured accountability with visible methodology.” AI designed the methodology, built the scoring engine, and implemented the editorial safeguards. But every inclusion decision, every malice score, and every publish gate is ultimately approved by the human.
Skills, Agents, and Rules — True Co-Creation
This is the clearest example of iterative collaboration. Neither the human nor the AI could have built the skills library alone.
What happened: Peter and Claude iterated on the skill definitions — 71 methodology skills covering constitutional law, investigative OSINT, civic strategy, legal analysis, election security, and more. Peter would identify a domain need (“we need a skill for autocracy evaluation”) and often recommend specific people whose expertise should inform the reasoning (scholars like Anne Applebaum, Timothy Snyder, Steven Levitsky, Kim Lane Scheppele, Marc Elias). Claude would build the skill — the methodology, the reasoning framework, the prompt structure — and Peter would review, correct, and refine.
The same iterative pattern governed the 13 Cursor rules (machine-enforced editorial standards — see Rules & Editorial Standards — Overview), the Board of Advisors personas (~90 expert reasoning lenses), and the multi-agent editorial system (57 AI specialist personas organized into 7 divisions).
The role-mapping: Subject-matter expert and editorial director (human) + knowledge engineer and technical writer (AI), with each iterating on the other’s work in repeated cycles.
The Publishing Pipeline
What the human brought: Peter defined the problem — the existing manual workflow (export to XML, import as drafts, manually convert to knowledge base articles) was slow, error-prone, and produced broken cross-references. See Editorial Review & Publishing Process for the current pipeline as readers experience it.
What AI architected: Claude produced the full engineering plan and built the implementation. The pipeline is a Python CLI (pu_publish.py) that reads local Markdown, renders HTML, rewrites cross-reference links to WordPress permalinks, and syncs content to WordPress via the REST API. It is idempotent (running it twice with no changes produces no updates), change-detected (content hashing), cascade-aware (when a referenced document changes, its referrers are re-rendered), and includes structured logging with correlation IDs for debugging.
A later session illustrates how the human manages risk in AI-assisted builds. When the Content Operations Console was being planned, Peter’s directive was explicit: “Before building, review the Plan to insure nothing will break our existing Pipeline.” Claude responded with a parallel analysis of the plan, the Makefile, the publishing scripts, and the frontmatter library — identifying three critical risks (must use the existing KBDoc.write() method rather than custom YAML writers, must not touch wp_post_id fields, must handle stale in-memory state after pipeline write-back). Those risks were addressed in the plan before any code was written. The human’s instinct was “check before you break something.” The AI did the checking.
Token Management
What the human brought: Peter identified the real-world need for token usage tracking. AI-assisted development consumes API tokens — Claude, Tavily web search, Pinecone vector operations — and those costs add up. Without visibility, you cannot manage budget.
What AI built: Claude proposed and built a token usage dashboard in the Content Operations Console that tracks spending across Cursor, the Claude API, Gemini, and Tavily credits — with cost analysis and trend visualization. The human defined the business need; AI proposed the architecture and built the implementation.
When AI Found a Problem the Human Did Not Know Existed
During the Phase 0 analysis, Claude discovered that 67 articles were live on the patriot.university WordPress site but had no corresponding source file in the local Markdown repository. These were “orphan” articles — created through earlier manual WordPress editing, before the structured pipeline existed.
This mattered because the planned migration would rebuild the entire site from local Markdown. Without those 67 source files, those articles would be silently deleted during cutover — and the human would not have known they were missing.
Claude built a recovery script (pull_live_content.py) that fetched each orphan article via the WordPress REST API, converted the HTML back to Markdown with proper frontmatter, and wrote local source files — preserving the original URLs so no search equity was lost. All 67 recovered articles were then reviewed by Peter and promoted to published status.
Why this matters: AI analyzing the environment surfaced a data-loss risk that manual inspection would likely have missed. The human did not know the problem existed until the AI found it. But the human still decided what to do about it — review each recovered article, decide whether it met current standards, and approve or revise.
Board of Advisors — Human Curation, AI Execution
What the human brought: Peter recommended specific scholars, analysts, and practitioners whose expertise should inform the platform’s reasoning. Names like Anne Applebaum, Robert Mueller, Kim Lane Scheppele, Steven Levitsky, Timothy Snyder, and Marc Elias were human selections — Peter’s editorial judgment about whose analytical frameworks are most valuable for civic accountability work. See Patriot University Board of Advisors — Routing Index for the full roster.
What AI built: Claude built approximately 90 “advisor” personas — structured reasoning lenses modeled on each expert’s published work and analytical approach. These are not impersonations. They are frameworks: when the platform analyzes an accountability question, it can reason through the lens of a specific expert’s methodology (“How would a Levitsky-style democratic backsliding analysis frame this action?”).
Building on What Came Before
Patriot University was not built from scratch. It drew on patterns, code, and lessons learned from earlier ITI products — and this is itself a demonstration of how AI-assisted development compounds.
Before Patriot Uiversity, Peter had directed the builds for multiple AI-powered products across different domains. Each one contributed patterns that PU reused:
| Product | What it contributed to PU | Build period |
|---|---|---|
| AI News Cafe | RSS aggregation patterns, WordPress plugin architecture, news monitoring | Late 2024 – early 2025 (est.) |
| ScubaGPT | Knowledge base management, AI advisor patterns, vector search integration | Late 2024 – early 2025 (est.) |
| Factchecker | Verification methodology, claims analysis, evidence standards | Late 2024 – early 2025 (est.) |
| Career Coach | Conversational AI patterns, multi-mode interaction design | Late 2024 – early 2025 (est.) |
| GD Chatbot | Chatbot architecture, prompt engineering, conversation management | Late 2024 – early 2025 (est.) |
| Journey Mapper | Customer journey methodology, audience segmentation | Late 2024 – early 2025 (est.) |
| ITI Shared Library | WordPress API clients (Claude, Tavily, Pinecone), database patterns, agent infrastructure, admin UI components | Evolving since early 2025 (est.) |
The shared library is particularly important. Rather than building WordPress integration from scratch for each product, Peter and Claude extracted reusable components — API clients, database base classes, orchestrator patterns, chat handlers, admin UI utilities — into a cross-product library. When Patriot University needed a Claude API client or a Pinecone integration, the shared library already had one. When Patriot University needed a chatbot architecture, the pattern from earlier products was already documented and tested.
The transfer was less “copy the code” and more “re-platform the proven patterns into a new domain.” The conversational AI layer came from gd-chatbot and Scuba GPT. The content pipeline discipline came from Scuba GPT’s 22 data pipelines. The evidence and verification methodology came from Factchecker. The persona-based reasoning architecture came from Career Coach’s 65 sub-agent system. The SEO automation came from AEO Optimizer. Each precursor solved a problem in its own domain; Patriot University synthesized those solutions into civic accountability.
Why this matters for understanding AI-assisted development: AI does not just build the current project. It carries forward what worked before — adapting proven patterns to new contexts, reusing code, and avoiding the mistakes of earlier iterations. This is how a single human can direct a portfolio of 20+ products without starting from zero each time. The AI remembers what was built, understands why it was built that way, and applies those lessons to new work.
Diagnosing an Opaque Technical Failure
A recurring technical problem illustrates a different facet of the collaboration. The WordPress AI Engine plugin — which powers the chatbot’s knowledge retrieval — was throwing an opaque error: Invalid data for embedding. The error message gave no clue about the actual cause.
Claude traced the failure through the AI Engine source code (classes/engines/chatml.php, run_embedding_query()) and identified that the plugin was masking the real OpenAI error message. The actual causes turned out to be three distinct problems: empty content (articles whose post_content was blank because AI Engine reads raw database content, not rendered blocks), oversized content (several knowledge base documents exceeded OpenAI’s 8,192 token embedding limit), and malformed encoding (null bytes or invalid UTF-8).
The fix was two-layered: a pre-flight validation step in the publishing pipeline (rejecting empty or oversized content before it reaches WordPress) and a server-side guard plugin (sanitizing content before AI Engine sends it to OpenAI). Both were designed and built by AI based on the root-cause analysis.
The role-mapping: In a traditional team, this is senior backend debugging — the kind of work where an engineer reads third-party source code, traces error paths, and designs a multi-layered fix. The human approved the approach; AI did the forensic analysis and built the solution.
The Build, Sequenced
The build of Patriot University followed a compressed but disciplined timeline.
Phase 0 — Foundation
Peter:
- Developed the concept and editorial framework
- Built the initial knowledge base content (accountability profiles, voting guides, civic education articles)
- Scoped the FastAPI backend and AI advisor
- Built the iOS/macOS app prototypes (Swift/SwiftUI) [development paused]
- Created the initial investigative tool catalog
- Scoped the multi-platform architecture (WordPress + FastAPI + mobile apps)
This work was done in collaboration with AI.
The Platform Emerges
In late March 2026, the ITI workspace was restructured. During March and April:
- Agent roster and skills library expanded
- Chat and API handlers updated across products
- UI design system and cross-product upgrades applied
- Documentation standardized across products
This period established the shared infrastructure that PU would draw on heavily.
The Re-engineering Sprint
The most intensive period of the build occurred over two days. Claude produced the Content Workflow Re-engineering Plan — a 546-line engineering document analyzing the existing workflow, comparing two architectural options, and recommending a seven-phase implementation. Peter approved the direction with edits, and the build began immediately.
All seven phases were built:
| Date | What was built |
|---|---|
| May 15 | Phase 1: Frontmatter metadata foundation (backfill ~1,000 files) |
| May 15 | Phase 2: Cross-reference system (link migration, resolver, bidirectional sync) |
| May 15 | Phase 3: Publishing sync engine (pu_publish.py + supporting libraries) |
| May 15 | Phase 4: WordPress mu-plugins and setup runbook |
| May 16 | Phase 5: Authoring workflow and content propagation |
| May 16 | Phase 6: Cutover tooling (orphan recovery, URL-diff gate, SEO check) |
| May 16 | Phase 7: Content Operations Console (local admin GUI) |
This was the equivalent of a small engineering team’s two-week sprint, compressed into 48 hours. The AI did the building; the human set the requirements, approved the architecture, and reviewed the output — directing modifications.
Cutover and Content Expansion
The days immediately after the re-engineering sprint were dedicated to deploying the new pipeline and expanding content at scale:
- 673 published articles recorded with WordPress post IDs
- 67 orphan articles recovered from the live site and promoted
- Skills published as searchable AI-skills articles
- 17 duplicate documents removed, categories synced
- Major accountability profile expansions — detailed TRC (Truth and Reconciliation Commission) sections added to key profiles
- Content Operations Console features: taxonomy management GUI, multi-category support
- Batch creation of accountability profiles: 5 spokesperson profiles, 24 governor profiles, 12 redistricting profiles, 122 January 6 objector profiles
- Supreme Court justice profiles — all 9 current justices
- Press freedom tracker integration
- Auto-generated SEO metadata for all 573 pipeline-managed documents
- Reader-facing editorial standards and documentation articles written, edited and published
Sustained Development
Following the initial sprint, development continued at a steady pace — averaging multiple commits per day. Key milestones:
- Inline timeline and infographic embedding system
- Master timeline repository with extraction scripts
- 122 accountability profiles for January 6 electoral certification objectors
- Policy tracker articles (Schedule F, Impoundment, Birthright Citizenship, Comstock Act, Media Retaliation)
- Task Force 250 and Freedom 250 accountability profiles
- Federal regulatory analysis skill and OMB analysis
The Tempo
The build log shows 450 commits to the Patriot University product directory. The weekly tempo tells the acceleration story:
| Period | Commits | What was happening |
|---|---|---|
| March 2026 | 4 | Foundation, workspace migration |
| April 2026 | 4 | Infrastructure, design system |
| May 15–16 | ~135 | Re-engineering sprint (Phases 1–7) |
| May 17–25 | ~120 | Cutover, content expansion, profile batches |
| May 26 – June 2026 | ~185 | Sustained development, deepening |
The acceleration from March (4 commits) to May (250+ commits in 16 days) is the direct result of the AI collaboration reaching full velocity — the shared library was in place, the pipeline was built, and the human/AI workflow was refined enough to produce at scale.
The Product, in Plain Terms
Each major capability area of Patriot University was shaped by a specific aspect of the human/AI collaboration. Here is what was built, stripped of jargon, with the collaboration role clearly marked.
Structured Knowledge, Not Articles
Traditional civic information sites publish articles that scroll off a news feed. Patriot University organizes most of its content differently — as a queryable knowledge base where every document has structured metadata, explicit cross-references to related documents, and a position in a taxonomic hierarchy.
Who built which part:
- Human: Defined the content architecture (topic categories, audience segments, content types), set the editorial scope, selected Obsidian and the LLM-Wiki approach.
- AI: Built the metadata schema, wrote the validation pipeline, migrated 1,000+ documents to the structured format, built the cross-reference system (bidirectional
related:fields,slugwikilinks, a link graph for cascade integrity).
The result is a knowledge base that compounds. When a new accountability profile mentions a policy, the link graph connects it to the policy tracker, the relevant voting guides, the investigative tools that apply, and the legal analysis of the constitutional issues involved. Those connections are maintained automatically.
Accountability with Visible Methodology
The platform’s signature feature is its accountability profiles — structured records of the documented conduct of public officials and public figures. See Accountability Profiles — Standards FAQ for the full methodology reference.
What makes them unusual is the visible methodology. Every profile carries:
- An evidence tier (Documented, Credibly Reported, Alleged) for every factual claim
- A priority classification (P0, P1, P2) based on position and impact
- A Democratic Malice Assessment score (1–5), with an Ideology-vs-Malice Gate that prevents legitimate policy disagreement from being scored as malice
- A “Basis for Inclusion” disclosure block explaining why the individual meets the threshold for a profile
- A sanity-check audit result (five-level stress test)
Who built which part:
- Human: Conceived the accountability profile concept, set the editorial standards (evidence-based, proportionate, defensible), established the inclusion criteria, approved every published profile.
- AI: Designed the DMA scoring methodology, built the five-stage pipeline (builder, inclusion gate, verification, malice evaluator, sanity check), implemented the private-citizen inclusion gate (five Non-Speech Anchors, Speech Taint Strip Test), created the Federal Judge Inclusion Gate, and built the automated guardrail checks that enforce the editorial rules during authoring.
The AI Rights Advisor
The platform includes an AI-powered advisor that answers questions about constitutional rights, generates civic documents (flyers, talking points, letters, press releases), simulates conversations for civic preparedness, and provides strategic organizing guidance. See Patriot University — User Manual for how readers interact with the advisor.
Who built which part:
- Human: Defined the four interaction modes, set the tone (educational, not advocacy), established the PII privacy requirement (no user accounts, no tracking).
- AI: Built the FastAPI backend, the Claude API integration, the knowledge-retrieval layer (Pinecone vector search grounded in the full knowledge base), and the 71 methodology skills that give the advisor deep, domain-specific reasoning capability.
The Entity-Relationship Graph
Every accountability profile is a node in a relationship graph — connected to other profiles, organizations, financial flows, and events. The graph supports community detection (which people cluster together?) and social-network-analysis metrics (who is most central? who bridges communities?). See Knowledge Graph and LLM Wiki Architecture for the graph architecture.
Who built which part:
- Human: Defined the requirement based on social network analysis expertise. Specified that the graph should support community detection, centrality metrics, and interactive exploration.
- AI: Selected igraph for the graph library. Implemented three community-detection algorithms. Computed six categories of SNA metrics. Built the Cytoscape.js interactive visualization. Designed the graph embedding system so readers can explore relationship networks directly within accountability profiles.
The Content Operations Console
As the knowledge base grew, the human identified an operational problem: managing a knowledge platform with 1,500+ documents, requiring frequent updates, a multi-stage publishing pipeline, embedding health, cross-reference integrity, and editorial guardrails required a single dashboard — not scattered Markdown files with hand-maintained counts that drifted out of date.
Peter defined the requirement. Claude designed and built a browser-based operations console (local-only, never exposed publicly) with nine functional areas:
| Feature | What it does |
|---|---|
| Overview Dashboard | Live inventory counts, pipeline health, category and status charts |
| Network Graph | Cytoscape.js visualization with community overlays and SNA metrics |
| News Update | Tavily and RSS scans, skill-based reviews, patch queue |
| Compose | Three-pane AI co-authoring workspace with context inspector |
| Source Manager | Document ingestion (upload, URL, or paste) with AI-powered draft generation |
| Infographic Generator | AI brief generation, image rendering, WordPress Media upload |
| Timeline Generator | AI event extraction, timeline creation and embedding |
| Token Usage Dashboard | Cross-platform cost tracking (Cursor, Claude API, Gemini, Tavily) |
| Scripts and Jobs | 25 one-click pipeline operations with dry-run preview |
The Source Manager is particularly noteworthy as a collaboration example. An editor uploads a document (PDF, URL, or pasted text), the AI processes it and generates draft knowledge base articles with proper frontmatter — depositing them into a drafts directory for human review. The AI does the heavy lifting of reading, analyzing, and structuring the source material. The human reviews, edits, expands, and decides what gets promoted to publication.
Who built which part:
- Human: Defined the operational need (the Content Workflow Re-engineering Plan explicitly notes that “the plan documents repeatedly hand-maintain drifting counts” and that “every plan ends with a manual ‘update the counts’ step”). Specified what the console should monitor and control.
- AI: Built the entire application — a Python backend with a browser frontend, connected to the filesystem, the WordPress API, and the publishing pipeline.
Editorial Governance
The platform enforces its editorial standards through 13 machine-readable rules that AI must follow during content creation. These rules cover evidence tiers, inclusion gates, prohibited language, proportionality requirements, speech doctrine (actions are documented separately from speech), and documentation freshness. See Rules & Editorial Standards — Overview for the full rule set.
Who built which part:
- Human: Set every editorial standard. The rules encode Peter’s editorial judgment — not AI’s defaults.
- AI: Translated those editorial standards into machine-enforceable rules, built the automated guardrail checks, and implemented the sanity-check audit system.
What We Learned
The build surfaced several honest lessons about how human/AI collaboration works in practice. See Corrections & Transparency Policy for how these lessons translate into reader-facing editorial commitments.
What the Human Learned
AI is not a replacement for knowing what to build. The most important contributions in this project were directional — choosing Obsidian, insisting on structured metadata over free-form articles, introducing social network analysis, selecting which scholars to model, maintaining evidence standards. AI could not have supplied any of those. It needed to be told.
AI is fast but not always right. Claude’s initial analysis of existing knowledge solution technology stacks was incomplete and erroneous. Peter caught the error, directed deeper research, and corrected the record. Speed without verification is not an advantage.
You have to read everything. AI generates text at a pace that tempts the human to skim. Every factual error that made it into the prospectus was caught during human review — because Peter reads the output. Those corrections required human domain knowledge to catch and fix.
AI makes confident mistakes. During a knowledge base expansion session, Claude recommended adding accountability profiles for several high-profile figures — Kevin Roberts, Leonard Leo, Peter Thiel, and others — as “gaps” in the platform’s coverage. They already existed. The knowledge base had 484 profiles at the time, and the AI had failed to check the directory before recommending new work. The human caught it (in this case, the AI self-corrected once pointed at the filesystem). The lesson: AI can be confidently wrong about what already exists in a large corpus. Filesystem is ground truth, not memory.
What the AI Learned (Iteratively)
Editorial voice is hard. The writing-voice analysis from the prospectus edit session showed a systematic pattern: AI defaults to hype (“zero-PII,” “10x conference revenue,” “personally writing PHP”), and the human consistently de-escalates to defensible, qualified claims (“tiered, data-minimizing privacy architecture,” “increased conference revenue,” “directing the builds”). A formal voice rule was extracted from those edits and applied to subsequent work.
Human constraints are information. Peter’s insistence on separating what exists today from what is planned (“Currently WordPress + FastAPI. Planned iOS/macOS apps and Hugo portal”) is not a style preference — it is an accuracy discipline. AI learned to apply the Currently/Planned framing systematically.
Real-world needs surface problems AI would not anticipate. Token management is a good example. AI does not experience budget constraints. The human identified that API costs were a real operational concern, and the AI built the tracking dashboard. Similarly, the orphan-article recovery — finding 67 published articles on the live WordPress site that had no local source file — was a problem AI discovered during its analysis, but the operational imperative (these articles would be silently lost during migration) was understood because the human cared about the content.
The Always-in-the-Loop Principle
The most important lesson is structural. This project produced 478 accountability profiles about real people. Those profiles carry evidence tiers, malice scores, and factual claims that have legal and reputational consequences.
AI can draft those profiles. It can score them. It can run sanity checks. But the decision to publish a profile — to say “this person’s documented conduct meets the threshold for public accountability documentation” — is a human decision. It has to be.
The platform’s credibility rests on that distinction. The methodology is visible. The evidence is cited. The scoring is transparent. But a human — not an algorithm — made the call.
What This Means for Future Product Development
The Patriot University build demonstrates something generalizable: AI changes the economics of product development, not by replacing expertise but by amplifying it.
The Team-of-One Economics
In a traditional build, this product would require:
| Role | Traditional headcount | In this project |
|---|---|---|
| Systems architect | 1 | AI (human approves architecture) |
| Backend engineer | 1–2 | AI (human defines requirements) |
| Frontend/WordPress engineer | 1 | AI (human selects platform) |
| Data engineer | 1 | AI (human specifies graph requirements) |
| Content strategist | 1 | Human |
| Researchers/writers | 3–5 | AI (human reviews and approves) |
| Legal/compliance analyst | 1 | AI + human (scoring is AI; judgment is human) |
| Editor-in-chief | 1 | Human |
| Project manager | 1 | AI + human (AI phases the work; human approves) |
| DevOps | 0.5 | AI |
| Total | 11–14 FTEs | 1 human + AI |
This does not mean the work quality is lower. The AI-produced publishing pipeline includes structured logging with correlation IDs, cascade re-rendering for cross-reference integrity, embedding pre-flight validation, and a reconciliation system that diffs intent against outcome. That is not corner-cutting. It is engineering at a level that a small team often cannot afford.
What Has to Be Human
The economics are compelling, but they work only because the human brings the irreplaceable elements:
- Domain knowledge. Knowing that a civic knowledge base should be structured like a B2B information product, not a blog.
- Editorial judgment. Deciding who warrants an accountability profile, what evidence meets the standard, and what tone is proportionate.
- Network expertise. Understanding that entity-relationship graphs with community detection add analytical value beyond standalone documents.
- Strategic direction. Choosing Obsidian, choosing WordPress, injecting the LLM-Wiki concept, selecting the scholars whose reasoning should be modeled.
- Quality control. Reading every output. Catching errors. Correcting claims. Maintaining the standard.
AI handles the execution — and at a speed and breadth that fundamentally changes the build timeline. But the execution is only as good as the direction.
The Velocity Example
On a single day (May 20, 2026), the human/AI collaboration produced: all 9 Supreme Court justice profiles, a press freedom tracker integration, SEO metadata automation for 573 documents, reader-facing editorial standards and documentation, a Federal Judge Inclusion Gate, 6 Trump personal attorney profiles, and multiple additional accountability profiles — each with evidence tiers, malice scoring, inclusion gates, and sanity checks.
That is not AI generating text mindlessly. Each profile goes through a five-stage pipeline with human approval at the gate. The speed comes from AI handling the research, drafting, scoring, and formatting — while the human reviews, corrects, and decides what publishes.
In a traditional editorial operation, the equivalent output would represent weeks of work by a team of researchers and writers.
The Generalizable Insight
This pattern — one domain expert directing AI across multiple specialist functions — is not limited to civic technology. Any product company where the founder or lead has deep domain expertise can apply the same approach:
- A healthcare executive who understands clinical workflows could direct AI to build a patient-engagement platform.
- A financial services professional who understands compliance could direct AI to build a regulatory-monitoring tool.
- An education leader who understands curriculum design could direct AI to build a learning management system.
The requirement is not technical fluency. It is domain fluency — knowing what the product should do and why, so that AI can handle how.
What changes is the team size, the timeline, and the cost. What does not change is the need for a human who knows the domain.
Appendix A: Build Timeline
| Date | Event | Human / AI |
|---|---|---|
| Late 2024 – early 2025 (est.) | Concept development, initial KB content, FastAPI backend, precursor product builds | Both |
| March 27, 2026 | ITI workspace migration and restructuring | Both |
| March 28 | Agent roster and skills library expansion | Both |
| April 18 | UI design system, cross-product upgrades | Both |
| April 29 | Documentation standardization | Both |
| May 15 | Content Workflow Re-engineering Plan produced (546 lines) | AI (plan); Human (approval) |
| May 15 | Phase 1: Frontmatter metadata foundation | AI (build); Human (schema decisions) |
| May 15 | Phase 2: Cross-reference system | AI |
| May 15 | Phase 3: Publishing sync engine | AI |
| May 15 | Phase 4: WordPress mu-plugins | AI |
| May 16 | Phase 5: Authoring workflow + propagation | AI |
| May 16 | Phase 6: Cutover tooling | AI |
| May 16 | Phase 7: Content Operations Console | AI |
| May 17 | 673 articles published via pipeline; 67 orphans recovered | AI (execution); Human (review) |
| May 18 | Major accountability profile expansions (TRC sections) | Both |
| May 19 | Batch profile creation (spokespersons, governors, redistricting) | Both |
| May 20 | Supreme Court profiles, press freedom integration, SEO automation | Both |
| May 23 | 122 January 6 objector profiles | Both |
| May 28 | Timeline/infographic embedding system | AI (build); Human (requirements) |
| June 1–2 | Policy trackers, regulatory analysis | Both |
| June 2026 | Sustained development, deepening, documentation | Both |
Dates marked “(est.)” are inferred from product artifacts and repository structure. Dates from May 2026 onward are verified from the git commit log (450 commits total).
Appendix B: AI Capability to Human Team Role Mapping
| AI capability | Equivalent human team role | Example in PU |
|---|---|---|
| Codebase analysis and architecture proposal | Systems architect | Content Workflow Re-engineering Plan |
| Python/PHP/Swift code generation | Backend/frontend engineer | pu_publish.py, WordPress mu-plugins, FastAPI endpoints |
| Data modeling and graph construction | Data engineer | Entity graph (19,766 edges), community detection, SNA metrics |
| Content research and drafting | Researcher/writer | 478 accountability profiles, 56 voting guides, 71 skills |
| Methodology design | Knowledge engineer | DMA scoring, evidence tiers, sanity-check audit |
| Prompt engineering | AI/ML engineer | 71 methodology skills, 90 Board of Advisors personas |
| Documentation | Technical writer | Administrators Manual, Editors Manual (1,000+ lines each) |
| Build sequencing and phasing | Project manager | Seven-phase plan with acceptance criteria |
| Testing and validation | QA engineer | Frontmatter validation, embed pre-flight, URL-diff gate |
| Plugin/theme development | WordPress specialist | Echo KB integration, custom theme, pipeline plugin |
| Visualization | Data visualization developer | Cytoscape.js network graphs, dashboard charts |
| SEO implementation | SEO specialist | Auto-generated meta descriptions, Yoast integration, sitemap management |
Appendix C: Sources and Methodology
This case study is grounded in the following primary sources:
- Git commit history: 450 commits to
products/patriot-university/in the ITI monorepo, spanning March 27 through June 2026. Commit messages, dates, and file-change logs were used to reconstruct the build timeline. - The Content Workflow Re-engineering Plan: A 546-line engineering document (
CONTENT-WORKFLOW-REENGINEERING-PLAN.md, dated May 15, 2026) produced by AI and approved by the human. This document is the most detailed single artifact of the collaboration — it shows AI analyzing the environment, proposing architecture, and the human making decisions. - Administrators Manual and Editors Manual: Two operational documents (2,400+ and 900+ lines respectively, both last updated June 2026) that catalog every feature, workflow, and governance structure.
- Agent transcripts: Cursor IDE session transcripts documenting human/AI conversations during the build — directives, reasoning, corrections, and iterative refinement.
- Precursor product artifacts: CLAUDE.md files, shared library code, and commit histories for ITI products that pre-date PU.
- An investor prospectus edit session: A documented instance of the human reviewing and correcting AI-generated prose — the source of the writing-voice analysis and the editorial-correction patterns described in “What We Learned.”