B2BEA.org Rebuild route-customization-review

Full legacy body rendered for humans

B2BEA.org Route Customization Review

Source of record: RedKey local project artifact draft.

• Project: B2BEA.org Rebuild
• Project ID: a820dd0c-6cef-4133-bfbd-d802fd806e44
• Artifact: route-customization-review
• Version: 1
• Status: draft
• Generated: 2026-05-08

Purpose

Close the open page-template-spec gap: mark which V1 routes are allowed to remain custom/signature and which must normalize to reusable B2BEA design-system page families.

Default Rule

All V1 routes use reusable B2BEA design-system page families unless explicitly marked as a custom exception here or in a future approved route override.

Approved Custom Candidates

| route_or_family | status | rationale | constraints |

| --- | --- | --- | --- |

| / | approved_custom | Home is the primary brand/storytelling surface and may carry campaign-level composition. | Must use official logo, metadata, responsive QA, accessibility, analytics, and no private-route leakage. |

| Major campaign/resource landing pages | candidate_custom | Some high-value campaign resources may need custom storytelling beyond standard templates. | Each page must declare owner, route, metadata, asset bundle, preview evidence, and rollback path. |

| Signature editorial features | candidate_custom | A small number of editorial pieces may merit custom layouts. | Must not become the default blog/resource detail pattern. |

| Approved custom HTML imports | candidate_custom | Publishing model allows custom imports for special pages. | Governed by custom-html-import-spec. |

Routes That Must Normalize

| family | routes | reason |

| --- | --- | --- |

| Directory indexes | /agencies, /consultants, /distributors, /exchange, /leaders, /manufacturers, /people, /software-providers, vendor category routes | Shared filters/cards/search should not drift page by page. |

| Standard marketing pages | /about, /contact, /how-we-use-ai, /join, /services, /vendor-application, /vendor-membership | Structured public pages need consistent page headers, sections, CTAs, and forms. |

| Editorial indexes | /blog, /insights, /podcast | Listing/search/filter layouts should be reusable. |

| Standard editorial details | /blog/:slug, /podcast/:slug, /authors/:slug | Default article/podcast pages use shared editorial detail contract unless separately marked signature. |

| Resources indexes/details | /resources, /guides, /reports, /case-studies, and details/downloads | Gating/download states must be consistent and testable. |

| Course pages | /courses, /courses/:slug, lesson/module routes | Entitlement and learning states require shared contracts. |

| Events/jobs | /events, /events/:slug, /careers, /careers/:slug | Status and filter states should be reusable. |

| Auth/account | /login, /signup, /confirm-email, /checkout, /upgrade, /account utilities | Auth state and errors must be consistent. |

| Admin/member/vendor/company | all private workspace routes | Operational surfaces must use compact design-system layouts, not marketing heroes. |

| Maturity assessment | /assessments/maturity/* | V1 special flow, but still reusable maturity-assessment pattern, not arbitrary custom pages. |

Required Marker

Every route in the implementation route registry must include:

{
  "route": "/example",
  "page_family": "standard_marketing_page",
  "surface": "public_site",
  "custom_treatment": "none",
  "custom_reason": null,
  "qa_profile": "standard_public"
}

Allowed custom_treatment values:

• none
• home_custom
• campaign_custom
• signature_editorial
• custom_html_import

Acceptance Criteria

• No implementation route can silently become custom.
• All custom routes have an explicit treatment, owner, QA profile, and metadata obligation.
• Standard reusable families are the default for migration sizing.
• The route registry can be tested for missing custom markers.