Skip to main content

Admission Contract Governance

Use this page when you already know the question is admission and need the exact Fabric-owned contract surfaces, template, and fail-closed review order.

Exact source surfaces​

  • POST /api/v1/tools/admission/dry-run
  • POST /api/v1/contracts/compatibility/check
  • GET /api/v1/contracts/matrix
  • GET /api/v1/contracts/docs-standard
  • GET /api/v1/contracts/admission-governance
  • GET /api/v1/identity/contracts/surface-admission

Canonical admission objects​

Even without a repo browser, the public-safe model is exact enough to describe the required objects:

  • one dry-run request object that carries identity, lifecycle request, contract usage, verification targets, and fail-closed boundaries
  • one docs-evidence object that points at tool profile, integrations, capabilities, API, OSS inventory, compatibility posture, and verify metadata
  • one readiness object that names the live or readiness surfaces another reviewer must read back

What the reviewer must be able to confirm​

  • the candidate has one stable tool identity, capability class, runtime kind, release channel, and lifecycle stage
  • producer and consumer declarations are explicit instead of implied by prose
  • the docs bundle includes tool profile, integrations, capabilities, API, OSS inventory, compatibility posture, and verify metadata
  • the declared verify path can be repeated by another reviewer without hidden local knowledge
  • the live readiness targets are readable and do not contradict the written posture

What the dry-run payload must cover​

  • identity and classification
  • contract-family producer and consumer usage
  • compatibility posture and lifecycle posture
  • verify entrypoint plus readiness readback targets
  • known boundaries, exclusions, and fail-closed conditions

What is mandatory before review can go green​

  • canonical tool identity and capability class
  • repo-owned docs entrypoint plus tool-profile, integrations, capabilities, API, and OSS inventory docs
  • explicit producer and consumer declarations
  • compatibility mode and lifecycle posture
  • repo-local verify entrypoint, readiness surface refs, and live verification target
  • checklist verdicts for every mandatory review item

Why API Surface Map alone is insufficient​

API Surface Map helps a reader classify route families, but it does not carry the partner payload shape, checklist verdict grammar, or fail-closed admission order. Admission review must always return to the Fabric-owned schema, governance surfaces, and dry-run template.

Review order​

  1. Validate the completed payload against the dry-run input schema.
  2. Check compatibility posture against the compatibility-check surface.
  3. Cross-check required family usage against the producer/consumer matrix.
  4. Cross-check required docs sections against the docs standard.
  5. Execute the declared verify entrypoint and read back the readiness targets.
  6. Treat any contradiction between manifest, docs, and live surfaces as blocking drift.

Next paths​