This page defines tiers for talking about providers. It is intentionally not a generated list of every package under providers/.
A recent ARC tree inventory observed on the order of 77 provider packages (implementation count, not a support promise). Most of them must stay out of the public catalog until they meet the evidence bar.
Tiers
| Tier | What belongs there | Evidence required before public wording |
|---|---|---|
| Core runtime contract | Shared path, operation, capability, and error contracts every author must understand | Current source + contract tests. This board documents those contracts; it does not list individual providers as "core products" |
| Reference / optional (documented) | A named integration you may present to developers as a starting point or optional module | Complete authoring acceptance record: contract, access boundary, conformance result, isolated local acceptance, compatibility, support ownership |
| Source inventory only | Packages visible in ARC source, including experimental, test-oriented, or incomplete work | Package presence alone. Keep source notes separate from the public catalog |
| Do not list | Internal, abandoned, or unverified backends; anything whose search/auth story would mislead | — |
Verified-with-evidence entries (this board revision)
Entries below are not a complete product matrix. Each row cites the evidence used for this revision (arc 2.0.0-beta.28 and/or ARC 44fbd616f). Absence from the table means "not admitted here yet," not "does not exist in source."
Core / reference evidence (not full product acceptance)
Rows below are core-contract or reference baselines with the evidence cited. They are not a claim that every field of the authoring acceptance record is already on file as a product support commitment (owner, lifecycle, isolated demo pack, public support surface). Use them to start from, not as a finished “admitted product” matrix.
| Name | Role | Evidence | Limits |
|---|---|---|---|
JSON / YAML provider (@aigne/afs-json, providers/core/json) | Compact tree-as-FS baseline for authors | Conformance: pnpm --filter @aigne/afs-json test -- test/conformance.test.ts → 372 pass, 6 skip, 0 fail on ARC 44fbd616f. Source implements list/read/write/delete/search/stat/explain (+ rename in capabilities when writable) | Local file-backed JSON/YAML; not a remote multi-tenant store; search is provider-local over that tree; not a complete product acceptance record |
Local filesystem provider (providers/basic/fs, URI scheme fs://) | Common local directory mount | Live local acceptance on beta.28: ls/stat/read/search on a mounted project tree; read …/.meta/.capabilities shows provider: "fs" with write/search/exec/batch flags; disposable write/read/delete on a separate pre-mounted writable fs:// path | Instance-specific mounts; mount add success ≠ immediate operational readiness (see Runtime boundaries); search is filesystem search for that mount, not global FTS |
Observed on a sample daemon (not catalog admission)
The following appeared on one verification host's mount list / root listing. They illustrate environment mounts only. They are not elevated to supported public products by this page:
web-device://(Web Device site host — contract lives on the Web Device board)vault://, agentcode-agent://mounts, messaging mounts, hub URIs, and others
Do not copy a host's mount list into marketing or onboarding as "supported providers."
Admission rule (repeat)
Do not promote a provider because the backend name is familiar or because a package exists. A future catalog row must name version boundary, supported operations, access/data boundary, maintainer, docs location, and the exact local acceptance evidence used.
Until more rows meet that rule, this catalog stays intentionally thin.