The facts about your own artifact, in a file you keep.

A maintainer knows what their package provides, what it needs and what it works with better than any crawl of the README. onedevatlas.json is where they say so: one small file in the repository, read by the atlas, quoted on the page as the maintainer's own statement, and never edited here.

What it is

A JSON file named onedevatlas.json, committed at the root of the repository, or beside the package.json of a package inside a monorepo. It states the facts the atlas otherwise reads out of documentation: where the artifact belongs, what it does, what it needs, what it works with, how it is reached and installed, and what its maker has said about its end. Every value enters the atlas with the file as its quoted source, the way a sentence from a README does, and the page shows that source beside the value.

The split of authority is the one in the vision: the maintainer owns the facts about their artifact, and the atlas owns the readings and the prose. So the file carries no description, no considerations and no number anyone ranks by, and the atlas writes nothing into it.

The file

{
  "$schema": "https://onedevatlas.dev/manifest/schema.json",
  "name": "cds-caching",
  "ecosystem": "cap",
  "type": "cds-plugin",
  "flavors": ["node"],
  "capabilities": [
    { "id": "caching", "does": "Retains query, request and function results, with expiry and tag-based invalidation." }
  ],
  "requires": [
    { "ref": "artifact:sap-cds", "for": "The runtime the plugin is loaded into; version 8 or later." },
    { "ref": "external:redis", "for": "The shared store for a distributed deployment.", "when": "store is set to redis" }
  ],
  "compat": { "runtimes": ["node"] },
  "properties": { "distribution": ["npm"] },
  "links": { "docs": "https://github.com/mikezaschka/cds-caching#readme" }
}

The schema is at /manifest/schema.json; with the $schema line an editor validates the file as it is written. The rules the schema cannot say are checked when the file is read: a flavor must belong to one of the file’s doors, and a property key must be one its type owns.

Each key

name	required	The thing's own name, as its README and its registry call it.
ecosystem	required	The one door it lives behind, or umbrella for something built for SAP software across stacks that names no single one.
type	required	What kind of thing it is, from the list below.
capabilities	required	What it provides: each capability by its id, with one sentence on what this artifact does for it. Descriptive, never evaluative.
serves	umbrella only	The doors it is relevant to beyond its own.
flavors	optional	The flavors of its door it answers in. Absent means the file does not say; it is never read as none.
requires	optional	What it needs to run, each as an atlas ref with what it is needed for and, where it is only needed sometimes, when.
compat	optional	The runtimes it runs on; on ABAP, the lowest SAP_BASIS release, the system lines, and where you ran it, in your words.
properties	optional	What its type states about it, from the keys its type owns. A key another type owns is refused.
links	optional	Documentation, a homepage, the changelog, the issue tracker, an SAP What's New feed. The repository and the registry are read from where the file was found.
lifecycle	optional	What you have said about its end, where you have said anything: the state, when it takes effect, and the statement in your words.

Doors

ecosystem and serves take a door’s key: cap, ui5, abap, btp, commerce, successfactors, digital-manufacturing. umbrella is an ecosystem only: Built for SAP software across stacks, and behind no one door: its own documentation names no single stack it serves.

Types

cds-plugin Installs into a CAP project and extends the runtime. CAP loads it through cds.requires or the plugin hook.
package A library you install and call yourself.
ide-extension Installs into a development environment (VS Code, Eclipse with ABAP Development Tools, SAP Business Application Studio) and works inside it, rather than as a library you call or a command you run.
app An application you deploy and use, installed into a system or loaded into an application as a component, rather than a library whose functions you call.
generator Creates a project, a component or configuration once, when you run it, rather than taking part in every build.
mcp-server Exposes tools to a coding agent over MCP.
skill A procedure an agent follows. Indexed here, never written here.
cli A command you run, rather than a dependency you import.
web-tool A hosted utility you use at a URL, rather than run or install. May be free or paid; source_available says whether anything behind it is inspectable.
desktop-app An application you run locally with a desktop user interface. It may be distributed as an installer or built from source; it is the workspace itself, rather than a library, command-line tool or hosted utility.
build-tool Runs at build time. Nothing of it ships in the deployed application.
platform Delivered with a runtime rather than published. Nothing versions it independently and there is nothing to adopt or avoid — it is simply what the platform gives you.
practice A convention or specification you conform to rather than install. The answer itself, not evidence about one.
sample A worked example you read or clone. Evidence: it demonstrates, it never provides.
doc-source Documentation collected and cited. Evidence, like a sample.
service A BTP service you subscribe to and bind, rather than install. It has plans and regions, not versions, and may deliver a product that lives outside the atlas.

Flavors

cap: node (Node.js), java (Java)
ui5: freestyle (Freestyle), fiori-elements (Fiori elements), web-components (Web Components)
abap: standard-abap (Standard ABAP), abap-cloud (ABAP Cloud)

Properties, by type

The keys a type owns, with the values each takes, are on the types page. A tool_count is a number, read_only true or false, guardrails a list of sentences in your words, uploads one sentence, and every other key takes one value or a list of them.

package: placement, distribution
mcp-server: runs, transports, auth, tool_count, read_only, guardrails
cds-plugin: distribution
cli: distribution
build-tool: distribution
skill: distribution
app: placement, distribution
ide-extension: installs_into, distribution
generator: generates, invoked_by, distribution
web-tool: access, uploads
sample: form
desktop-app: platforms, distribution

Lifecycle states

deprecated (Deprecated), maintenance (In maintenance), retirement-announced (Retirement announced), retired (Retired).

Where the ids are

A capability’s id is the last part of its page address: the caching capability is at /capabilities/caching, so its id is caching. The all-ecosystems overview has them all, by door. A requirement points at an atlas entry the same way: artifact:sap-cds for /artifacts/sap-cds, external:redis for a thing outside the atlas listed at externals. A capability or a requirement the atlas does not hold yet is not applied; the file is kept, the review names it, and the entry is drafted through intake.

What happens when you add it

At intake. When an artifact is drafted from its repository, the file is fetched, validated, kept as a source and applied onto the draft before anything else is checked. What it states replaces what was read elsewhere for the same fields; edges the file does not name stay as drafted, and the review says which.
Every night. Every artifact whose repository is on GitHub is asked for the file. Where it states what the entry does not, a revision is staged with the file as its source, and a person accepts or declines it in the admin. Nothing is published by a script.
On the page. Each applied value shows its source: the file, at the commit it was read from, with the line it rests on. A reader can see that the maintainer said it, and when.
When it does not validate. Nothing from it is applied. The errors are listed in the review and in the nightly’s report, with the path in the file each one points at.

What it does not carry

Prose. What the artifact solves, when not to use it and what to build on it are written by the atlas from the documentation, dated and attributed. A maintainer’s own words go into the note on their entry, signed in with their GitHub account.
Readings. Liveness, releases, CI and compatibility are crawled and computed with stated thresholds. A file cannot say a thing is maintained; the repository does.
Who maintains it. Read from the repository owner and the package publishers, never declared.
Anything to rank by. No tier, no score, no badge comes from the file, and a file’s presence orders nothing. An entry without one is curated from the README and the crawl, and reads the same.