This dossier maps the Agentic Enterprise Readiness Profile against the current AAIF project proposal path before any formal submission.
It is not an AAIF project proposal, not a Linux Foundation contribution agreement, and not an endorsement claim. It is a public readiness dossier for deciding what evidence must exist before a proposal would be credible.
Public AAIF proposal sources reviewed:
- AAIF project proposal repository: https://github.com/aaif/project-proposals
- Proposal issue form: https://github.com/aaif/project-proposals/blob/main/.github/ISSUE_TEMPLATE/project-proposal.yml
- Project lifecycle policy: https://github.com/aaif/project-proposals/blob/main/governance/project-lifecycle-policy.md
- Submission guide: https://aaif.io/blog/how-to-submit-your-project-to-the-aaif/
The public proposal repository says project proposals are for foundation-hosted projects seeking Growth or Impact status. Its README says projects should review lifecycle documentation first and that projects not meeting the requirements will not be accepted.
The issue form asks for, among other items, project description, AAIF mission alignment, relationship to existing AAIF projects, adoption evidence, repository URL, OSI-approved permissive license, governance model, CI/CD and release workflow, public contribution process, issue tracker, external dependencies and licenses, maintainers and contributors, leadership and decision process, website, and contact/signatory information.
The issue form also includes a required trademark/accounts checkbox and states that, if accepted, project trademarks and accounts would be donated to the AAIF.
The lifecycle policy says projects must meet proposal requirements before submitting, that acceptance requires Technical Committee review and vote, and that final acceptance depends on Governing Board approval and the Linux Foundation contribution agreement process.
Do not submit a formal AAIF project proposal yet.
Current state is strong enough for public technical review and proposal preflight, but not strong enough for a formal Growth-stage proposal.
Current focused review issue:
Current release:
Primary blockers:
- no Technical Committee sponsor identified
- no production deployment evidence from at least two different organizations
- no external adopter outside the Karuna-maintained portfolio
- no diverse maintainer base across organizations
- no public contributor base approaching 10 contributors
- no user decision on trademark, account, domain, and contribution-agreement implications
- no public AAIF or LF-adjacent reviewer signal saying the profile should be routed toward proposal
Project name:
- Agentic Enterprise Readiness Profile
Project purpose:
- A lightweight evidence profile, validator, templates, and examples for agentic AI repositories that need clear proof around
AGENTS.md, tool/action boundaries, human approval, identity assumptions, audit events, OSS fallbacks, security posture, and reproducible validation.
Current evidence surface:
- 16 public portfolio examples with machine-readable readiness JSON.
- 16 repo-local boundary model examples.
- Public docs portal.
- Public review packet.
- Ecosystem contribution ledger.
- Contribution monitoring protocol.
- Maintainer review kit.
- Adoption trial protocol.
- External reviewer program.
- AAIF proposal readiness self-audit.
- AAIF portfolio recognition roadmap.
- Security posture plan.
- Dependency license inventory.
- Release checklist.
- Spec change process.
- Community engagement plan.
| Proposal field | Current evidence | Status | Required next proof |
|---|---|---|---|
| Project name | Stable name in README, releases, docs portal | Ready | Keep name stable through external review. |
| Project description | README, public review packet, docs portal | Ready | Add 2-3 external reviewer quotes when available. |
| Origin and history | Release history from v0.1.0 through current release |
Partial | Add a concise project history section before proposal. |
| AAIF mission alignment | Ecosystem alignment brief, proposal readiness self-audit, AAIF portfolio recognition roadmap | Partial | Get public routing feedback from AAIF/LF-adjacent reviewers. |
| Relation to existing AAIF projects | Mapping to AGENTS.md, MCP, A2A, agent gateway, observability, taxonomy workstreams | Partial | Add accepted upstream feedback or maintainer comments. |
| Use cases | 16-repo testbed across identity, support, workflow, finance, commerce, media, learning, and operations | Ready for review | Convert two examples into external adoption trials. |
| Adoption evidence | Karuna-owned portfolio evidence only | Missing | Get at least two external repositories or maintainers to try or review the profile publicly. |
| Production deployment in two organizations | None claimed | Missing | Do not claim until there is verified public production-use evidence. |
| TC sponsor | None identified | Missing | Seek only after useful public review or maintainer engagement. |
| Repository URL | Public GitHub repository | Ready | Keep releases and issues public. |
| OSI-approved permissive license | MIT license, dependency inventory | Ready | Recheck before proposal. |
| Governance model | GOVERNANCE.md, maintainer growth policy, external reviewer program |
Partial | Add public reviewer/maintainer evidence before proposal. |
| CI/CD and release workflow | GitHub Actions validation, releases, release checklist | Partial | Add explicit release cadence and release-owner rules. |
| Public contribution process | CONTRIBUTING.md, issue templates, spec change process |
Ready | Keep issue templates active and simple. |
| Public issue tracker | GitHub issues with review/adoption threads | Ready | Keep review threads updated with current releases. |
| External dependencies and licenses | Dependency license inventory; minimal Node validator surface | Ready | Re-run inventory before proposal. |
| Maintainers and contributors | One maintainer; external reviewer path exists | Missing | Need at least two core maintainers from different organizations and credible contributor base. |
| Leadership and decision process | Governance docs and maintainer growth policy | Partial | Add decision log and external reviewer escalation rules. |
| Roadmap | Roadmap, twelve-month milestone plan, portfolio recognition roadmap | Ready | Keep roadmap outcome-based and update after external feedback. |
| Security posture | Security policy, security posture plan, no sensitive runtime | Partial | Add OpenSSF Scorecard or Best Practices evidence when appropriate. |
| Website URL | GitHub Pages docs portal | Ready | Keep portal current and fast to inspect. |
| Social media accounts | GitHub profile; LinkedIn is human-owned | Partial | User-controlled; avoid automation or claims without review. |
| Trademark and accounts | No decision | Missing | Human owner must decide before any formal proposal. |
| Contact and signatory | Not public and not automation-safe | Missing | Human owner must provide if proposal is ever submitted. |
| Growth criterion | Current status | Evidence gap |
|---|---|---|
| Technical Committee sponsor | Missing | No sponsor identified. |
| Growth plan | Partial | Twelve-month milestone plan exists, but not sponsor-reviewed. |
| Diverse maintainership | Missing | Single-maintainer project today. |
| Production use at wide scale | Missing | Portfolio examples are reference foundations, not verified external production use. |
| Appropriate ongoing commits and merged contributions | Partial | Active releases and upstream PRs exist, but accepted external contributions are still limited. |
| Community participation sufficient for growth goals | Missing | Need external reviewers, adopters, or contributors. |
| TC majority vote and Governing Board approval | Not applicable | Only possible after formal proposal and review. |
Impact stage is not an appropriate target now.
Current gaps:
- no broad industry adoption
- no substantial production deployments
- no multi-organization governing body
- no healthy number of committers from at least two organizations
- no long-term support plan
- no official foundation route or sponsor
The right target, if the evidence matures, would be Growth-stage discussion.
When the missing evidence exists, the proposal packet should contain:
- one-page project narrative
- public repository link
- docs portal link
- release history
- license and dependency inventory
- governance model
- maintainer roster
- contributor roster
- adoption evidence from at least two organizations
- production-use evidence if available
- security posture and badge status
- roadmap
- relationship to existing AAIF projects
- Technical Committee sponsor, if identified
- trademark/account transfer decision
- contribution agreement signatory details
- Keep upstream AAIF/LF-adjacent PRs monitored without noisy follow-up.
- Convert at least one portfolio example into a short case-study issue or discussion for external review.
- Ask for review of the preflight dossier in issue
#4or the external reviewer issue, not in the AAIF proposal repo. - Keep the project proposal boundary visible in the README and public review packet.
- Recruit two external reviewers or one external adoption-trial maintainer.
- Turn review feedback into one small profile improvement release.
- Add an adoption-trial summary only when an external maintainer publicly opts in.
- Re-run this dossier against current AAIF proposal requirements.
- Decide whether the project should remain independent, become AGENTS.md/MCP/agentgateway guidance, or begin a sponsor-search path.
- Do not submit a proposal unless the missing evidence is resolved.
Current verdict:
- Public review ready: yes.
- Proposal preflight ready: yes.
- AAIF Growth-stage proposal ready: no.
- AAIF Impact-stage proposal ready: no.
Next meaningful recognition gate:
- public external reviewer feedback, external adoption-trial interest, or maintainer feedback that the profile is useful enough to route toward an AAIF/LF-adjacent workstream.