Project Loom

A Research Framework for Understanding Why Governance Fails — and How to Fix It

What Is Project Loom?

Project Loom is an open research initiative that maps, analyzes, and improves governance mechanisms through transparent systems modeling, implementation analysis, and decision support. It treats governance as an empirical object of study — something that can be dissected, measured, and rebuilt.

Loom is not a think tank. It is not a consultancy. It is a research operating system: a set of conceptual tools, case study protocols, and analytical frameworks designed to answer one question with surgical precision:

Why do announced policies fail to become actual outcomes?

The gap between political ambition and institutional capacity is not a bug in the system. It is the system. Project Loom exists to make that gap visible, measurable, and — eventually — bridgeable.

Why Does This Exist?

American governance is optimized for announcements, not outcomes. Politicians promise. Agencies procure. Contractors bill. Citizens wait. And somewhere in the machinery between the press conference and the drinking water, things fall apart.

Loom builds its analysis from documented cases:

• Student Loan Forgiveness — how a legally vulnerable pathway collapsed under judicial review
• Healthcare.gov — how operational incapacity destroyed a politically supported policy
• Flint Water Crisis — how institutions with information and authority still failed to act
• Operation Warp Speed — how temporary capacity assembly can bypass institutional debt
• California High-Speed Rail — how long-horizon projects outlast their political and financial foundations
• United States Digital Service — how a governance system can build durable self-correction capacity after catastrophic failure

Each case follows a standardized diagnostic protocol. Each tests the ontology against real-world outcomes. The goal is not to score points but to build a vocabulary for the thing we are all experiencing but cannot name.

How Did This Start?

Project Loom emerged from a simple observation: the machinery of American governance is failing in predictable, repeatable ways. The same patterns appear across domains, administrations, and political coalitions. The failures are not random. They are structural.

Loom began as an attempt to name those structures. It has evolved into a multi-module research program with a core ontology, a growing case library, and applied frameworks for intervention design.

The EROS Governance Analysis Framework

EROS (Executive Reversal Operating System) is one module under the Loom umbrella. It provides a six-stage sequential methodology for analyzing governance mechanisms and designing transitions:

Stage	Question
1. Institutional Mapping	How do power, authority, funding, and decision-making actually flow?
2. Dependency Analysis	Which systems depend on which others, and what breaks if one changes?
3. Capacity Assessment	Can the responsible institutions actually perform the required work?
4. Implementation Design	What are the administrative, legal, and operational steps required?
5. Transition Risk Modeling	What are the foreseeable failure modes, bottlenecks, and capture pathways?
6. Accountability & Resilience Evaluation	How do we embed oversight, transparency, and recovery into the design?

This framework is politically neutral. It studies governance mechanisms, not ideology. The same analytical tools apply regardless of administration or policy domain.

Who Is This For?

You are…	Loom can help you…
A researcher or academic	Develop rigorous, cross-domain frameworks for studying institutional failure and transition
A policy professional or legislative staffer	Design implementation pathways that account for capacity constraints and political fragility
An organizer or advocate	Map the dependency chains and veto points that determine whether a campaign’s demands can actually be executed
A journalist	Analyze governance failures with conceptual precision rather than narrative convenience
A technologist or designer	Build tools, databases, and interfaces that make institutional machinery visible and navigable
A citizen	Understand why the systems that affect your life behave the way they do

How This Site Is Organized

Project Loom’s vault is structured as a working research environment, not a blog or a book. Every folder has a specific function. Understanding the structure is the first step to using the site effectively.

00 Documentation

What it is: Meta-project records, style guides, naming conventions, and operational instructions.

Why it matters: Loom is designed to outlast any single contributor. The documentation ensures that the research methodology, file naming, and editorial standards remain consistent as the project grows.

How to use it:

• New to Loom? Start with Getting Started.
• Writing a new case study? Read the Loom Analysis Protocol and Naming Conventions first.
• Proposing an ontology change? Check the Ontology Evolution Log for the procedure.
• Want to understand how the site deploys? Read the Git Workflow.

How to customize: Fork the repository, update the documentation to match your own research standards, and use it as the rulebook for your team.

01 Inbox

What it is: A holding pen for unprocessed notes, raw clippings, half-formed ideas, and temporary drafts.

Why it matters: Research generates noise before it generates signal. The inbox prevents raw material from polluting the permanent sections while keeping it accessible for later processing.

How to use it:

• Drop articles, quotes, and rough notes here during active research.
• Process inbox items regularly: either promote them to Literature Notes, Permanent Notes, or Projects — or delete them.
• The inbox should be empty (or nearly empty) at the end of every research cycle.

How to customize: If you work in teams, create subfolders by contributor or by topic (e.g., 01 Inbox/Immigration, 01 Inbox/Health Policy).

02 Literature Notes

What it is: Sourced material — book summaries, article annotations, interview transcripts, and research references. Each note is tied to a specific source and follows a standardized template.

Why it matters: Loom does not start from theory and look for examples. It starts from cases and builds theory. Literature notes are the raw material of that inductive process. They ensure that every claim in the ontology and every finding in a case study can be traced to a documented source.

How to use it:

• Reading a book relevant to governance? Create a Literature Note using the template.
• Literature notes should be source-bound, not concept-bound. One note per book/article, not one note per idea.
• Link Literature Notes to Permanent Notes and Case Studies using [[wikilinks]].
• Use the Literature Notes Index to browse by author, domain, or concept.

How to customize: Add fields to the template that match your discipline — e.g., “Methodology” for quantitative studies, “Geographic Scope” for area studies, “Policy Domain” for applied research.

03 Permanent Notes

What it is: The analytical core of the project. This folder contains the ontology definitions, case studies, cross-case matrices, and conceptual frameworks that constitute Loom’s intellectual architecture.

Why it matters: Permanent notes are where raw research becomes structured knowledge. A Literature Note asks: What did Fukuyama say? A Permanent Note asks: What is Governance Fragility, and which cases prove or disprove its existence?

How to use it:

• Case Studies (PL-4xx): Each follows a ten-stage diagnostic protocol. Read them as models, not just content. If you are writing a new case, copy the structure of an existing one.
• Ontology (PL-1xx): These are the canonical definitions. Do not edit them casually. If a concept needs revision, log the proposal in the Ontology Evolution Log and provide evidence from at least two cases.
• Cross-Case Matrices (PL-5xx): Use these to compare cases side-by-side. They are living documents — update them when new cases are added.
• Frameworks (PL-2xx): The EROS Framework, Dependency Chain Mapping, Capacity Assessment Rubric, and other methodological tools live here.

How to customize:

• Add new case studies by following the PL-4xx numbering convention.
• Propose new ontology concepts by creating a candidate note (status: Candidate) and linking it to at least two case studies.
• Build new cross-case matrices by identifying a dimension not yet mapped (e.g., “Cases by Administrative Tradition” or “Cases by Degree of Private Sector Involvement”).

04 Projects

What it is: Active intervention designs, applied research, and public-facing outputs that extend Loom’s analytical tools into specific policy domains.

Why it matters: Loom is not just a diagnostic tool. It is a design tool. The Projects folder is where analysis becomes architecture — where the question shifts from What went wrong? to What would it take to build something better?

How to use it:

• ICE Abolition Architecture (PL-600): A multi-lever governance design for dismantling an enforcement agency. Read it as an example of how Loom concepts translate into intervention design.
• Future projects might include: climate transition governance, healthcare system redesign, electoral integrity architecture, etc.
• Each project should reference the ontology and case studies that inform its design.

How to customize:

• Start a new project by creating a project charter (scope, concepts applied, expected outputs, feasibility assessment).
• Use the EROS Framework as the default methodology, but adapt the stages to the domain.
• Projects should produce at least one public-facing output (white paper, policy brief, or manifesto) and one internal analytical product (dependency map, actor inventory, or risk model).

05 Outputs

What it is: Public-facing writing, manifestos, white papers, and other documents intended for audiences outside the core research team.

Why it matters: Research that stays in the vault does not change the world. The Outputs folder is where Loom speaks to policymakers, journalists, organizers, and citizens.

How to use it:

• Autopsy of a Vanishing (PL-000-INTRO): The public introduction to Project Loom. It is meant to be read by people who have never heard of governance ontology.
• Future outputs might include: op-eds, testimony, white papers, or multimedia presentations.
• Outputs should link back to the ontology and case studies, but they should not require the reader to understand the full framework.

How to customize:

• Write outputs for specific audiences. A white paper for legislative staffers should look different from a manifesto for organizers.
• Use the Outputs folder to test whether your analytical concepts can survive translation into plain language. If a concept cannot be explained to a non-specialist, it may not be ready for the ontology.

06 Archives

What it is: Deprecated notes, superseded versions, and material that is no longer active but retained for historical reference.

Why it matters: Research is iterative. Concepts get refined, cases get corrected, frameworks get rebuilt. The archive preserves the intellectual history of the project without cluttering the active workspace.

How to use it:

• When an ontology concept is deprecated, move its note to the Archive and create a SUPERSEDED_BY relationship in the Neo4j graph (if using the knowledge graph).
• When a case study is updated, archive the old version and note the changes in the Change Log.
• The Archive is read-only. Do not edit archived notes.

How to customize: Add a deprecated tag or frontmatter status to archived notes so they are excluded from site navigation and Dataview queries.

99 Templates

What it is: Standardized templates for Literature Notes, Case Studies, Project Charters, and other recurring document types.

Why it matters: Consistency is a research tool. Templates ensure that every case study contains the same analytical stages, every literature note contains the same metadata, and every project charter contains the same feasibility dimensions.

How to use it:

• Create a new Literature Note? Use the Literature Note Template.
• Create a new Case Study? Use the Case Study Template.
• The templates include Templater syntax for auto-populating dates and IDs. They are ignored by the Quartz build (they do not appear on the live site).

How to customize:

• Add fields to templates as your research needs evolve.
• If you are not using Obsidian, the templates are still useful as checklists. Copy the structure into whatever note-taking system you use.

How to Use This Site

If you are a first-time visitor

Read the homepage (this page) and the Autopsy of a Vanishing. Browse the Case Studies to see the analytical method in action. Check the Dashboard for a bird’s-eye view of the project’s scope and status.

If you are a researcher

Start with the Ontology (PL-1xx) to understand the conceptual vocabulary. Read 2–3 Case Studies from different domains to see how the concepts are operationalized. Use the Cross-Case Comparison Matrix (PL-501) to identify patterns and gaps. Propose a new case study or ontology revision using the protocols in 00 Documentation.

If you are a policy professional

Read the EROS Governance Analysis Framework (PL-202) to understand the six-stage methodology. Review Case Studies in your domain (e.g., healthcare, environment, immigration). Explore Projects (PL-6xx) to see how Loom concepts translate into intervention design. Adapt the Capacity Assessment Rubric (PL-204) to your own policy context.

If you are an organizer or advocate

Read the Autopsy of a Vanishing to understand Loom’s political stance and analytical approach. Review Case Studies that align with your campaign domain. Use the Dependency Chain Mapping methodology (PL-203) to identify the veto points and bottlenecks that will determine whether your demands can be executed. Review the ICE Abolition Architecture (PL-600) as a model for multi-lever intervention design.

If you are a technologist or designer

Review the Neo4j Knowledge Graph Schema (PL-800) to understand how Loom’s relational data is structured. Explore the Dashboard and Cross-Case Matrices as examples of data presentation. Consider building tools that ingest Obsidian vaults into graph databases, generate dependency visualizations, or create interactive case study explorers.

The site is built with Quartz — a static site generator for Obsidian vaults. The entire codebase is open source and available on GitHub.

How to Customize & Extend Project Loom

Project Loom is designed to be forked, adapted, and extended. Here is how to make it your own:

1. Fork the Repository

The entire site is open source:

• GitHub: https://github.com/loom-research-system/loom-research-system
• Live Site: https://loom-research-system.github.io/loom-research-system

Fork the repo, rename it, and deploy your own instance to GitHub Pages. The Quartz build system will handle the rest.

2. Adapt the Ontology

The ontology is not a catechism. It is a working hypothesis. To modify it:

• Log the proposed change in the Ontology Evolution Log.
• Provide evidence from at least two case studies (or one case study and one external empirical source).
• Update the Cross-Case Comparison Matrix to reflect the change.
• Update the Neo4j Knowledge Graph (if you are using it) to reflect new nodes or relationships.

3. Add Case Studies

New cases should:

• Follow the ten-stage diagnostic protocol documented in the Loom Analysis Protocol.
• Use the Case Study Template (PL-4xx).
• Be linked to at least two existing ontology concepts.
• Include a Change Log documenting revisions.

4. Build New Projects

Projects are where Loom concepts meet real-world intervention design. A new project should:

• Reference the ontology and case studies that inform its design.
• Use the EROS Framework as the default methodology.
• Produce at least one public-facing output and one internal analytical product.
• Include a Feasibility Assessment using the rubric in PL-204.

5. Deploy the Knowledge Graph

The Neo4j Knowledge Graph (PL-800) is optional but powerful. It enables:

• Relationship analytics across cases, actors, and concepts
• Pattern detection in governance failure and success
• Intervention simulation (“what happens if we remove this node?”)
• Cross-domain comparison via graph algorithms

To deploy:

• Sign up for Neo4j Aura (free tier available).
• Seed the graph with the Concept nodes from PL-800.
• Ingest case study data using the Python ingestion pipeline (pseudocode provided in the schema).
• Run Cypher queries to test hypotheses and discover patterns.

6. Customize the Site

The site is built with Quartz v5.0.0 and deployed to GitHub Pages. To customize:

• Edit quartz.config.yaml to change the site title, base URL, and plugin settings.
• Edit quartz.layout.ts to change the page layout and component structure.
• Add custom CSS in quartz/styles/custom.scss.
• Add custom components in quartz/components/.

The site ignores 99 Templates, .obsidian, and private folders — add more ignore patterns as needed.

A Note on Method

Project Loom does not start from theory and look for examples. It starts from cases and builds theory. Every concept in the ontology must earn its place by explaining something that actually happened. If a concept cannot be operationalized — if it cannot be tested against a documented case — it does not belong in the framework.

This is empirical research, not opinion journalism. The goal is to build tools that are useful, not to build a brand that is popular.

Explore

Dashboard | Getting Started | Case Studies | Projects | Literature Notes | Ontology | EROS Framework

---

Project Loom investigates why policies fail even when well-intentioned, using cross-case analysis of systemic breakdowns.

Built with Quartz v5.0.0. Source available on GitHub.