Skip to main content

​
Core approach

The library publishes generated reference pages rather than raw-source-only pages. Each public section page is written to behave like a commentary-heavy textbook chapter with direct traceability back to the source standard.

​
Mental model

The workflow is built around five objects:
  1. A source object created from the PDF
  2. An ingestion brief that explains what the PDF contains and how it should be drafted
  3. A public framework hub when the source is a bundle such as FRS 102
  4. A canonical standard page for the downstream section-standard
  5. Supporting material such as appendices, illustrative examples, or basis-for-conclusions content
The PDF is never the public page. It is only the input container for the source object.

​
Intake patterns

There are two intake patterns.
  • Standalone standard: one PDF becomes one source object, one brief, and one canonical page.
  • Framework bundle: one PDF becomes a parent bundle source object and parent brief first, then child section-standard objects and child briefs.

​
Content pipeline

1

PDF intake

The original supplied PDF is stored in the ignored sources/inbox/ directory. If a PDF is a framework bundle with multiple official section-level reading units, it is split conceptually before drafting begins.
2

Parent or standalone source object

The first source object records the supplied PDF itself. For a framework bundle, that first object is the parent bundle source object. It records the official code, title, framework, jurisdiction, material type, paragraph-reference quality, and intended public path.
3

First ingestion brief

Every supplied PDF requires an ingestion brief in sources/briefs/ before drafting starts. For framework bundles, the parent brief defines the split map, child inventory, source-location quality, and proposed hub structure before any child drafting happens.
4

Child source objects and child briefs

If the parent brief splits the PDF, one child source object is created per official downstream section-standard. Each child that will be drafted next gets its own child brief.
5

Public drafting

Framework bundles produce a hub page plus child section-standard pages. Standalone standards produce one canonical page. The narrative stays blended and interpretive rather than a verbatim rewrite, but it remains traceable.
6

Review gate

Before publication, the relevant public page is checked for ambiguous interpretations, unresolved definitions, missing source anchors, and mislabeled supporting material. A page should not be published if it cannot show clear traceability or if the commentary overstates what the source supports.
7

Publish or update

If the source is a new standard, a new canonical page is published. If the source is a framework bundle, the hub remains the public entry point and live child section pages are added beneath it. If the source is an amendment, the existing canonical page remains the public page and its history or status is updated instead of creating a public version page in v1.

​
Source object contract

Every incoming PDF should eventually produce one or more source objects with the following minimum contract:
  • source_id
  • source_kind
  • source_pdf
  • framework
  • jurisdiction
  • standard_code
  • official_title
  • material_type
  • mandatory_or_supporting
  • paragraph_reference_quality
  • public_page_path
Framework-bundle and child-section objects may also carry:
  • parent_source_id
  • source_location
  • derived_page_range
Templates for this live in sources/templates/.

​
Ingestion brief contract

The ingestion brief is required before drafting starts. It should capture:
  • official code and official title
  • framework and jurisdiction
  • what the PDF contains
  • whether it must be split
  • a section map
  • paragraph mapping status
  • amendment or history implications
  • a proposed hub-page outline for bundle parents
  • a proposed child-page inventory and ordering when the PDF is a bundle
  • a proposed canonical page outline for the child section page
  • an ambiguity log
  • a missing-reference log

​
Commentary and examples

The public section page is allowed to interpret, comment, and clarify. It is not limited to a plain-language restatement. That said, commentary must stay traceable to the source and should be written as part of one blended canonical narrative. Selective practical examples are allowed where they clarify a hard judgment call or a recurring misunderstanding. They should not become mandatory filler on every page.

​
Supporting material

Appendices, illustrative examples, basis-for-conclusions content, and other non-mandatory material can be used to enrich commentary. When that happens, the page should label those moments clearly as supporting or interpretive rather than presenting them as if they were mandatory requirements. Supporting material can attach to a parent bundle or to an individual child section-standard.

​
What every generated page must include

  • At a glance
  • Who this applies to
  • Core principles
  • Recognition / measurement / presentation / disclosure where relevant
  • Effective date and transition
  • Amendments and status
  • Related standards
  • Source references

​
Source traceability

The library uses paragraph-level references rather than broad document-level citations. That makes it possible to see where a generated explanation came from without publishing the raw source text itself. If OCR quality, pagination, or paragraph mapping is weak, that issue belongs in the ingestion brief before the page reaches the public review gate. For framework bundles, the parent brief should flag which child sections still need deeper paragraph extraction before drafting.

​
Public boundary

  • Generated summaries are public.
  • Source references are public.
  • Raw standards text is not part of the public documentation surface.
  • Framework hubs are public.
  • Comparison pages are a later layer and should link back to canonical standard pages.

​
Internal working files

The internal workflow lives under sources/:
  • sources/inbox/ for original PDFs
  • sources/splits/ for derived split PDFs and split manifests
  • sources/objects/ for parent bundles, child section-standards, amendments, and supporting-material records
  • sources/briefs/ for parent and child ingestion briefs
  • sources/templates/ for templates
  • sources/examples/ for worked examples