Excerpt: This article describes the standard architecture for an issue hub page — what sections it contains, what belongs in each, and what distinguishes a publishable hub from a placeholder that should stay unpublished. It is a practical template for anyone building a hub on America’s Plan.
Purpose of this article
The Issue Hubs: What They Are and How to Start One page establishes the three-part framework for a hub: an organization of people, a set of tools, and an accumulation of knowledge. What it does not provide is a section-by-section architecture for the hub home page itself, a standard for what each section should contain, or a clear definition of what makes a hub publishable versus a placeholder that should stay unpublished.
This article fills those gaps. It describes the standard architecture for a hub, section by section, with publication standards for each. Its audience is a facilitator who has decided to start a hub and needs to know how to build it. It builds on the Issue Hubs framework and should be read alongside The Issue Pipeline in Practice: A Worked Example for a sense of how hub content develops over time.
The hub home page
The hub home page is the first thing a visitor sees. Its job is to tell that visitor what the issue is, who it affects, where the work currently stands, and how to get involved or follow along. It is not a deep dive into the problem — that belongs in the issue mapping section. It is an accurate, specific orientation.
Issue statement (required for publication)
Two to four sentences. What is the problem? Who does it affect? What makes it a civic issue rather than a personal one?
The issue statement should be specific enough that a stranger knows what the hub is about and whether they are in the right place.
A weak issue statement: “Media is important to democracy and we need to fix it.” This says nothing about scope, mechanism, or affected parties. A visitor cannot tell from this whether the hub is about national broadcast regulation, local newspaper closures, social media algorithms, or something else entirely.
A strong issue statement: “Local news coverage of city councils, school boards, and county governments has collapsed in most non-metro areas since 2005. Without that coverage, local government operates with reduced public scrutiny. This hub documents the scope of that collapse and works toward plans that affected communities can use to address it.” A visitor who reads this knows what the hub is about, who is affected, and what the hub is trying to do.
Affected parties (required for publication)
A brief description of who is directly harmed by this issue. Not the general public (“everyone”), but the specific people whose daily lives are shaped by the problem — residents of news desert counties, small business owners without coverage, local officials whose decisions go unscrutinized, communities where accountability journalism has disappeared. The Issue Hubs framework establishes that affected parties should lead. The hub home page should name who they are. If the facilitator cannot name the affected parties at publication, that is a signal the hub is not ready.
Current pipeline stage and status (required for publication)
Where is the hub in the issue pipeline? Sentiment, Plan, Pressure, or Accountability — and within that stage, what is the current state? “Sentiment stage: open for contributions — the hub is building a picture of how local government coverage gaps are experienced in different communities” is publishable. “This hub is a testbed” is not. The status should tell a new visitor what they would be walking into and what the hub currently needs from them.
Forum and commons links (required for publication)
Direct links to the relevant forum space and, when live, the commons area for the issue. If the forum space does not yet exist, the hub should not be published until it does. A hub page without a functioning forum link is a dead end — it offers a visitor nowhere to go and no way to contribute.
Contributor note (optional at publication, recommended)
One to two sentences. Who is currently working on this hub, and what kinds of contributors does it need? Anonymity is fine — “one facilitator, currently seeking affected-party contributors from rural and non-metro markets” is sufficient. This signals to a potential participant that someone is holding responsibility and that there is a specific role for them.
The issue mapping section
This section documents what is actually known about the problem. It is the foundation for the Analysis stage of the pipeline and the evidence base for everything that follows.
Problem definition
Not the same as the issue statement on the home page. This is the extended version: the scope of the problem documented with evidence, the populations affected and how, the geographic or demographic variation, the timeline of how the problem developed. This section should be grounded in documented sources, not opinion.
Publication standard: a problem definition that a stranger could read and come away with an accurate understanding of the problem’s scope and mechanism. If it is a paragraph long and vague, it is not ready. The Media Reform issue overview demonstrates what a documented problem definition looks like — specific statistics, named structural causes, identified variation between market types.
Power analysis
Who has authority over this issue? Which institutions are responsible for the conditions producing the harm? Which actors benefit from the current state? This section should name institutions and interests specifically — not “powerful interests” but the specific agencies, corporations, legislative bodies, or officials who have the authority and incentive structure that the hub needs to work with or against. A power analysis that does not name anyone is not useful for plan-building.
This section will often be incomplete at publication. It is acceptable to publish with a partial power analysis that names what is known and flags what needs more work. But something must be there. An empty power analysis section is a signal that the hub has not yet done the analysis work that plan-building requires.
Affected party stories
Documented accounts from people who live with the consequences of the issue — the output of the Sentiment stage. They should be specific, attributed (even if pseudonymously), and grounded in particular experiences rather than general descriptions. What Is Public Sentiment, and Why Does It Matter More Than Polls? explains why this kind of testimony matters and what it is meant to produce.
Publication standard: this section can be empty at the start of the Sentiment stage. It is the purpose of the Sentiment stage to fill it. A hub can publish with a note that this section will be filled through the forum’s Sentiment stage work — but only if the forum space is active and a facilitator is holding it.
The planning section
This section documents the work of the Plan stage. It should not exist in published form until the hub has completed enough of the Sentiment and Analysis stages to have a grounded basis for proposals. Publishing proposals before the problem is adequately documented risks building on the wrong picture.
Proposals under development
Specific proposals that the hub is evaluating. Not “we think something should change” but named proposals with enough specificity to be discussed, critiqued, and eventually tested. For each proposal, the entry should state: what it proposes to change, which institution would need to act, what the expected mechanism is — how does this change actually produce the improvement claimed — and what a realistic implementation timeline looks like. How to Facilitate a Deliberative Discussion covers how proposals emerge from the deliberative process; this section is where they are recorded once they exist.
Trade-offs
For each proposal, what does it cost? What are the risks? Who would resist it and why, and on what basis? This section is what makes the planning section useful rather than promotional. A set of proposals without trade-offs is advocacy dressed as planning. Civic work requires naming costs honestly, including costs that are unfavorable to the hub’s preferred outcome.
Community input record
What has the deliberative process produced? What has been established through forum work, what remains contested, what has been revised based on new information? This is the living record of the plan-building process — not a polished final document but an honest account of where the thinking currently stands and what moved it.
The accountability section
This section tracks what institutions have committed to and what the record shows. It is often empty for most of a hub’s early life, and that is expected — commitments come after sustained pressure, not before. But the section should exist and be visible from early in the hub’s structure. Its presence tells participants that accountability tracking is built into the architecture from the start, not added after the fact.
What has been promised
A documented list of commitments made by responsible institutions. For each entry: what was committed to, when, by whom, under what conditions, and by what deadline. Each entry should have a source — a public statement, a vote record, a legislative text, a formal policy document. Undocumented commitments do not belong in this section. The Accountability Stage covers the function of this work in the pipeline.
What the record shows
For each commitment, what actually happened? Was it implemented as promised, partially, or not at all? This section updates over time as commitments come due. It is the section that closes the loop — or documents that the loop has not closed. A commitment that has come due and not been verified should be flagged. A declared win is not a verified outcome, and this section is where that principle becomes operational.
The resources section
Links to the commons area for the issue (when live), relevant external sources used in the hub’s documentation work, definitions used by the hub, and reusable materials produced by the hub’s work — templates, research summaries, guides, checklists. This section grows over time. At publication, it may contain only a few external links, and that is acceptable. Its function is to aggregate the material that makes the hub’s work reusable by others.
Publishable vs. stub: the standard
The site currently lacks an explicit standard for this. A published hub that is actually a dead placeholder damages the site’s credibility and wastes the time of anyone who follows a link to it. The cost of a premature publication is higher than the cost of waiting.
A hub is ready to publish when all seven of the following are true:
- The issue statement is specific enough that a stranger knows what the hub is about and whether they are in the right place.
- The affected parties are named.
- The current pipeline stage and status are accurately stated, including what the hub currently needs from contributors.
- A functioning forum space exists and is linked from the hub page.
- The problem definition section contains at least a basic documented account of scope and mechanism — specific enough to be checked, not just asserted.
- The power analysis names at least the primary institutions with authority over the issue.
- At least one facilitator is actively holding responsibility for the hub and will respond to new participants.
A hub should stay unpublished — or be explicitly labeled “stub: not yet active” — when:
- The issue statement is vague or aspirational without documentation.
- No functioning forum space exists.
- No one is holding facilitator responsibility.
- The hub page exists primarily as a placeholder for a future intent rather than a record of current work.
The label “stub: not yet active” is a legitimate state for a hub to be in — it signals that the issue exists on the platform and that someone intends to build it out, without misleading a visitor into thinking they can participate in something that isn’t yet operational. What is not acceptable is a published hub page with no status disclosure that turns out to be a dead end.
A note on the Media Reform hub: it was published as an explicitly labeled testbed for a single-person build learning how hubs work. That was a legitimate early-stage decision. The standard in this article applies to hubs built by facilitators using the platform rather than building it. For those hubs, the seven-point standard should be applied before the hub goes live.
This article was researched and drafted with AI assistance under human review. See our full AI and editorial practices.