WAP LabsProject atlas

docs/knowledge-graph/readme.md

WAP Compliance Knowledge Graph

This directory contains the human and AI projections of the repository-derived WAP compliance knowledge graph.

The graph is not a new source of truth. Canonical facts remain in:

  • docs/waves/wap-1.2.1-compliance-program.json;
  • spec-processing/source-manifests/wap-1.2.1-release.json;
  • spec-processing/source-manifests/wap-1.2.1-effective-spec.json;
  • spec-processing/source-manifests/wap-1.2.1-class-conformance.json;
  • the family SCR ledgers;
  • spec-processing/source-manifests/wap-1.2.1-selected-normative-clauses.json.

See docs/architecture/decisions/0003-generate-compliance-knowledge-graph.md for the decision and boundaries.

The operational expansion policy is docs/knowledge-graph/SLICE_ADOPTION.md: extend the graph when a compliance implementation slice begins, not through a separate bulk migration.

Supported slices

The initial pilot selects the WML-2 compliance sprint and generates:

  • spec-processing/source-manifests/wap-1.2.1-wml-2-knowledge-graph.json: typed, machine-readable nodes and edges;
  • docs/knowledge-graph/vault/: an Obsidian-compatible Markdown vault;
  • docs/knowledge-graph/context-packs/WML-2.md: a bounded AI context bundle.

The current graph contains the target sprint, its direct dependency/downstream sprints, five work items, source families/documents, directly mapped SCR rows and clauses, planned fixtures, requirements, owner layers, and legacy ticket links.

The pilot intentionally reports remaining gap levels:

  • Machine-derived fact: WML-201 has 178 direct clauses: 175 selected WML clauses plus 3 WAE composition clauses. It also projects the exact WML SCR matrix while retaining direct-test, mapped-gap, and optional-not-assessed evidence states;
  • WML-202 now directly maps 14 root/head/access, template, and task-shadowing clauses adopted by R0-04 and R0-12;
  • WML-204 has 23 completed direct WML clause mappings with exact fixture commands, and completed WML-205 directly maps and implements the three selected error-policy clauses with native invalid-WML tests and executable production-WASM fetch/access failure stories;
  • declared source families without direct clauses remain explicit rather than inferred from broad ownership or adjacent work.

Broad family ownership and cross-family clauses remain valid planning context, but neither is treated as direct clause coverage for a different family.

The TRN-7 slice adds the minimum projection needed for WCMP implementation work:

  • spec-processing/source-manifests/wap-1.2.1-trn-7-knowledge-graph.json;
  • docs/knowledge-graph/vault-TRN-7/;
  • docs/knowledge-graph/context-packs/TRN-7.md.

Its focused TRN-702, TRN-703, TRN-706, and TRN-707 retrieval targets include only the obligations directly mapped to the selected work item and keep unrelated transport work-item details out of the pack. TRN-706 and TRN-707 intentionally retain declared WTP-family gaps while connection-oriented WSP/WTP remains conditional. The TRN-707 pack also includes the explicit WAP-259 successor context linked by that work item. TRN-708 projects the adopted CDPD/IPv4 correction, including its directly mapped WDP and RFC 792 ICMP obligations. The focused TRN-710 target preserves its TRN-703/T0-17 dependencies and projects 27 direct WAP-202 sections 5.1/5.2/5.5 clauses against four capability SCR parents without changing the 198 selected-parent total or the TRN-7-CL-C gate. WAP-202 sections 5.4.1-.7 bearer encapsulations and WAP-159 SMPP clauses remain unimplemented and deferred context, not mapped evidence.

The WML-3 slice adds the bounded runtime projection needed for context, variable, task, event, BACK, form-request, and timer work. Its focused WML-301 target exposes the source-audited 20-clause history, browser-context, deck/card navigation, and inter-card process-order boundary; WML-302 exposes the audited variable-store, substitution, setvar-ordering, and history-resolution obligations; and WML-303 exposes only directly mapped action/event clauses, their selected SCR parents and planned fixtures, the effective WML amendment order, and the explicit WAP-236 successor-only context used by RQ-WAE-017. The focused WML-304 target exposes the current request/access mappings and its declared WAE-family gap without implying readiness. The focused WML-305 target exposes the ten directly mapped timer-lifecycle clauses and their five selected SCR parents without changing fixture status. The focused WML-306 target activates WML-C-15 as an explicit optional Class C capability and exposes the source-audited access, error, unknown-DTD, and task-failure obligations without inferring an unrelated WAE-family mapping.

The WSP-8 slice is the adoption checkpoint for the selected connectionless WSP lane:

  • spec-processing/source-manifests/wap-1.2.1-wsp-8-knowledge-graph.json;
  • docs/knowledge-graph/vault-WSP-8/;
  • docs/knowledge-graph/context-packs/WSP-8.md.

Its focused WSP-801, WSP-802, and WSP-805 targets use only canonical direct-clause mappings. WSP-801 exposes the connectionless PDU, primitive, and method obligations and their selected SCR parents. WSP-802 exposes header and encoding-version obligations. WSP-805 combines its WSP method/PDU obligations with only the WML request-serialization clauses directly owned by the native ingress lane; WAE and WDP remain explicit family gaps until source clauses are selected. The WSP-802 source-scope audit removed the unrelated general-formats family declaration because WAP-188 contains no WSP header grammar. The canonical WSP SCR ledger remains authoritative.

The WMLS-5 slice is the adoption checkpoint for WMLScript language, bytecode, VM, and library work:

  • spec-processing/source-manifests/wap-1.2.1-wmls-5-knowledge-graph.json;
  • docs/knowledge-graph/vault-WMLS-5/;
  • docs/knowledge-graph/context-packs/WMLS-5.md.

Its focused WMLS-501 target exposes the canonical bytecode/interpreter clause mappings and selected SCR parents while preserving the work item’s completed state. Its focused WMLS-502 target bounds language operator, conversion, call, local, return, and control-flow execution without absorbing URL/access, standard-library behavior, or the unfinished error matrix.

Commands

Generate all committed projections:

node spec-processing/scripts/generate-wap-knowledge-graph.mjs

Validate graph integrity and generated drift:

node scripts/check-wap-knowledge-graph.mjs

Print a fresh AI context pack to standard output:

node scripts/wap-context-pack.mjs WML-2

For implementation or review of one pilot work item, request a focused pack:

node scripts/wap-context-pack.mjs WML-203

The supported retrieval targets are WML-2, WML-201 through WML-205, WML-3, WML-301 through WML-306, WML-309, TRN-7, TRN-702, TRN-703, TRN-706 through TRN-708, TRN-710, WSP-8, WSP-801, WSP-802, WSP-805, WMLS-5, WMLS-501, and WMLS-502. A work-item target keeps sprint dependencies and conformance governance in view while limiting work-item details, direct obligations, mapping gaps, and source documents to the selected slice. Other targets remain rejected until their implementation slice starts, so graph expansion is explicit and reviewable.

Graph contract

Every node has:

  • a globally stable ID in <type>:<key> form;
  • a stable domain key such as WML-203 or WBXML-C-001;
  • a controlled node type;
  • a title and source-derived properties.

Every edge has:

  • an ID derived from its endpoints and relationship;
  • an existing from node;
  • a controlled relationship type;
  • an existing to node;
  • one or more canonical repository source references where applicable.

The pilot relationships include:

  • contains and depends-on for execution order;
  • covers-family, owned-by, and relates-to for planning ownership;
  • planned-by and refines for normative work allocation;
  • sourced-from and effective-document for authority;
  • verified-by and maps-to for fixture/requirement traceability;
  • selected-from, targets-profile, and requires-family for WAP-215 profile governance.

Obsidian use

Open docs/knowledge-graph/vault/ as an Obsidian vault. Start at _index.md, then use local Graph view around sprints/WML-2.md or an individual work item.

All notes in that directory are generated. Do not edit them directly. Obsidian configuration, personal layouts, and plugin state should remain local rather than being committed with the compliance projection.

AI retrieval rules

The generated context pack follows four rules:

  1. include the target, its direct execution neighbors, and its work items;
  2. include only clauses with explicit work-item mappings;
  3. include the applicable profile, source documents, fixtures, requirements, and evidence commands;
  4. report both zero-clause and declared-family mapping gaps rather than inferring completion or non-applicability.

This keeps the pack bounded while retaining the information needed to challenge compliance claims.

Codex discovers this workflow through the repository AGENTS.md. Claude Code discovers the same rules through the root CLAUDE.md, which imports AGENTS.md and docs/agents/COMPLIANCE_CONTEXT_RETRIEVAL.md.