reading time: 20 minutes

Prompt engineering is fragile. At 80,000 tokens, your alignment rules are drowned in noise, and the LLM forgets what you asked at the beginning of the conversation. My solution? Do not align by text, but byspace. I structured my development workspace into four concentric circles of trust — from the intimate secret garden to the public forges — and each circle is a physical zone of the file system. The LLM doesn’t need to be reminded of the rules: the file path contains them. Here is how it works, and why this spatial alignment architecture is more resilient than a`system prompt`of 500 lines.

This is a long article.
Get comfortable.

toc

[]

The Observation: Prompt Engineering is a Sandcastle

For three weeks, I developed Gradle plugins with Opencode, using three different LLMs — Kimi K2.6, GLM-5.1, and DeepSeek-V4-Pro (the only survivor, but that’s another storyAlready covered here.). My agent governance methodI documented it in detail in a previous article. relies on AsciiDoc files —AGENT.adoc, INDEX.adoc, PROMPT_REPRISE.adoc— which load ~30,000 tokens of rules, backlog, and history at the start of every session.

And despite this documentary infrastructure, two things struck me:

  1. The LLM forgets. Even with absolute rules at the top of every EAGER file, beyond 60,000 cumulative tokens (initial context + conversation), Kimi K2.6 began suggesting`Write`overwriting configuration files. GLM-5.1 confused a Firebase token with a placeholder to be replaced. The rules were written — the LLM no longer saw them.

  2. Governance itself becomes a problem. After implementing the Hot/Warm/Cold mechanismArticle on backup rotation. to avoid context explosion, my EAGER files still weighed 1414 linesI documented this audit here.. Governance — designed to protect the LLM from saturation — was saturating the LLM.

I needed an alignment mechanism that did not depend on the number of tokens in the prompt.

The answer: stop aligning by text, and start aligning byspace.

The Four Circles of Trust: a Spatial Ontology

My`workspace/folder (in~/workspace/`) is not a Git repository. It is the root of all my work — code, documentation, training, infrastructure. And it is structured into four zones that are not just storage conventions, butconcentric circles of trust:

Level

Label

Physical Zone

CVS

Visibility

0

Secret Garden

`workspace/`root

None

Intimate — free thought, no commit, no publication

1

Vault

configuration/

Private Git (solo)

Secrets, tokens, vision archive. One single person.

2

Library

office/

Private Git (extended)

Pedagogical data, SPG/SPD, JSON schemas. Identified circle of trust.

4

Forges (public)

foundry/

Public Git (Apache 2.0)

Source code, plugins, tests, technical documentation.

There is no level 3 in the table. Level 3 is a transitory level: it is content from`office/`that has been anonymized and is ready to be published as open data. It has no physical zone of its own — it is a state of the data, not a location.

Each level answers a specific question:

  • Where to put an idea that is not yet ready to be shared, even with a restricted circle? → The secret garden. No Git. No pressure.

  • Where to store an API token without it leaking? → The vault (configuration/). Physically isolated. No other repository can reference it by mistake.

  • Where to co-construct a training catalog with a pilot training center? → The library (office/). Versioned, collaborative, but private.

  • Where to industrialize an open source Gradle plugin? → The forges (foundry/). Public, forkable, tested in CI.

This ontology isconsumable by an LLM. When it reads a file in`foundry/plantuml-gradle/src/`, it knows implicitly: "I am in circle 4 — public code, mandatory tests, no secrets, no pedagogical data". It does not need a prompt to remind it.

The Secret Garden: Out-of-CVS Space

This is the most important — and most counter-intuitive — concept.

The`workspace/root has no.git/. The documents that live there (`WORKSPACE_VISION.adoc, WORKSPACE_AS_PRODUCT.adoc, WORKSPACE_ORGANIZATION.adoc— and the one you are reading right now, which originated from it) are not intended to be versioned, shared, or even reread by anyone other than me. They aregerminating thoughts.

The secret garden is out-of-CVS by nature. The absence of versioning is the condition for freedom of thought. One does not write there to be read — one writes to clarify one’s own vision.

But this freedom has a cost: one accidental`rm`and months of strategic reflection disappear. The solution is not to version the garden (that would destroy it) — it is tomirror itinto the most restricted circle.

.gitignore as Governance Configuration

At the root of`workspace/, a minimal.gitignore`file declares thehistory policyfor the secret garden files:

.goosehints
.goose

Ce .gitignore`has no classic Git function (there is no.git/`at the root). It acts as agovernance configuration filethat answers a specific question: which artifacts from the secret garden deserve to be historized, and which are purely transitory?

  • Files listed in`.gitignore`—.goosehints, .goose— are ephemeral artifacts generated by agents. No strategic value. No history.

  • Files`.adoc`of the root —WORKSPACE_VISION.adoc, WORKSPACE_ORGANIZATION.adoc, WORKSPACE_AS_PRODUCT.adoc, WHAT_THE_GAMES_BEEN_MISSING.adoc, depots_implementes_strategie.adoc, synthese-LLMs-long-contexte.adoc— arenotin the`.gitignore`. These are the artifacts to be historized.

Le `.gitignore`is thegovernance schema: everything not listed there is a candidate for a snapshot. And the LLM, by reading this file, knows exactly what must be archived and what can be ignored — without needing to be reminded in a prompt.

The Snapshot Mechanism

I created`configuration/vision-archive/: dated snapshots of all.adoc`of the root, committed to the private repository`configuration/`. Each brainstorming session produces a snapshot:

DATE=$(date +%Y-%m-%d)
mkdir -p /home/cheroliv/workspace/configuration/vision-archive/$DATE
cp /home/cheroliv/workspace/*.adoc /home/cheroliv/workspace/configuration/vision-archive/$DATE/
cd /home/cheroliv/workspace/configuration && git add vision-archive/ && \
  git commit -m "vision-archive: snapshot $DATE"

The procedure is triggered at the end of the session by the LLM itself, which executes this global routing task. Each snapshot captures the complete state of strategic thought at time T.

The Git history of`configuration/`becomes thebiography of my strategic thought. I can do a`git log — vision-archive/`and see the evolution of my vision, session by session, date by date.

Real example of the history after a day of work:

$ git -C configuration log --oneline -- vision-archive/
1089d1b vision-archive: fin de session finale 2026-05-03
6b21eaf vision-archive: fin de session 2026-05-03-1300
1690f82 vision-archive: post-article 2026-05-03
28e6593 vision-archive: post-migration 2026-05-03
3707b78 vision-archive: snapshot 2026-05-03 — jardin secret initial

Five snapshots in one day. Each is a restoration point. Each is a milestone in the genesis of the strategy.

The`configuration/vision-archive/latest/`folder permanently contains aworking copyof the last snapshot, serving as a quick reference without having to navigate the Git history.

And for the LLM, it is acoherence oracle: when it observes a contradiction between the current implementation and the vision archived at an earlier date, it can signal it.

The Vault: configuration/ as Spring Cloud Config

`configuration/`does not only contain the vision archive. Its primary — and future — function is to be aSpring Cloud Config server. All secrets, tokens, credentials, and infrastructure descriptors live here, in a private Git repository accessible only to the owner.

Why a separate repository rather than a`.env`file in each project?

  • Accidental secret push: impossible. Secrets are in a private repository that public projects cannot reference by mistake.

  • Audit: the Git history provides the trail for every configuration change. Who changed what, when, with which SHA hash.

  • Rollback:`git revert`on a broken configuration. Instantaneous, without manual backup.

The Library: office/ as Consumable Data

`office/`is the documentary counterpart to the development work. It contains blog articles, technical specifications, training materials (38 course directories for FPA, SPG/SPD, JSON schemas, Bloom/Harrow/Krathwohl taxonomies) — everything that constitutes thepedagogical material.

But`office/`is not just a doc drawer. It is astructured data sourcethat the Gradle plugins of`foundry/`consume. A blog article in`office/`is an entry that a plugin will transform into HTML. An AsciiDoc SPG in`office/metiers/FPA/`is an artifact that an orchestrator will parse to generate slides, quizzes, and video capsules.

Et le `build.gradle.kts`at the root of`office/`is not business code — it is aconsumption script for the plugin ecosystem. It says: "here are the Gradle plugins I use, here is the context of my workspace".

The Forges: foundry/ as Implementation

foundry/`contains theindustrialized code. 54 Git repositories, 7 of which are currently governed by.agents/`. This is where the vision becomes executable — Gradle plugins, CI/CD, JUnit5 + Cucumber tests.

The relationship with`office/`is bidirectional:

  • office/foundry/: pedagogical data is the raw material that plugins consume.

  • foundry/office/: plugins produce data that enriches`office/` — le `graph.json`of graphify-gradle, compiled slider decks, build reports.

Pro/Contra: Spatial Alignment vs Prompt Alignment

Let’s compare the two approaches.

Classical Approach: Pre-Prompt Alignment

✅ Pro

❌ Contra

Simple to implement. A block of text in the system prompt.

Fragile in long context: the rule is drowned out after 80K tokens.

Works for general rules (tone, format).

Non-verifiable: nothing prevents the LLM from violating the rule.

No need to rethink project architecture.

Non-transferable: each repo redeclares the rules.

Purely declarative: the LLM knows it should, but nothing stops it.

This Approach: Spatial Ontology Alignment

✅ Pro

❌ Contra

Resilient in long context: the rule is in the file path, not in a distant prompt.

Initial infrastructure cost: structuring the workspace into circles takes time.

Mechanically verifiable: a secret in`foundry/is detectable by`git check-ignore.

Requires discipline: a new contributor must understand the circles.

Transferable: a standard`AGENT.adoc`exposes the circles to any new project.

Only covers spatial constraints — code style remains in the prompt.

Security by design: a`git push`from`foundry/cannot expose`configuration/.

Consumable by non-LLM agents: a Gradle orchestrator can route according to the circle.

The main gain is not defensive (security, visibility) — it iscreative. When the LLM works in a space structured by an ontology, it can do what no prompt allows it to: observe the delta.

The Relational Algebra of the Workspace and the Observable Delta

When the LLM traverses`foundry/, it has astructured data lattice: nodes (plugins, files, tests, dependencies), typed edges (`import, depends_on, generates, tests), composition and order relations (`training-gradle`extracts the repository →`slider-gradle`generates the slides →`capsule-gradle`assembles the video).

This algebra is written nowhere in plain text — but it is observable. Every`build.gradle.kts`exposes dependencies. Every`INDEX.adoc`exposes cross-references.

The LLM observes this algebra and detects thedelta: the gap between what the system already knows how to produce and what the vision describes.

From this delta, it can definebusiness expert mappings— CDA (Application Designer Developer, Kotlin/Gradle/JHipster) and FPA (Adult Professional Trainer, Pedagogy/Qualiopi/Bloom) — and identify what is missing for each expert.

Expert CDA (Kotlin/Gradle/JHipster)
  ├── Plugins : jhipster-gradle-plugins, plantuml-gradle,
  │   codebase-gradle
  ├── Delta : pas encore de SPG CDA formalisé,
  │   pas de fine-tuning expert CDA

Expert FPA (Pédagogie/Qualiopi/Bloom)
  ├── Plugins : training-gradle, slider-gradle,
  │   school-backoffice/forms, capsule-gradle
  ├── Matériel : 38 modules cours, SPG/SPD, taxonomies
  └── Delta : parser AsciiDoc→JSON à créer,
      orchestrateur à coder

The LLM does not need to be told what to do. The delta emerges from the structure.

The Composite Context Vector: RAG + pgvector + Graphify

Relational algebra is not a theoretical construction. It is materialized by three components that form acomposite context vectorfor the LLM.

Component 1 — RAG LangChain4j + PostgreSQL pgvector

I already have LangChain4j in production in two plugins:`slider-gradle`(4 LLM providers) and`plantuml-gradle`(7 providers). ONNX embeddings (AllMiniLmL6V2) index the data from`office/`and the source code of`foundry/`in PostgreSQL + pgvector.

This RAG operates on two dimensions:

  • Data dimension: the`office/`documents (SPG, articles, training, JSON schemas)

  • Code dimension: the`foundry/`codebases (Kotlin sources, Cucumber tests, AGENT.adoc)

The intersection covers both the what (the business domain) and the how (the implementation).

Component 2 — Knowledge Graph Graphify

Graphify is integrated into`plantuml-gradle`(109 tests, 380/380 PASS) and produces a`graph.json`— a structured knowledge graph with nodes, edges, and automatically detected communities.

Unlike RAG, which operates via vector similarity (fuzzy), the knowledge graph operates viaexact relations(deterministic):`graphify query`for semantic queries (~50 tokens),`graphify path`for navigation,`graphify explain`for explanation.

Component 3 — Incremental Graphify: Sparse, Aggregatable, Consumable

This is the key architectural decision.

Graphify must not live in a single repository. It must live in asparsemanner across each plugin:

  1. Each plugin carries a Gradle task`updateKnowledgeGraph`that calls Graphifyon its own scopeand produces a`graph.json`local.

  2. The build script of`office/ consumes`graphify-gradle`with`rootDir = /home/cheroliv/workspace`and produces a`graph.json globalthat aggregates the local graphs.

  3. The RAG of each plugin injects the`graph.json`global as acontext filterfor LLM queries.

TÂCHE GRADLE (dans chaque plugin)
    ↓
graphify → graph.json (scope local)
    ↓
office/build.gradle.kts → graph.json (scope global)
    ↓
RAG pgvector (dans slider, plantuml, codebase...)
    ↓  ← injection du graph.json comme filtre
LLM (deepseek-v4-pro)
    ↓  ← observation algèbre relationnelle
    ↓  ← détection delta vs cartographies experts
PRIORISATION → prochaine tâche

Result: the LLM does not search in a vacuum — it navigates in a space structured by the knowledge graph. A query on "generate a diagram" knows how to reach the relevant nodes of the graph.

Automatic GDPR Classification: the LLM as Router

Spatial ontology doesn’t just align the LLM — it gives it aGDPR classification gridto route each piece of data to its legitimate zone.

Criterion

LLM Detection

Action

Max Level

Personal data (name, email, IP)

Pattern`@`, IP, proper names

Anonymize →`[OF_PILOTE]`or route level 2

2

Token / Secret / Credential

Pattern`sk-…​, `ghp_…​, ya29…​

Route →configuration/. Reference by`${VAR}`in code.

1

Internal URL

Contains`localhost`, private IP

Anonymize →${API_URL}

2

Pedagogical data (SPG, course)

Bloom/Qualiopi structure

Route →office/(level 2). Double version if export.

3

Source code / test

Extension`.kt`, .kts`in`foundry/

Route →foundry/. Verify absence of secrets.

4

At the end of a session, the LLM executes aglobal task:

  1. Read the`.gitignore`root to identify ephemeral artifacts (to exclude from snapshot) vs strategic artifacts (to historize)

  2. Inventory of all`.adoc`files of the root`workspace/`

  3. Filtering: exclusion of files listed in`.gitignore`, inclusion of all others

  4. Copy to`configuration/vision-archive/$DATE/and update the symlink`latest/

  5. Commit to the`configuration/`repository with a structured message

  6. Automatic GDPR classification of each modified file (all circles)

  7. Routing:`office/data → private commit,`foundry/`code →./gradlew check`, configuration → commit

  8. Structured report with GDPR alerts and archiving confirmation

Le `.gitignore`root is not a Git configuration file — it is ahistory governance file. It defines the schema that the LLM consumes to decide which secret garden files enter the strategic biography and which are disposable.

The LLM is no longer a simple text generator. It is theinformation managerof the ecosystem — producer, classifier, router.

Roadmap: from AsciiDoc to LangGraph4j

Today, this governance is deterministic: the LLM applies a procedure described in AsciiDoc files. This isphase 1— prompt engineering with LLM memory.

La phase 2will extract each step of the procedure into atyped Gradle task:

./gradlew endSessionWorkspace    → snapshot vision-archive
./gradlew endSessionProject      → archive .agents/
./gradlew endSessionReport       → rapport multi-zones

La phase 3will model the end-of-session process as astate graphwithhttps://github.com/langgraph4j/langgraph4j[LangGraph4j]:

[Start] → [Inventaire fichiers modifiés]
       → [Classification RGPD] (nœud ONNX)
       → [Branchement par cercle]
            ├→ cercle 0 → snapshot → commit
            ├→ cercle 2 → anonymisation → commit
            ├→ cercle 4 → archive → commit
            └→ cercle 1 → commit configuration/
       → [Rapport] → [End]

This graph will be versioned in CI/CD, executed by Gradle, and configured via plugin GitHub Secrets. The LLM will no longer have to decide the routing — the graph will do it.

What This Architecture Solves (and what it doesn’t Solve)

Spatial ontology doesn’t cover everything. Code style conventions, naming, architectural design choices — all that remains in the prompt. What spatial ontology solves is thesecurity and visibility layer: where every byte must live, and who can see it.

Here is what it brings concretely:

  1. No accidental`git push`of a secret: secrets are in`configuration/(circle 1). Public projects are in`foundry/(circle 4). No path crosses both.

  2. No business code in data:`office/contains.adoc`, YAMLs, JSON Schemas — but no`.kt`. Le `build.gradle.kts`that lives there is a consumption script, not business code.

  3. No exposed strategic thought: vision documents live in the secret garden (out-of-CVS root). Snapshots are in`configuration/`(private vault). No one, even in the extended circle of trust, reads the genesis of the strategy.

  4. Auto-prioritization: the LLM observes the delta between the relational algebra (what exists) and the expert mappings (what is necessary). The next development task emerges from this delta.

Conclusion: Architecture as Discourse

I don’t put a political manifesto in my site’s footer. I don’t put ethical rules in my prompts. Alignment is not in the text — it is in thefile system.

When an LLM works in this space, it cannot leak a secret (the path prevents it). It cannot confuse pedagogical data with source code (the physical zone is different). It cannot forget a security rule at 80,000 tokens — because the rule is not in the prompt, it is in the`workspace/→`configuration/office/→`foundry/`that every file read reactivates.

This is the principle of secure by design applied to agent alignment: do not ask the LLM to remember the rules. Make the architecture render the error structurally impossible.

And in the process, it gives the LLM something no prompt can: the ability toperceivewhere it is, what exists, what is missing — and deduce what it must do.

References

Related articles