Skip to content

README.md

Latest commit

 

History

History
229 lines (165 loc) · 14.4 KB

README.md

File metadata and controls

229 lines (165 loc) · 14.4 KB
Raw

Agentic Enterprise Readiness Profile

validate-readiness-profile

An executable, evidence-first profile for evaluating whether an agentic AI repository is ready for serious enterprise review.

This project is maintained by Karunanidhi Mishra as an independent OSS contribution. It is not an Agentic AI Foundation project, not a Linux Foundation project, and not endorsed by either organization. It is designed to support constructive AAIF/LF-style technical discussion around repository readiness, governance, and reusable evidence.

Why This Exists

Agentic AI projects often demonstrate workflows before they expose the operational evidence that enterprise developers need:

  • clear AGENTS.md instructions
  • human approval boundaries
  • MCP/tool governance assumptions
  • identity and policy assumptions
  • audit logs and observability
  • release and contribution process
  • OSS fallback options for paid providers
  • reproducible setup for outside contributors

The profile gives maintainers and contributors a practical way to find and describe that evidence without over-claiming production maturity.

Scan A Repository

Run the zero-dependency scanner against any local repository:

npx --yes github:kmishra1204/agentic-enterprise-readiness-profile scan .

Or from a clone of this repository:

node bin/aerp.mjs scan /path/to/repository \
  --format both \
  --output-dir .artifacts/aerp

The scanner reads repository evidence only. It does not execute project code, inspect secret values, call providers, or award Level 4 automatically.

Add The GitHub Action

- uses: kmishra1204/agentic-enterprise-readiness-profile@v0.6.0
  with:
    minimum-level: "1"

The action emits JSON and Markdown reports under .artifacts/aerp. See CLI and GitHub Action for outputs, exit codes, and a complete workflow.

Profile Levels

Level Name Meaning
0 Public Scaffold Basic public repo hygiene exists.
1 Contributor-Ready Outside developers can inspect, run, and contribute.
2 Agentic Readiness Agent instructions, tool boundaries, approval points, and audit assumptions are documented.
3 Enterprise Evidence Security, governance, observability, threat model, and validation evidence are present.
4 Foundation Candidate Governance, adoption, maintainers, roadmap, releases, and ecosystem fit are strong enough for AAIF/LF-style proposal discussion.

What To Add To A Repository

At minimum:

  • AGENTS.md
  • CONTRIBUTING.md
  • SECURITY.md
  • GOVERNANCE.md
  • ROADMAP.md
  • docs/AAIF_ALIGNMENT.md or equivalent ecosystem-alignment note
  • docs/AGENTIC_BOUNDARY_MODEL.md
  • agentic-readiness.json

Use these starter artifacts:

Machine-Readable Profile

Use the schema in schema/agentic-readiness.schema.json.

Validate the profile, scanner, examples, and self-scan:

npm test

No network, Docker, database, or paid provider is required for validation.

Testbed

The first testbed is a 16-repository enterprise product portfolio maintained by Karunanidhi Mishra. All 16 examples are included in this repo with companion readiness JSON and boundary-model evidence.

Product Domain Readiness Example Boundary Model
SecureIDE Workbench AI coding workbench governance JSON Boundary
FlowGrid Orchestrator MCP-style connector governance JSON Boundary
SupportDesk Intelligence support-answer provenance and human escalation JSON Boundary
AccessGovernance Kit agent access policy and audit evidence JSON Boundary
VoiceGrid Operations voice consent and transcript governance JSON Boundary
Meeting Intelligence Hub transcript retention and follow-up approvals JSON Boundary
TenantCommerce Control tenant-scoped commerce policy and audit JSON Boundary
LedgerOps Intelligence finance consent and reconciliation controls JSON Boundary
AppForge Studio generated app publishing and sandbox preview governance JSON Boundary
BrandOps Studio brand asset approval and export governance JSON Boundary
IdentityCore Platform delegated identity and session policy JSON Boundary
KnowledgeStream Hub transcript provenance and retention controls JSON Boundary
CollabBoard Command collaborative board export controls JSON Boundary
LiveOps Broadcast moderation, recording, and retention governance JSON Boundary
SkillForge Learning assessment provenance and manager review JSON Boundary
WorkGrid Portfolio portfolio approvals and dependency governance JSON Boundary

See docs/PORTFOLIO_TESTBED.md for the full 16-repo map.

Ecosystem Work

The public contribution ledger tracks current upstream work, maintainer feedback, and recognition gates:

Open PRs and issues are listed as work in review. They are not treated as accepted contribution until maintainers merge or explicitly adopt them.

External Adoption Trials

The first public entry point for external trials is:

Use the adoption trial protocol, reviewer quickstart, and public review packet for read-only reviews, branch trials, and maintainer feedback before any repository is listed in the adoption registry.

The useful first signal is intentionally small: compare one repository boundary against one readiness example, then comment with one useful part, one heavy part, and one adoption blocker.

Good First Review

The pinned first-review issue is:

Reviewers can inspect one artifact and leave one route signal. This is technical feedback only, not endorsement, adoption, certification, AAIF status, or Linux Foundation status.

The broader external reviewer call is:

Use it when the feedback is more than one route signal but still a technical review, not endorsement or adoption.

The focused AAIF/LF-style proposal-readiness review is:

Use it to challenge the proposal preflight dossier and missing-evidence list before any formal foundation route is considered.

Use the route signal issue template when a reviewer wants a structured path with context links, a one-sentence response shape, anti-claim checks, and public acknowledgement consent.

Use the route signal response protocol to classify the signal as recorded, accepted change, follow-up issue, non-goal, route change, or adoption trial.

Use the route signal ledger to inspect public route signals and response states. No external route signals are recorded yet.

Use the public discussion when the feedback is broader than one route signal but still technical and non-promotional.

Use In Public Forums

Good use:

  • Ask maintainers whether the evidence shape is useful.
  • Ask for a one-comment route signal using the route-signal issue template.
  • Open issues or PRs that improve a concrete repo boundary.
  • Compare the profile against AGENTS.md, MCP, agent gateway, identity, audit, and human-review needs.
  • Use the maintainer review kit, external review guide, and AAIF proposal readiness self-audit before any formal foundation route.
  • Use the public review packet when asking AAIF/LF-adjacent communities for focused technical feedback.
  • Use the AAIF forum posting packet for the first human-reviewed public ask so the post stays concise, route-focused, and non-promotional.
  • Use the AAIF ambassador contribution plan when preparing project-based monthly educational contributions tied to AGENTS.md, MCP, Goose, and agentgateway.
  • Use the AGENTS.md enterprise evidence checklist when teaching maintainers how to turn repository instructions into reviewable setup, tool-boundary, approval, fallback, and validation evidence.
  • Use the MCP tool boundary evidence checklist when teaching maintainers how to document tool side effects, schemas, approval gates, identity scope, audit events, and fallback mode.
  • Use the MCP review posting packet only after human review when asking for one field-level correction on MCP-style tool evidence.

Bad use:

  • Claim AAIF or Linux Foundation affiliation before official acceptance.
  • Treat the profile as proof of production readiness by itself.
  • Auto-post mass promotion to maintainers or forums.

Current Status

Version: 0.6.0

Status: executable OSS profile with a zero-dependency CLI, reusable GitHub Action, machine-readable reports, a 16-repository public testbed, and explicit anti-claim boundaries.

Next target: external repository trials that produce verified usability feedback, not promotional adoption claims.