What the review states mean
library is a completed manual review against the provider documents the pack names in its sources, with every exclusion stated in the pack's notes — and the records document manual sign-off of that review. draft is work in progress — the output of an import, or a review whose evidence or sign-off is not finished: installable, but not a reviewed-library release, and excluded from the distributable manifest; installation does not resolve a draft's named blockers. A pack that declares no review block at all renders as unreviewed, because a missing review must never read as approval. A pack review is not a vendor or examiner attestation.
Review state and artifact status are different facts. The first is a documentation-review declaration. The second is whether the pack's exact bytes match the digest-bound distribution manifest compiled into the binary: against an unchanged manifest entry, different bytes report modified and drop out of the distributable set; an identity absent from the manifest reports "not in manifest". Deployment apply separately checks the files against its plan. Neither check authenticates approval.
The two phases
Phase 1 — evidence. Every named source is attempted live — retrieved, replaced with a retrievable equivalent where a page fails, or recorded as blocked — and every claim the pack makes — endpoint, method, actions, tier, data class, credential lifecycle, exclusions — is compared against the retrieved documents where evidence was available, discrepancies are fixed in the pack in the same session, and the outcome — including unresolved gaps — is written to a per-pack record (packs/review/records/<provider>.md in the repository). This phase may be agent-assisted: retrieval and comparison are recordable labor, and the record is what makes the labor checkable. A record that names no retrieved document is not a review. Review does not independently verify provider behavior.
Phase 2 — sign-off. The reviewer reads the record, checks what it names, and records sign-off by running packs/review/promote.py with a reviewer identifier. The run records the sign-off in the record — approver, date, and the SHA-256 of the exact bytes approved — flips the state, and pins provider, version and digest into the binary's manifest. The tool records a supplied reviewer identifier and the approved pack digest; it does not authenticate the reviewer, prove human participation, or independently enforce separation from agent assistance. Agent assistance with the evidence phase is disclosed here and in the gate README. Thirteen packs predate this gate; all thirteen have since received their first gated approvals through this tooling — okta and postgres on September 22, 2026, the other eleven on September 23, 2026 — each evidence record declaring the pre-gate pin history in a ## Legacy baseline section.
The gate's work queue is the generated checklist (packs/review/CHECKLIST.md): for every draft pack, the sources to retrieve, the per-capability claims to verify, the credential-contract claims, and the exclusion inventory to confirm. The checklist is generated from the packs and never hand-edited. The checklist, the gate README, the promotion tool, and one evidence record per reviewed pack live in the source repository at packs/review/ — packs/review/CHECKLIST.md, packs/review/README.md, packs/review/records/<provider>.md, available with the evaluation materials — and ship embedded in the release binary's asset tree at the same paths: the embedded set is a byte-for-byte mirror of the repository files, and the asset tests (TestEveryRepositoryDeployableIsEmbedded and TestTheEmbeddedSetMatchesTheRepository in aaes/internal/assets/assets_test.go) detect differences between repository files and embedded assets when run — passing them establishes matching bytes, not authenticated approval or mandatory release enforcement.
Where the gate stands today
On September 21, 2026 the evidence phase was executed for all 87 packs then in draft. The records document retrieval attempts, comparisons where evidence was available, corrections, and unresolved gaps: where a page failed (JavaScript-only shells, gated portals, dead links), a retrievable equivalent replaced it and the substitution is recorded in the pack's record, or — where no equivalent exists — the pack was held. Review does not independently verify provider behavior. Every comparison outcome is written down, one record per pack. 35 packs received same-day corrections (endpoint paths, verb and tier placements, data-class raises, credential-lifecycle corrections); each fix is listed in its record.
The same packs also went through additional model-assisted reviews by GPT-6 Astra across several batch rounds; the verbatim requests and responses are retained in the repository under .tmp/, and each round's findings and the disposition of each are recorded round by round in the CHANGELOG, including rounds covering the gate itself — the promotion tooling, the evidence records, and this page's own claims. These reviews produced findings recorded in the retained transcripts and CHANGELOG; they are not independent assurance, certification, or proof of operational behavior. The custody-model review the capability-library plan gates any authentication mode on — issuance authority and delegation, scope, audience, TTL, refresh ownership, revocation, executor access, bypass paths — has recorded dispositions for the cohort of 14 packs that declared it open in the September wave; promoted packs record custody-review dispositions, including accepted limitations and deployment obligations, in their approval blocks. That cohort does not exhaust all open custody reviews: Workday, still draft, retains unresolved custody blockers — issuance authority and delegation chain, minimum functional scopes and ISU domain-security mapping, token audience, actual TTL, executor access and bypass paths, and plan-gate conformance — named in its notes and credential note.
The outcome, honestly split: 90 packs carry the library state — the 77 the accountable reviewer signed off on September 22, 2026 after reading the evidence records, and the thirteen packs that predate this gate, each since first-gated through this tooling after a full evidence review (okta and postgres on September 22, the other eleven on September 23, 2026) — every gated sign-off a recorded promote.py run binding approver, date and the approved bytes' SHA-256 in the pack's record and the binary's manifest — and 10 remain draft on named gaps. The records document manual sign-off. The tool records a supplied reviewer identifier and the approved pack digest; it does not authenticate the reviewer, prove human participation, or independently enforce separation from agent assistance.
The 10 packs held on named gaps
Each held pack names its blocker in its notes and its record, and each blocker is a recorded gap — not a waived check:
- airbase — invite-only API documentation; no operation semantics retrievable.
- five9 — the authoritative VCC REST guide is login-gated; unofficial corroboration only.
- genesys — the developer reference renders as a JavaScript-only shell; corroborated via Genesys's official SDK sources, token-revocation cut-off unestablished.
- mailchimp — campaign-send corroborated at section-index level only; the operation page itself was not retrievable.
- redis — two blockers: Redis Cloud authenticates every request with two headers and the pack's declared single-header injector cannot place them (a wiring gap, not only a documentation gap), and the full API reference is a client-side Swagger UI that could not be retrieved verbatim.
- sentinelone — first-party API documentation is console-gated; capabilities are corroborated only by third-party connector documentation.
- wiz — documentation rate-limited; one capability corroborated by nothing retrieved.
- workday — the REST Services Directory is gated behind a customer login; three capabilities whose exact methods and paths could not be established were removed. Two reads remain, supported by public provider examples — not live-tested; promotion is blocked on tenant-specific operation confirmation and the custody questions named in the pack's notes.
- zip — Zip's own help center states API documentation is available only through an authenticated session, and no public specification exists; no endpoint or credential mechanic could be established.
- zscaler — corroborated via Zscaler's official SDK documentation, but no retrieved source prints the raw paths and methods.
These ten drafts are installable, but are not reviewed-library releases and are excluded from its manifest. Installation does not resolve their named blockers. They ship in the repository and render with the draft badge everywhere they appear. Each is promotable only after a successful review against retrievable documents, any required fixes, and the recorded sign-off — document availability alone is not promotion.
What the gate does not establish
No pack — library or draft — is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant. The library badge means a completed review against the dated provider documents the pack names, approved by the accountable reviewer, nothing more. A dated URL is a reference to a mutable page: the retrieval date names what the review claims to have seen, and a later reader can re-fetch the page to check the claims against the current document — rechecking is possible, exact historical reproduction of what was retrieved that day is not. Where a claim needs stronger evidence, the records say so. Registration is not connectivity: credentials, adapters, routing, policy, and deployment validation remain the deployment's responsibility.