Section

How does a system describe itself to 1ADK?

Enough of the mechanism, published, that a technical reader can judge whether this is engineering or a prompt with a logo.

Why any of this is public

Because the alternative is asking people to take it on faith. A product whose central claim is "we do not need access to your code" should be able to explain what it does need, in enough detail that somebody technical can decide whether the claim holds.

The three pages above are the parts that matter for that judgement: what an agent is instructed to do, what the file it produces can and cannot contain, and how two of those files are compared. Between them they answer the question a sceptical engineer actually has, which is not "what does it do" but "where could this go wrong?"

What is not published

  • The full schema. Publishing it in machine-readable form is a separate product decision that has not been taken, and this section does not pre-empt it.
  • Server-side internals. Storage layout, queueing, locking and validation implementation. Nothing here is a secret worth keeping for its own sake, and nothing here helps a reader judge the boundary.
  • Anything that would help somebody attack a customer's project. The security page states the boundary and its limits; it does not hand over a map of where to push.

The metadata preview shows a complete worked example of a package, field by field, which is the practical version of this section.

Find out what you actually own.

No repository access. No source-code upload. No card.

Build your project map — free