Skip to content

Roll out Beacon product whitepapers and public whitepaper routes across eligible repositories #11

Description

@szmyty

Outcome

Use Pace to bootstrap and maintain a Beacon-based technical whitepaper for each eligible Ego Hygiene product, publishing both durable document artifacts and a stable public whitepaper page such as:

https://identity.egohygiene.io/whitepaper

or the equivalent canonical product-route architecture selected for that repository.

Architecture

product canonical metadata + architecture + evidence
        ↓
Beacon whitepaper profile (#1)
        ↓
product-owned manuscript/content
        ↓
Relay PDF/web publication
        ↓
product site /whitepaper route
        ↓
Observatory freshness/conformance

Beacon owns the reusable publication template and validation contract. Product repositories own product claims/content. Pace owns fleet adoption and drift reconciliation. Relay owns reusable build/publication automation.

Eligibility

Inventory the product fleet and classify repositories as:

  • whitepaper required;
  • whitepaper recommended;
  • optional;
  • not applicable;
  • blocked by missing architecture/evidence/product maturity.

Do not generate meaningless whitepapers for repositories that are purely policy, template, archival, or internal infrastructure unless the product profile explicitly warrants one.

Bootstrap behavior

For each eligible product:

  • consume the versioned Beacon technical-whitepaper profile from beacon#1;
  • derive safe factual metadata from canonical product/Identity sources;
  • create a product-owned manuscript scaffold;
  • link relevant architecture/ADR/evidence sources;
  • preserve explicit placeholders/TODOs for claims that require human authorship/review;
  • never fabricate benchmarks, adoption, outcomes, partnerships, security claims, or research evidence;
  • track Beacon template/profile version.

Whitepaper content model

Support a consistent outline that can be specialized by product, for example:

  • abstract / executive summary;
  • problem/context;
  • product purpose and scope;
  • architecture/system model;
  • design principles;
  • key capabilities;
  • security/privacy/accessibility boundaries;
  • implementation/technical details where appropriate;
  • validation/evidence;
  • limitations and non-goals;
  • roadmap/future work where appropriate;
  • references;
  • version/provenance.

Research-paper projects should consume the separate Beacon research-paper profile rather than being forced into a product whitepaper.

Public site integration

For each published product site:

  • expose a canonical /whitepaper route;
  • link downloadable PDF/PDF-A where supported;
  • expose accessible HTML/web representation;
  • include canonical metadata, sitemap coverage, and Agent-Ready Web/Markdown representation where applicable;
  • show document version, represented product release/source commit, and last-reviewed date;
  • avoid mutable default-branch coupling.

Support both subdomain and path-based product deployments according to the accepted egohygiene.io gateway architecture.

Fleet rollout

Pilot with at least:

  1. Identity — proving identity.egohygiene.io/whitepaper or accepted equivalent;
  2. one developer tool/library;
  3. one product with materially different architecture/content.

After canaries:

  • produce the remaining fleet plan;
  • detect existing papers/technical docs before creating new scaffolds;
  • preserve existing authored material and migrate intentionally;
  • track missing/stale whitepaper state in Observatory conformance.

Acceptance criteria

  • Eligible repositories are classified through an explicit whitepaper applicability profile.
  • Every adopted product consumes the versioned Beacon whitepaper contract rather than copying templates.
  • Product-owned content remains the canonical source for claims.
  • Generated scaffolds never fabricate evidence or product claims.
  • PDF/document and accessible web outputs build through reusable Relay automation.
  • Product sites can expose a stable /whitepaper route.
  • Version, source revision, provenance, and review freshness are visible.
  • Identity and two materially different products prove the workflow.
  • Existing authored whitepapers/docs are preserved or migrated intentionally.
  • Pace can detect missing, stale, blocked, and current whitepaper states across the fleet.

Dependencies / related

Non-goals

  • Auto-authoring final whitepaper claims without review.
  • Treating every repository as a product requiring a whitepaper.
  • Keeping generated PDFs as canonical manuscript source.

Activity

  1. self-assigned this
    on Aug 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions