SCHEMA

Wiki Schema — sw30labs

Organization: sw30labs Purpose: Central knowledge base for AI security, OSCAL compliance, agentic frameworks, local inference, and developer tools.

Single source of truth for taxonomy. Both detect_changes.py and generate_sitemap.py read this file via scripts/taxonomy.py. Keep IDs stable — they are referenced in every stub's frontmatter.

Taxonomy

categories:
  - id: ai-security
    name: AI Security & Pentesting
    dir: wiki/ai-security/
    desc: Pentesting tools, threat modeling, LLM red-teaming, AI security research.

  - id: oscal-compliance
    name: OSCAL & Compliance
    dir: wiki/oscal-compliance/
    desc: OSCAL-driven compliance automation, NIST frameworks, zero-trust lenses.

  - id: agentic-frameworks
    name: Agentic Frameworks
    dir: wiki/agentic-frameworks/
    desc: Agent orchestration, multi-agent systems, agent runtimes.

  - id: local-inference-mlx
    name: Local Inference & MLX
    dir: wiki/local-inference-mlx/
    desc: On-device inference, Apple MLX, model distillation, local serving.

  - id: developer-tools
    name: Developer Tools
    dir: wiki/developer-tools/
    desc: Utilities, converters, scripts, general developer productivity.

stacks:
  - id: mlx
    name: Apple MLX
    desc: Runs on or targets the MLX framework / Apple Silicon.

  - id: oscal
    name: OSCAL
    desc: Uses the OSCAL data model (SSPs, profiles, controls, assessment).

  - id: agentic
    name: Agentic
    desc: Multi-agent orchestration, agent loops, tool-using agents.

  - id: pentest
    name: Pentest
    desc: Offensive security, red-teaming, vulnerability discovery.

  - id: compliance
    name: Compliance
    desc: Regulatory frameworks, controls mapping, audit automation.

  - id: rag
    name: RAG
    desc: Retrieval-augmented generation, vector stores, document pipelines.

  - id: mcp
    name: MCP
    desc: Model Context Protocol servers, clients, or tooling.

  - id: langgraph
    name: LangGraph / LangChain
    desc: Built on LangGraph, LangChain, or related framework.

  - id: converter
    name: Converter
    desc: File-format converters, OCR, doc-to-markdown, media transcription.

  - id: cli
    name: CLI / Tooling
    desc: Command-line utilities and developer workflow glue.

Tag whitelist

All content must be tagged with one or more of these controlled tags:

python, langgraph, langchain, mlx, apple-silicon, oscal, nist, security, compliance, pentesting, llm, local-inference, azure, openai, tts, stt, chromadb, faiss, pydantic, fastapi, streamlit, cli, docker, mcp, zero-trust, digital-twin, rag, lora, distillation, audio, video, ocr, benchmark, qwen

Voice

Concise, technical, present tense, practitioner-oriented. Write for someone who builds with these tools, not someone evaluating them from the outside.

Freshness

Number of days after which a wiki page's updated: date is considered stale by detect_changes.py.

freshness_threshold_days: 90

Quality Standards

• Format: Markdown files with inline code examples, architectural diagrams (ASCII or linked), and links to external references.
• Metadata: Each file includes a YAML frontmatter block with title, tags, and last-updated date.

Directory Structure

wiki-repo/
├── SCHEMA.md          # This file
├── Index.md           # Taxonomy overview and entry points
├── Log.md             # Change log and bootstrap entries
├── Sitemap.md         # Auto-generated category-view sitemap
├── Sitemap-Stacks.md  # Auto-generated stacks-view sitemap
├── raw/               # Repo stubs (.stub.md)
├── wiki/
│   ├── ai-security/
│   ├── oscal-compliance/
│   ├── agentic-frameworks/
│   ├── local-inference-mlx/
│   ├── developer-tools/
│   └── articles/      # Published article summaries + timeline

Rules

• Every repo stub MUST declare exactly one category: (from the list above).
• Every repo stub SHOULD declare one or more stacks: using inline form: stacks: [mlx, agentic]. Zero is allowed but shows up in the "Unclassified" bucket in Sitemap-Stacks.md.
• Category and stack IDs are kebab-case and must not be renamed casually — a rename is a breaking change that touches every stub.
• Adding a new category or stack: append to the relevant list here, then the curator picks it up on the next run.
• Removing a category: first re-home every stub that references it, then delete the entry.
• The dir: field is informative — the curator uses it when placing new stubs; existing stubs stay where they are unless manually moved.

Workflow

1. Capture: Repos are cloned into ~/Documents/sw30labs/repos/; article source into articles-published.
2. Synthesis: Curator writes stubs under raw/ and category/article pages under wiki/.
3. Link: Index.md is updated; pages cross-link via [[wikilinks]] and [^src:stub-id] citations.
4. Log: Significant additions and updates recorded in Log.md.

How scripts use this file

• scripts/taxonomy.py parses the fenced yaml block (restricted grammar — no PyYAML dependency).
• scripts/detect_changes.py reports stubs with missing/unknown category or unknown stack IDs.
• scripts/generate_sitemap.py uses categories: for the default view and stacks: for --view stacks.
• Anything outside the yaml fence (like this prose) is ignored by the scripts but useful for humans maintaining the file.