Skip to content

ADOPTION_TRIAL_PROTOCOL.md

Latest commit

 

History

History
119 lines (80 loc) · 4.03 KB

ADOPTION_TRIAL_PROTOCOL.md

File metadata and controls

119 lines (80 loc) · 4.03 KB
Raw

Adoption Trial Protocol

Purpose

This protocol gives external maintainers a low-friction way to test the Agentic Enterprise Readiness Profile without claiming adoption, endorsement, certification, or foundation affiliation.

Use it when a maintainer wants to answer a narrow question:

Does this profile help us expose the evidence an enterprise reviewer would need before trusting or extending our agentic AI repository?

Current public intake issue:

Current release:

Trial Modes

Mode Timebox Output
read-only review 30-60 minutes issue comment or checklist feedback
branch trial 1-3 hours branch with draft AGENTS.md, boundary model, or readiness JSON
maintainer review 1-2 review cycles maintainer feedback on whether the profile is useful, too heavy, or misaligned

A trial is not adoption. Adoption should be listed only after the maintainer explicitly asks to be listed in docs/ADOPTION_REGISTRY.md.

Fastest First Trial

  1. Pick one repository or one agentic workflow.
  2. Pick one evidence artifact: AGENTS.md, boundary model, readiness JSON, audit/observability, OSS fallback, or validation proof.
  3. Compare it with one example from the 16-repository testbed.
  4. Comment in the intake issue with one useful part, one heavy part, and one adoption blocker.
  5. State explicitly whether the repository can be listed publicly as trial evidence.

Minimal Read-Only Trial

Review these files:

  • README.md
  • PROFILE.md
  • docs/REVIEWER_QUICKSTART_16_TESTBED.md
  • docs/ADOPTER_GUIDE.md
  • templates/AGENTIC_BOUNDARY_MODEL.md
  • one flagship example in examples/

Answer:

  1. Which evidence categories already exist in your repository?
  2. Which evidence categories would be too heavy?
  3. Which missing category would be most useful to add first?
  4. Would a maintainer accept a small PR adding a boundary model or readiness JSON?
  5. Does any wording imply endorsement or certification too strongly?

Branch Trial

Create a non-default branch in your repository and add one or more draft artifacts:

  • AGENTS.md
  • docs/AGENTIC_BOUNDARY_MODEL.md
  • agentic-readiness.json

Keep the branch scoped. Do not rename the project, change runtime behavior, or add production claims.

Recommended branch name:

trial/agentic-readiness-profile

Trial Evidence To Share

When opening an issue in this repository, include:

  • repository link
  • branch or PR link, if any
  • which trial mode you used
  • which profile files you reviewed or added
  • what was useful
  • what was too heavy
  • what was missing
  • whether the maintainer wants to be listed as trial evidence

Listing Rules

The adoption registry can list a trial only when:

  1. A public maintainer or contributor provides a link.
  2. The repository or branch is public.
  3. The listing does not claim production readiness.
  4. The listing does not claim AAIF or Linux Foundation endorsement.
  5. The maintainer agrees to being listed, or the evidence is clearly a public review request.

Trial Closure States

State Meaning
useful The reviewer found a clear use case or adoption path.
too-heavy The profile is useful but too large for the repository today.
misaligned The profile does not fit the repository type.
needs-change The profile needs changes before another trial.
adoption-requested Maintainer wants registry listing or follow-up PR.

Anti-Claim Language

Use this wording when publishing a trial:

This is an independent trial of the Agentic Enterprise Readiness Profile. It does not imply AAIF, Linux Foundation, or maintainer endorsement, and it does not certify production readiness.

Maintainer Ask

The best request is narrow:

Would this profile make your repository easier or harder for enterprise developers to review?

That keeps the trial grounded in repository usefulness rather than promotion.