Context Engineering

Prompt engineering decides what to ask the model. Context engineering decides what to put in front of it so the answer is grounded in reality rather than the model’s memory. UOM leans heavily on the second — it is the difference between “code that looks right” and “code that compiles and returns the same data.”

​

1. What “Context Engineering” Means Here

• invent a package version that does not exist,
• pick an arbitrary collection/field name that does not match your database,
• emit a query that compiles but reads the wrong field,
• or wrap everything in boilerplate (drivers, config loaders, serializers) that drifts from what the sandbox actually expects.

1. Framework configuration — the exact .csproj / pom.xml (versions, dependencies, language level).
2. Schema mappings — the canonical relational→document / relational→graph mapping, including naming and embedding rules.
3. Compilation skeletons — full, verified harness programs the model only has to fill in.

​

2. Ground-Truth Schema Mappings

• mappings/mssql_mongodb.json — maps relational MSSQL tables/columns onto MongoDB collections/fields, including embedding strategy.
• mappings/mssql_neo4j.json — maps relational MSSQL tables/columns onto Neo4j node labels, properties, and relationship directions.

{
  "version": "1.8.0",
  "project": {
    "name": "UOM WideWorldImporters",
    "type": "SQL_SERVER",
    "content": {
      "settings": { "casing": "CAMEL_CASE", "keyHandling": "GENERATED" },
      "collections": {
        "5bd7402f-...": { "name": "orders" },
        "67c830a5-...": { "name": "orderLines" }
      },
      "mappings": {
        "84a19f24-...": {
          "settings": {
            "type": "EMBEDDED_DOCUMENT_ARRAY",
            "embeddedPath": "stockItemStockGroups",
            "foreignKeyName": "FK_Warehouse_StockItemStockGroups_StockItemID_..."
          },
          "fields": {
            "StockItemID": {
              "target": { "name": "stockItemId", "type": "INTEGER" },
              "source": { "name": "StockItemID", "databaseSpecificType": "int", "isPrimaryKey": false }
            }
          }
        }
      }
    }
  }
}

• Exact casing rules (StockItemID → stockItemId, CAMEL_CASE) so generated @Field(...) names match the documents on disk.
• Embedding decisions (EMBEDDED_DOCUMENT_ARRAY, embeddedPath) — i.e. that StockItemStockGroups rows are embedded inside their parent stock item rather than stored as a separate collection. This is the single hardest part of relational→document mapping, and it is provided as fact, not inferred.

​

3. Compilation Skeleton Snippets

​

4. Why the Context Lives in the Orchestrator’s context/ Folder

1. Single source of truth, reused twice. The same .csproj/pom.xml and harness skeletons are both injected into the prompt and shipped into the compile sandbox. One file, zero drift.
2. Pair-scoped injection = token efficiency. At runtime, only the active source and target files are read (FRAMEWORK_TO_CONFIG_FILES / FRAMEWORK_TO_SNIPPET_FILES). The prompt never carries context for the four frameworks you are not using.
3. Editable without touching code. Adding a framework or bumping a dependency version is a matter of dropping a file in context/ and registering it in constants.py — no prompt rewrite. This is exactly the extension path described in the Contribution Guide.
4. Versionable & reviewable. Because they are real files in git, the ground-truth context is diffable and code-reviewable like any other source.

​

Key benefits, summarised

1. Minimises dependency errors — pre-pinned NuGet/Maven dependencies leave nothing for the model to invent.
2. Standardised serialization — skeletons define exact ISO date and decimal (3 d.p.) formatting, so the DeepDiff equivalence check compares like-for-like data shapes.
3. No boilerplate generation — the model spends its tokens on the translation, not on regenerating drivers, config loaders, and test rigs, keeping its attention focused and the output faster and more accurate.

​

5. Related Reading