Schema Engineering For Durable LLM Wikis

The schema engineering page on the site is intentionally narrow, but its core idea is larger than “make the model emit valid JSON.” Read literally, it defines the schema file as the agent’s operating contract: compact...

Metadata

Field	Value
Source site	llmwikis.org
Source URL	https://llmwikis.org/
Canonical AIWikis URL	https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-archive-2026-04-27-conte-53e425ea/
Source reference	raw/system-archives/llmwikis/agent-file-handoff/Archive/2026-04-27/Content/Schema Engineering for Durable LLM Wikis.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-04-27T12:32:40.2355113Z
Content hash	sha256:53e425eac381223c95e48d429097789008b8035676b1e903f10ee7447adf6895
Import status	unchanged
Raw source layer	data/sources/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-archive-2026-04-27-content-schema-engineering-fo-53e425eac381.md
Normalized source layer	data/normalized/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-archive-2026-04-27-content-schema-engineering-fo-53e425eac381.txt

Current File Content

Structure Preview

• Schema Engineering for Durable LLM Wikis
• Executive summary
• Reading the page
• Patterns and templates
• LLM Wiki Agent Instructions
• Purpose
• Directories
• Page Shape
• Ingest
• Query
• Lint
• Final Response
• Comparison with adjacent approaches
• Workflows and checklists
• Design checklist
• Validation checklist
• Iteration checklist
• Failure modes, metrics, and further reading

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 21556
• Preview characters: 11853

# Schema Engineering for Durable LLM Wikis

## Executive summary

The schema engineering page on the site is intentionally narrow, but its core idea is larger than “make the model emit valid JSON.” Read literally, it defines the schema file as the agent’s operating contract: compact enough to follow reliably, explicit enough to route work, and strict enough to protect raw sources and source-backed claims. Its linked guidance on `AGENTS.md` and `CLAUDE.md` makes that concrete by specifying directory boundaries, deterministic page shapes, three separate operating loops for ingest, query, and lint, and a required final verification summary. citeturn0view0turn1view0turn1view1

That framing only fully clicks when it is read alongside the site’s broader LLM Wiki model. The site defines an LLM Wiki as a file-based system with three durable assets: immutable raw sources, synthesized markdown pages that can be updated, and a small instruction file that governs how the graph is maintained. In other words, schema engineering here is not primarily about serialization; it is about stable boundaries, provenance, review state, and recoverable handoff across sessions or model families. The linked entity["organization","UAIX","ai interoperability standard"] Project Handoff draft reinforces the same pattern by treating `AGENTS.md` as a root coordinator and typed `.uai` files as durable context records. citeturn28view0turn24view0turn3view0

That site-local view aligns surprisingly well with current mainstream implementation guidance from entity["company","OpenAI","AI company"], entity["company","Anthropic","AI company"], and entity["company","Google","technology company"]. Across those platforms, structured outputs and tool definitions are also treated as contracts, usually expressed in JSON Schema or a supported subset of it. Structured outputs shape what the model says; function or tool schemas shape how the model acts. All three providers recommend clear key names and descriptions, local validation after generation, and strong typing where possible. They also all impose practical limits or subsets of full JSON Schema, which means “valid JSON Schema” is not the same thing as “provider-compilable schema.” citeturn5view0turn22view0turn22view2turn13view0turn6view1

For practitioners, the most useful synthesis is this: schema engineering should be treated as a layered discipline. At the outer layer, define a small operating contract for the agent. At the middle layer, define stable page and metadata schemas for the knowledge graph. At the inner layer, define task-local I/O schemas for extraction, classification, contradiction capture, or tool calls. Keep each layer minimal, typed, and testable. Recent research supports this emphasis on discipline: constrained decoding has become the dominant mechanism for structured outputs, JSON Schema has emerged as a de facto standard, and benchmark work shows that performance depends not just on whether a schema exists, but on coverage, compliance, latency, and downstream task quality. Emerging evidence also suggests that key names themselves act as an instruction channel, so wording is not merely cosmetic. citeturn20academia12turn25view1turn25view2turn21view0

## Reading the page

The most important analytical move is to read the page as a statement about control surfaces, not just formatting. The site’s schema guidance says the instruction file should tell the model where it may read, what it may write, what workflows exist, and what it must report back. The linked lint guide extends that contract into maintenance by checking broken links, orphan pages, contradictions, stale claims, and missing provenance. Its source policy adds trust labels so that readers can tell whether a page is canonical-linked, explanatory, reviewed, stale, or archived before relying on it. citeturn1view0turn1view1turn3view0

A useful practitioner interpretation is that the site implies three nested contracts: one for repository behavior, one for knowledge objects, and one for runtime exchange. The first two are explicit on the site; the third is the natural extension used in modern LLM APIs. citeturn0view0turn1view0turn28view0turn5view0turn22view0turn13view0

| Contract layer | Primary artifact | What it constrains | Typical fields or rules |
|---|---|---|---|
| Repository contract | `AGENTS.md` or `CLAUDE.md` | Read/write boundaries, operating loops, reporting discipline | directories, read-only vs writable paths, ingest/query/lint, final summary |
| Knowledge contract | page frontmatter and trust labels | Shape and status of wiki pages | `type`, `status`, `source_status`, `related`, `last_reviewed`, source labels |
| Runtime exchange contract | JSON Schema for outputs or tools | Machine-readable interaction with models and apps | `required`, `enum`, `description`, `additionalProperties: false`, local validation |

Prompt engineering still matters, but it is a different layer. The prompt tells the model what to try to do. Schema engineering tells the system what counts as a valid action or artifact. That distinction is explicit in provider docs: prompt engineering improves instruction following; structured outputs constrain response shape; tool use constrains callable actions; and, in the site’s model, the root schema constrains filesystem behavior and provenance. citeturn17view0turn9view1turn22view0turn29view0

## Patterns and templates

The best site-aligned pattern is contract minimalism. The linked `AGENTS.md` guidance warns against turning the root instruction file into a philosophy essay or dumping every edge case into it; enduring project truth belongs in linked wiki pages, not in the always-loaded control file. That advice closely matches Anthropic’s broader context-engineering recommendation to keep context informative but tight, avoid bloated tool sets, and prefer canonical examples over laundry lists of rules. citeturn1view0turn34view0

A second pattern is explicit asymmetry between immutable evidence and writable synthesis. The site’s LLM Wiki definition treats raw sources as durable originals, while markdown pages are compiled derivatives that can be extended over time. That is a strong practical design: source loss, source mutation, and silent synthesis drift become detectable rather than habitual. citeturn28view0turn1view0turn1view1

A third pattern is to treat names, keys, and descriptions as part of the instruction surface. OpenAI recommends intuitive keys plus clear titles and descriptions. Gemini recommends descriptions and strong typing. Anthropic places unusually strong emphasis on detailed tool descriptions and example inputs. A recent arXiv paper goes further and argues that schema key wording can materially change performance under constrained decoding, suggesting that field names function as implicit instructions, not just parser labels. citeturn7view0turn13view0turn22view1turn21view0

A fourth pattern is two-pass validation: first let the provider enforce structural conformance, then validate locally against the original application schema. That second pass matters because providers support subsets of JSON Schema and because syntactic validity does not guarantee semantic correctness. Anthropic’s SDKs explicitly simplify unsupported constraints into descriptions and then validate against the original schema; Gemini warns that structured output guarantees correct JSON, not semantically correct values; and Pydantic and Zod both support generating JSON Schema and validating parsed results locally. citeturn31view3turn13view0turn33view0turn33view1turn33view2

The following root contract stays close to the site’s minimal form while keeping the action surface compact and explicit. It is a good default for the site’s practitioner audience. citeturn1view0turn24view0

```md
# LLM Wiki Agent Instructions

## Purpose
Maintain this markdown LLM Wiki by compiling raw sources into durable, linked wiki pages.

## Directories
- raw/: read-only source material. Never edit, move, or delete.
- wiki/: compiled markdown graph. Writable.
- wiki/index.md: required catalog of public pages.
- wiki/log.md: append-only activity log.

## Page Shape
Every page must include:
- title
- type: concept | entity | source-summary | synthesis | contradiction | runbook
- status: draft | reviewed | needs-update | archived
- source_status: source-linked | source-needed | derived
- related: list of wiki paths or wiki-links
- last_reviewed

## Ingest
When asked to ingest:
1. Read raw/ without editing it.
2. Create or update one source-summary page.
3. Extract summary, claims, evidence, entities, contradictions, and update targets.
4. Update related concept, entity, or synthesis pages.
5. Preserve unresolved disagreements unless a human resolves them.
6. Update index.md and append to log.md.

## Query
When asked a question:
1. Read wiki/index.md first.
2. Open the smallest useful page set.
3. Cite local wiki paths.
4. Mark unsupported claims as unsupported.
5. Ask before saving new synthesis.

## Lint
Check broken links, orphan pages, stale claims, contradictions, missing metadata, and missing provenance.
Do not delete pages without explicit approval.

## Final Response
Report changed files, sources used, contradictions found, and checks performed.
```

For task-local model I/O, the site’s ingest loop maps cleanly to a strict extraction schema. This is where mainstream structured outputs become useful inside the site’s broader operating model. The template below combines site-specific fields with provider-friendly conventions such as required keys, enums, and `additionalProperties: false`. citeturn1view0turn5view0turn29view0turn13view0

```json
{
  "type": "object",
  "properties": {
    "summary": {
      "type": "string",
      "description": "A concise source summary in 2 to 4 sentences."
    },
    "claims": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "claim": { "type": "string" },
          "support": {
            "type": "string",
            "enum": ["source-linked", "source-needed", "derived"]
          },
          "evidence_locator": { "type": "string" }
        },
        "required": ["claim", "support", "evidence_locator"],
        "additionalProperties": false
      }
    },
    "contradictions": {
      "type": "array",
      "items": { "type": "string" }
    },
    "update_targets": {
      "type": "array",
      "items": { "type": "string" }
    }
  },
  "required": ["summary", "claims", "contradictions", "update_targets"],
  "additionalProperties": false
}
```

A site-aligned ingest prompt can then stay extremely short: *“Read `raw/2026-04-source.pdf` without editing `raw/`. Return JSON matching `SourceIngestV1`. If evidence is insufficient, mark support as `source-needed` instead of guessing. Propose `wiki/` pages to update, but do not write until asked.”* That prompt works because the root contract already supplies behavior, boundaries, and page-shape expectations. citeturn1view0turn17view0turn34view0

## Comparison with adjacent approaches

The distinctions below synthesize the site’s framing with official provider guidance. The short version is that schema engineering is not a substitute for prompts, tools, or structured outputs; it is the layer that makes them composable and durable. citeturn17view0turn9view1turn22view0turn13view0turn29view0

| Approach | Main artifact | What it primarily controls | Best use case | Typical failure mode |
|---|---|---|---|---|
| Prompt engineering | instructions and examples | behavior, tone, task framing | one-shot tasks, reasoning guidance, few-shot behavior shaping | good answers in the wrong format, brittle behavior across model changes |

Why This File Exists

This is a memory-system evidence file from llmwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: Schema Engineering for Durable LLM Wikis; Executive summary; Reading the page; Patterns and templates; LLM Wiki Agent Instructions; Purpose; Directories; Page Shape. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-408 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Schema Engineering For Durable LLM Wikis",
    "source_site":  "llmwikis.org",
    "source_url":  "https://llmwikis.org/",
    "canonical_url":  "https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-archive-2026-04-27-conte-53e425ea/",
    "source_reference":  "raw/system-archives/llmwikis/agent-file-handoff/Archive/2026-04-27/Content/Schema Engineering for Durable LLM Wikis.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:53e425eac381223c95e48d429097789008b8035676b1e903f10ee7447adf6895",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-04-27T12:32:40.2355113Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-408",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}