course · schema
A species is the description of everything one kind of being can be asked, plus the code that answers. The description is called a schema: every question or request a caller can send to a being of that species, and exactly what it promises back.
Behind the schema sit resolvers: for each question the schema promises an answer to, a resolver is the code that works it out and returns it. You write the schema and its resolvers once, in whatever language you choose — the protocol doesn’t care which one.
An illustrative example, in plain words rather than real syntax: a caller asks a bakery being, “what’s on today’s order list?” The schema promises back a list of today’s orders, each one with what’s in it and when it’s due.
Behind the resolvers often sit services: plain code that does what a resolver decides — checks a ledger, looks something up, calls another system — with no idea it’s part of a being at all. Keeping the deciding and the doing apart means a service can be tested and swapped out without the being noticing.
Once written, the same species is read two ways without any extra work: by a person, as a page they can look at, and by an AI tool, as a set of calls it can make directly. Both readings come from the one schema — nobody hand-writes a second version for either audience.
This trade is for anyone who wants to define a new kind of being — a bakery keeping its own order book, a clinic minding its appointments, a landlord running a building. You decide what your kind of being can be asked, and what it promises back.
After this course you can write a schema that says exactly what your being can be asked, write resolvers that answer it honestly, and trust that the same definition is readable by a person and by a piece of software without doing the work twice.
This course opens when the engine proves itself — only then is there a species worth writing.
Follow the build