Skip to main content

Boost Admission Pack

Use this page when you need to explain the Boost Admission Pack in a public-safe way without depending on repo hosting, branch links, or reviewer-only context.

Download the canonical sources​

Owner model​

  • Fabric owns the admission contract, dry-run schema, review order, and final verdict semantics.
  • jhf-docs may explain that model in public-safe language, but it does not approve admission and must not fork the contract meaning.
  • downstream partner or product repos own their own manifest, docs, verify path, and runtime evidence.

What the admission pack is for​

  • It gives a partner one exact request packet instead of a loose pile of onboarding links.
  • It defines what evidence must exist before a Boost or adjacent tool can be reviewed.
  • It keeps the review fail-closed: missing identity, missing docs, missing verify evidence, or contradictory runtime claims block the request.
  • Public understanding of this packet must remain valid even if repo hosting is temporarily unreachable.

What the packet contains​

  • one onboarding brief that explains the tool, its capability boundary, and its runtime posture
  • one dry-run request that declares identity, lifecycle, producer and consumer usage, and verify targets
  • one docs and evidence bundle that lets another reviewer repeat the readback without private context

Minimum admission packet​

  • one canonical tool identity with stable capability class, runtime kind, lifecycle stage, and release channel
  • docs for tool profile, integrations, capabilities, API, and OSS inventory where the selected mode requires them
  • explicit producer declarations for the contract families the tool publishes
  • explicit consumer declarations for the contract families the tool consumes
  • compatibility posture, lifecycle posture, and verify metadata
  • one completed dry-run payload in the current canonical request shape

What the dry-run must declare​

  • the requested lifecycle stage and release channel
  • the exact contract families the tool produces and consumes
  • the verify entrypoint another reviewer can execute
  • the readiness or live targets that must be read back
  • the known limits that should stay fail-closed unless later admitted

Public-safe declaration shape​

A reader should be able to name the required declaration fields from this page alone:

  • identity: tool name, owner, capability class, runtime kind, and release channel
  • lifecycle request: requested stage, intended promotion or adoption target, and any explicit rollout boundary
  • contract usage: produced families, consumed families, and any families that are intentionally out of scope
  • verification: exact verify command or procedure, readiness surfaces, and live readback surfaces
  • limits: unsupported environments, excluded behaviors, and fail-closed conditions

What a partner should prepare​

  • one short capability summary that explains what the tool does and what it explicitly does not do
  • one exact verify path that another reviewer can repeat without hidden local steps
  • one compatibility statement that names the supported runtime, release channel, and known boundaries
  • one evidence packet that stays readable even when the source repo or review system is temporarily unavailable

Review order​

  1. Receive the completed admission packet and dry-run payload.
  2. Validate the payload shape and required declarations.
  3. Cross-check docs coverage, compatibility posture, and contract-family usage.
  4. Execute the declared verify path and read back the named readiness surfaces.
  5. Treat any contradiction between manifest, docs, and live evidence as blocking drift.

What this page does not replace​

  • It does not replace the Fabric-owned dry-run schema or governance surfaces.
  • It does not allow jhf-docs to approve admission on its own.
  • It does not turn a prose page into a green review verdict.
  • It does not make generic API route summaries sufficient for admission review.

Verification​

This public page is healthy when a reader can download the canonical packet, understand the required declaration shape, and follow the fail-closed review order without needing a branch link, a repo browser, or reviewer-only context.

Next paths​