An AFS provider is an AFSModule that supplies resources and operations behind paths. It is the unit that decides which operations exist, how paths resolve, and how a backing system is reached.
Role in routing
| Step | Who owns it |
|---|---|
| Path string in the instance namespace | Caller |
| Mount path → provider instance | Runtime / configuration |
| Operation implementation and enforcement | Provider |
| Backing store or network transport | Provider |
Without a mount that maps a path prefix to a provider, the path is not a product feature—it is an unresolved address. See the routing diagram on Overview.
What a provider must make explicit
Provider documentation (or acceptance records) should state:
| Topic | Why it matters |
|---|---|
| Owned path shape | How callers form stable paths |
| Declared operations and features | What is in contract vs optional |
| Access mode / auth / network-read policy | Who may read or mutate |
| Search and query behavior | Separate contracts; see Search and query |
| Failure codes and side effects | What callers can branch on |
| Support ownership | Who maintains it |
Source inventory is not a catalog
The current ARC repository groups provider packages under areas such as core, basic, AI, messaging, platform, runtime, cost, IoT, and test. That inventory is implementation evidence. A package directory does not by itself become a stable public integration.
This board therefore:
- Explains the module contract on Author a provider
- Defines admission tiers on Provider catalog
- Does not flatten every package as an equally supported product
Runtime modules you may already see
On a local daemon, arc afs ls / and mount list show this instance's mounts—not the full source inventory. Examples observed on one beta.28 host (not a support matrix): fs:// project and memory trees, web-device://, vault://, agent code mounts, and others. Treat them as environment-specific until a catalog entry with evidence exists.