Architecture requirements

An Enterprise feature, available on dedicated instances, where nyxory switches it on for you. Not on the shared platform.

Your organisation already knows how software should be built: which templates teams start from, which technologies the cloud strategy allows, what the platform provides centrally. On a dedicated instance you write that down once. Every coding agent learns it from nyx_brain before it writes code, the platform refuses a rollout that breaks it, and a team that needs to deviate requests an exception that a person decides.

A workspace without requirements behaves exactly as before.

The Architecture page

In the console, open Settings › Architecture. The page has five sections, in this order:

Architecture owners are a small group of people per instance, typically your architecture or platform team. nyxory assigns the role on your instance. Members and agents read everything they need to build. Only people change requirements and decide exceptions, never an agent.

Reference architectures

A reference architecture is a template for one kind of software: what it is for, which platform building blocks it uses, and build instructions the agent follows. The page shows them as a gallery, each with its architecture diagram.

• From nyxory are the templates nyxory maintains, such as a web app with Postgres or an agent with the AI gateway. A template that does not fit your cloud strategy shows greyed out with the reason and is not offered to the agents.
• Own are yours and apply to all workspaces on the instance. They are offered ahead of nyxory’s.

Create reference architecture opens an editor with a live preview. A template is Markdown with a YAML header:

---
id: web-service-postgres
title: Web service with Postgres
purpose: Web service on the platform's Postgres database.
signals: [web service, node, api, postgres, database]
components: [postgres, public_url]
diagram:
  nodes:
    - {id: web, kind: ingress, label: "Public URL"}
    - {id: app, kind: app, label: "Web service"}
    - {id: db, kind: postgres, label: "Postgres"}
  edges: [[web, app], [app, db]]
---
## Build instructions
…

id, title, purpose, signals and either diagram or image are required. signals are the keywords that match a plan to the template. A technology the template needs beyond the platform building blocks goes under technologies, each with a reason. The console checks it against your cloud strategy and warns when saving, and the review then names the conflict. In the build instructions, the console fills in __APP__, __NAMESPACE__, __REGISTRY__ and __GATEWAY__. It increments version on every save. Projects built from an older version show “newer version available”, and nothing is rebuilt for them.

Cloud strategy

Paste your organisation’s cloud strategy with Insert strategy. An architecture owner chooses under Where should the strategy apply?:

• For the whole instance applies it to all workspaces in this instance.
• Only for this workspace applies it here in addition. This workspace becomes stricter, all others stay as they are.

Workspace owners and admins without the role get Make it stricter for this workspace for the second case. A workspace can add to the instance-wide strategy, never loosen it.

The AI model connected to your instance reads it section by section and turns it into proposals, each with the sentence from the document and where it stands. A proposal whose sentence is not in the document word for word is discarded. Nothing applies until you Adopt a proposal, one by one or with Adopt all.

A requirement takes one of two forms:

• Databases: only PostgreSQL allows one or more technologies in a category and rules out the rest of it.
• Kafka: not allowed rules out one technology.

Each requirement shows where the platform detects it: in the code, in the container image, in the bill of materials. A technology the platform does not know still reaches the agent, and the page marks it “unknown to the platform: the agent is told, it is not enforced”.

A new version of the document comes in through Insert new version and shows its proposals as the difference to the current one. Only people who may change the strategy see the full text. Everyone else, agents included, sees the requirements with their sentence.

Platform building blocks

For each building block a workspace answers allowed or no. A no needs a Reason, and you can add a Note for the agent on what to use instead, for example the central database and the secret its credentials are in. Both reach the agent word for word.

Below the building blocks, Still running although no longer allowed lists what was there before a requirement and keeps running. It stays untouched. The list includes running containers whose image falls under a technology requirement of the cloud strategy, such as a mysql:8 container after “Databases: only PostgreSQL”. For each of them, Request exception leads to the project’s exception form, in case it should keep running.

What your coding agent gets

The agent calls nyx_brain with the project and describes its plan in agent_briefing: what it builds, its components, its data stores. On top of the cookbook, the answer carries:

The agent picks a template and calls nyx_brain again with reference set to its id. The answer is the build instructions with the project’s values filled in. When the agent then rolls out from the same session, the project counts as built from that template, and the template’s page lists it.

Your requirements win over every cookbook recipe and every reference architecture. The repo check reads dependencies, Dockerfile base images and services in a compose file. What it could not read, it says so, and the agent checks that part itself.

What happens at rollout

The platform checks every new rollout against the requirements, on every path into the project: nyx_deploy_manifests, a push with a deploy/ folder, and kubectl through nyx_shell. A rollout that breaks a requirement is refused before anything is applied. The message starts with a code the agent can read, shown wrapped here:

requirement:denied:technology:mysql: image "mysql:8"
(mysql) is not allowed in workspace "Orders". …

The code is requirement:denied:<rule>, and for a technology requirement:denied:technology:<name>. The rest of the message carries the reason, the alternative, the note for the agent where you set one, and how to request an exception. On some paths the code follows a prefix, so the agent looks for requirement: anywhere in the message. A refused deploy/ push leaves the running version serving.

Running workloads stay untouched. Requirements apply to what is created or changed. An update is checked only for images that are new in it, and lowering a memory limit always works.

Request an exception

When a project needs something a requirement rules out, the agent requests an exception with nyx_exception_request. A member does the same on the project, under Settings › Architecture with Request exception.

The answer is the request with its state, and created says whether it is new. Asking again for the same thing returns the open request, or the exception that already applies, instead of a second one. A project has at most ten open requests.

A person decides, never an agent. An architecture owner sees the request under Exceptions, with its reason and who requested it, and chooses Approve or Reject. Rejecting needs a reason, so the team knows what to do instead. The person deciding can pick a different duration from the same choice. An approved exception applies after about a minute, in the rollout check and in the next nyx_brain answer. The agent tells you that the request waits for a decision and plans with the alternative until then.

An exception moves through these states:

Fourteen days before an exception ends, the project’s feed and alert channels say so. When it expires or is revoked, what runs stays in place, and a new rollout of that technology is refused again. An unlimited exception never expires.

Example: from plan to approved exception

A team builds an order service. Your cloud strategy says “Databases: only PostgreSQL”, and the team also ships a reporting tool that only runs on MySQL.

Related: MCP tools · Configure your app from the repo · The cookbook