Governed Context
Approval flows govern the moment a change is submitted. Governed context governs everything before that: the posture the work is done under in the first place.
Most organisations have the material already. Architectural principles agreed in a workshop. Decision records explaining why Postgres and not MongoDB. Naming conventions, review standards, a list of technology that is approved and technology that is not.
None of it is applied. It lives in a wiki, a slide deck, or somebody’s memory, and the work happens somewhere else. A new joiner does not read it. A contractor never sees it. Reviewers apply the parts they remember, which is why two reviews of the same change disagree.
AI makes the gap expensive rather than merely annoying. An agent writing code against your API will follow some set of conventions — it just will not be yours, unless somebody pastes them into a prompt, every time, correctly. Standards that depend on a human remembering to attach them are not standards.
Your documentation, built as you go
Section titled “Your documentation, built as you go”Because the principles, decisions, standards and designs live here, your documentation does not have to be written separately. It is built up from them as your architecture takes shape: a principle you add, a decision you accept, a design you approve and the contract it produces each become part of it the moment they exist — and a superseded decision drops out the same way.
So the documentation is never a project someone starts after launch, and never out of date with the architecture it describes. It is iterative because the architecture is.
What you get
Section titled “What you get”Your tenant holds the substrate the work is judged against:
| Principles | Your architectural rules — API first, OAS first, naming, whatever your team has agreed. Versioned, so an audit can reconstruct which were in force at any past moment. |
| Decision records | ADRs with a real lifecycle: Proposed, Accepted, Superseded. A superseded decision stops being handed out. |
| Personas | The roles work is done as, each with its own remit — including the ones your AI agents adopt. |
| Agent rules | Standing instructions for automated work, held at tenant level rather than in a chat history. |
| Skills | Shared procedures your tools and agents can call on, instead of each developer keeping their own. |
| Tech catalogue | Technology graded Trial, Approved, Deprecated or Forbidden — so “can we use this?” has an answer that does not depend on who you ask. |
Apiway curates a baseline; your tenant overlays it with your own. Only what is in force is ever handed out — superseded decisions, deprecated technology and disabled rules are excluded rather than returned with a warning nobody reads.
How you plug in
Section titled “How you plug in”One call returns the effective context for whoever is asking:
GET https://architecture.api.apiway.net/v1/governanceWhoever picks up governed work — a developer, or an agent running in Claude, Cursor or Copilot — loads it at the start and works under the same posture as everyone else on the team. Through CLI & MCP this happens as part of the tool’s own startup, so the person doing the work does not have to remember anything.
The same context is what approval flows judge a submission against, which is why a review does not depend on the reviewer’s memory.
Where it fits
Section titled “Where it fits”Governed context attaches at two points of product delivery: design, where the contract is produced against your standards rather than generic ones, and code, where the implementation is written and gated under the same rules.
You do not have to fill it before you start. The Apiway baseline applies from day one, and your own principles and decisions replace it as you record them.