The Specification \u2013 What’s fixed and what’s still open<\/h4>\n\n\n\n
This is where the business domain of a module is defined: its terms, data, and rules. This also includes the use cases with their acceptance criteria, which precisely describe how the system should behave. This is owned by the business analyst.<\/p>\n\n\n\n
Every statement in it falls into one of two categories:<\/p>\n\n\n\n
- \n
- Invariant:<\/strong> A fixed rule that an implementation may never violate.<\/li>\n\n\n\n
- Open Decision:<\/strong> A decision not yet made, recorded with a safe default value so nobody has to guess.<\/li>\n<\/ul>\n\n\n\n
\n
The Golden Rule:<\/strong> write down every business rule and invariant explicitly, no matter how obvious it seems. Whatever isn’t in the specification doesn’t exist for the AI agent.<\/p>\n<\/blockquote>\n\n\n\n
EXCERPT: FROM THE ORDER DOMAIN MODEL<\/p>\n\n\n\n
Order
id: string
accountId: string (owning customer account)
status: placed | shipped | cancelled | refunded
INV-07: A customer may view only orders belonging to their own account.
OD-03: How long does a cancelled order stay visible in the account?
Default: 24 months, pending confirmation from Legal.
<\/pre>\n\n\n\nEXCERPT: USE CASE ORDER DETAIL<\/p>\n\n\n\n
Scenario: Customer views their own order
Given an authenticated customer
When they request an order by id
Then the order is returned only if accountId matches the requester
# enforces INV-07
Scenario: Customer requests an order they do not own
Given an authenticated customer
When the requested order belongs to a different account
Then the response is 403 Forbidden
# enforces INV-07
<\/pre>\n\n\n\nThe Guardrails \u2013 The memory that applies to everyone<\/h3>\n\n\n\n
Above the specification of an individual module sit the guardrails<\/strong>. They form the shared technical standard that every application in the system follows: tech stack, programming language, API design, security, error handling, and logging.<\/p>\n\n\n\n
This is defined by the solution architect<\/em>. It also includes architecture decision records (ADRs) <\/strong>\u2014 short entries that capture why a particular option was chosen and an alternative rejected.<\/p>\n\n\n\n
\n
The golden rule:<\/strong> define technical standards and security rules once, centrally, for the whole system. Whatever is anchored in the guardrails applies without exception, regardless of what the business analyst happened to think of in an individual use case.<\/p>\n<\/blockquote>\n\n\n\n
EXCERPT: ARCHITECTURE DECISION RECORD<\/p>\n\n\n\n
Title: Integration with SAP S\/4HANA
Status: Accepted
Context: Multiple services need data from SAP. Direct point-to-point connections would mean many sets of credentials to rotate and no single place to audit access.
Decision: All integration with SAP S\/4HANA goes through SAP Cloud Integration. No service connects to SAP directly.
Consequences: One integration surface to secure and monitor. Slightly higher latency accepted as tradeoff for a single audited path.
<\/pre>\n\n\n\nEXCERPT: DEFINITION OF FOLDER STRUCTURE<\/p>\n\n\n\n
pxp-portal-web (BFF)
\u251c\u2500\u2500 app\/ (Routes & Server Components call microservice directly)
\u251c\u2500\u2500 app\/api\/ (Route Handlers, one per client-triggered write)
\u2514\u2500\u2500 lib\/api-client (Typed calls to the microservice)
order-service (Microservice)
\u251c\u2500\u2500 src\/handlers (HTTP routes)
\u251c\u2500\u2500 src\/services (Business logic)
\u2514\u2500\u2500 src\/models (Domain types)
Rule: The browser never calls a microservice directly.
Every client-triggered write goes through a same-origin Route Handler in the BFF.
<\/pre>\n\n\n\nThe UX \u2013 What’s allowed vs. how it should look<\/h3>\n\n\n\n
A visual design carries no memory <\/strong>of its own at all. A Figma design only shows a target state, but never the reasoning or the business logic behind it.<\/p>\n\n\n\n
\n
The golden rule:<\/strong> the design shows the how, the specification decides the what. If the two contradict each other, the specification always wins, because it’s the only one that can be explained and traced back.<\/p>\n<\/blockquote>\n\n\n\n
EXAMPLE: UX ORDER OVERVIEW<\/p>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/diselva.com\/wp-content\/uploads\/2026\/07\/image-1.png?resize=1360%2C823&quality=78&ssl=1\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
The Hands \u2013 Two kinds of memory<\/h3>\n\n\n\n
None of the three human roles (architect, business analyst, UX designer) writes the code itself. That’s handled by a set of repeatable procedures: the skills<\/strong>.<\/p>\n\n\n\n
Here the difference between two types of knowledge becomes visible:<\/p>\n\n\n\n
- \n
- Declarative knowledge (factual knowledge): <\/strong>The specification and the guardrails record what has been decided.<\/li>\n\n\n\n
- Procedural knowledge (know-how): <\/strong>The skills record how to actually build something from these requirements.<\/li>\n<\/ol>\n\n\n\n
\n
The Golden rule:<\/strong> define the procedural knowledge (how to build) in repeatable skills, but never let them guess the factual knowledge (what to build). A skill executes rules strictly and stops immediately if a specification is incomplete.<\/p>\n<\/blockquote>\n\n\n\n
EXCERPT: SKILL DEFINITION IMPLEMENT-USE-CASE<\/p>\n\n\n\n
name: implement-use-case
description: Turn an already written Use Case doc into working code against the harness.
instructions:
Before writing any code, trace every Open Decision and Invariant
the Use Case cites. If a citation points to an ID that does not
exist in the Domain Model doc, STOP and flag it rather than
guessing what it might have meant.
<\/pre>\n\n\n\nWas \u201eSTOP and flag” in der Praxis bedeutet: Der Agent bricht die Session nicht ab, er pausiert sie. Die offene Frage geht als R\u00fcckfrage an die verantwortliche Rolle zur\u00fcck, meist an den Business Analyst bei einer fehlenden Anforderung, an den Architekten bei einer L\u00fccke in den Leitplanken. Bis die Antwort da ist, wird nichts geraten und nichts implementiert. Sobald die Entscheidung in Spezifikation oder Leitplanken eingetragen ist, nimmt der Agent die Session mit dem neuen Stand wieder auf.<\/p>\n\n\n\n
The Audit \u2013 How we closed the gap<\/h3>\n\n\n\n
When the team investigated the invoice URL security hole, it became clear: it was never the decision of a single module, but a rule that everyone had considered “obvious.”<\/p>\n\n\n\n
The problem was fixed in two places:<\/p>\n\n\n\n
- \n
- Invoice retrieval now checks ownership.<\/li>\n\n\n\n
- The rule was added globally to the guardrails<\/strong>.<\/li>\n<\/ol>\n\n\n\n
EXCERPT: GUARDRAILS (ADDITION AFTER THE INCIDENT)<\/p>\n\n\n\n
Rule: Any endpoint returning an entity by ID MUST verify that the requester
owns it before the response is built. No exception\u2014not even for internal tools.
<\/pre>\n\n\n\nThe Overview: Three roles, one borrowed memory<\/h3>\n\n\n\n
An AI agent forgets everything. Every time. So that AI can still develop software reliably within an enterprise, we move the project’s memory out of the volatile chat window and into structured artifacts.<\/p>\n\n\n\n
Three human roles define the factual knowledge<\/strong> (what gets built). Repeatable skills provide the procedural knowledge<\/strong> (how it gets built). The agent only borrows this knowledge for the duration of a working session.<\/p>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/diselva.com\/wp-content\/uploads\/2026\/07\/image.png?resize=1024%2C913&quality=78&ssl=1\")
<\/figure>\n\n\n\nIn a nutshell<\/h3>\n\n\n\n
- \n
- Borrowed memory<\/strong>: The AI agent has no memory of its own. It reads specifications and guardrails at the start of a session and forgets them again when it closes. <\/li>\n\n\n\n
- The golden rule<\/strong>: What isn’t written down doesn’t exist for the AI. In AI engineering, there’s no such thing as “obvious.” <\/li>\n\n\n\n
- Engineering instead of “vibe coding”<\/strong>: The difference between trial and error and professional AI development doesn’t lie in clever prompting \u2013 it lies in the quality of the specifications and guardrails.<\/li>\n<\/ul>\n\n\n\n
How Diselva can help<\/h3>\n\n\n\n
Getting started with AI-driven software development is a cultural and process shift. At Diselva, we help you build this foundation:<\/strong><\/p>\n\n\n\n
Anchoring guardrails:<\/strong> We work with your architects to define technical standards and security rules (harness).<\/p>\n\n\n\n
Sharpening specifications:<\/strong> We establish structures for use cases and invariants that AI agents understand unambiguously.<\/p>\n\n\n\n
Developing custom AI skills: <\/strong>We build the procedures your agents need to code precisely to your specifications.<\/p>\n\n\n\n
Lowering context costs:<\/strong> A memory that gets reloaded from scratch at every session has a cost. We structure guardrails and specifications so agents only load what they actually need.<\/p>\n\n\n\n
Make your project’s knowledge independent of any single chat’s context window \u2013 get in touch.
<\/p>\n\n\n\n<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
An AI agent has no memory of its own between two sessions. We preserve the project’s memory permanently through specifications, guardrails, and skills. Three months after project kickoff, the acceptance test of an AI-developed application revealed something troubling: anyone who changed the invoice number in the URL could see another customer’s invoice as a PDF, […]<\/p>\n","protected":false},"author":268896787,"featured_media":117733,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_eb_attr":"","content-type":"","advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"jetpack_seo_schema_type":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_wpcom_ai_launchpad_first_post":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[1916,1963],"tags":[],"thema":[],"class_list":["post-117790","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-expert-article","category-leading-with-ai"],"blocksy_meta":{"styles_descriptor":{"styles":{"desktop":"","tablet":"","mobile":""},"google_fonts":[],"version":8}},"acf":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/i0.wp.com\/diselva.com\/wp-content\/uploads\/2026\/07\/image.png?fit=1024%2C913&quality=78&ssl=1","_links":{"self":[{"href":"https:\/\/diselva.com\/en\/wp-json\/wp\/v2\/posts\/117790","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/diselva.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/diselva.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/diselva.com\/en\/wp-json\/wp\/v2\/users\/268896787"}],"replies":[{"embeddable":true,"href":"https:\/\/diselva.com\/en\/wp-json\/wp\/v2\/comments?post=117790"}],"version-history":[{"count":2,"href":"https:\/\/diselva.com\/en\/wp-json\/wp\/v2\/posts\/117790\/revisions"}],"predecessor-version":[{"id":117798,"href":"https:\/\/diselva.com\/en\/wp-json\/wp\/v2\/posts\/117790\/revisions\/117798"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/diselva.com\/en\/wp-json\/wp\/v2\/media\/117733"}],"wp:attachment":[{"href":"https:\/\/diselva.com\/en\/wp-json\/wp\/v2\/media?parent=117790"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/diselva.com\/en\/wp-json\/wp\/v2\/categories?post=117790"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/diselva.com\/en\/wp-json\/wp\/v2\/tags?post=117790"},{"taxonomy":"thema","embeddable":true,"href":"https:\/\/diselva.com\/en\/wp-json\/wp\/v2\/thema?post=117790"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- The golden rule<\/strong>: What isn’t written down doesn’t exist for the AI. In AI engineering, there’s no such thing as “obvious.” <\/li>\n\n\n\n
- Borrowed memory<\/strong>: The AI agent has no memory of its own. It reads specifications and guardrails at the start of a session and forgets them again when it closes. <\/li>\n\n\n\n
- Procedural knowledge (know-how): <\/strong>The skills record how to actually build something from these requirements.<\/li>\n<\/ol>\n\n\n\n
- Open Decision:<\/strong> A decision not yet made, recorded with a safe default value so nobody has to guess.<\/li>\n<\/ul>\n\n\n\n