# Open Knowledge Format (OKF)

**Version 0.1 — Draft**

OKF is an open, human- and agent-friendly format for representing
*knowledge* — the metadata, context, and curated insight that surrounds
data and systems. It is designed to be authored by people, generated by
agents, exchanged across organizations, and consumed by both.

The format is intentionally minimal: a directory of markdown files with
YAML frontmatter. There is no schema registry, no central authority, and
no required tooling. If you can `cat` a file, you can read OKF; if you
can `git clone` a repo, you can ship it.

---

## 1. Motivation

The space of knowledge representation for AI agents is evolving quickly,
and many incompatible conventions are emerging. OKF takes the position
that knowledge is best represented in commonly accessible, established
formats that are:

- **Readable** by humans without tooling.
- **Parseable** by agents without bespoke SDKs.
- **Diffable** in version control.
- **Portable** across tools, organizations, and time.

The format is minimally opinionated. It standardizes only the small set
of structural conventions needed to make a knowledge corpus
*self-describing* — anything beyond that is left to the producer.

### Goals

1. Define a universal format that **enrichment agents** can write into.
2. Inform how **consumption agents** should read and traverse it.
3. Facilitate **exchange** of knowledge across systems and organizations.
4. Standardize the small number of **required** fields that must be
   present for content to be meaningfully consumed.

### Non-goals

- Defining a fixed taxonomy of concept types.
- Prescribing storage, serving, or query infrastructure.
- Replacing domain-specific schemas (Avro, Protobuf, OpenAPI, etc.) —
  OKF *references* them; it does not subsume them.

---

## 2. Terminology

- **Knowledge Bundle** — A self-contained, hierarchical collection of
  knowledge documents. The unit of distribution.
- **Concept** — A single unit of knowledge within a bundle. Represented
  as one markdown document. May describe a tangible asset (a table, an
  API), an abstract idea (a metric, a business process), or anything in
  between.
- **Concept ID** — The path of the concept's file within the bundle,
  with the `.md` suffix removed. For example, `tables/users.md` has
  concept ID `tables/users`.
- **Frontmatter** — YAML metadata block delimited by `---` at the top of
  a markdown file.
- **Body** — Everything in the file after the frontmatter.
- **Link** — A standard markdown link from one concept to another, used
  to express relationships beyond the implicit parent/child hierarchy.
- **Citation** — A link from a concept to an external source that
  supports a claim in the body.

---

## 3. Bundle Structure

A bundle is a directory tree of markdown files. The directory structure
is independent of the domain — producers organize concepts however makes
sense for the knowledge being captured.

```
path/to/bundle/
├── index.md                      # Optional. Directory listing for progressive disclosure.
├── log.md                        # Optional. Chronological history of updates.
├── <concept>.md                  # A concept at the bundle root.
└── <subdirectory>/               # Subdirectories organize concepts into groups.
    ├── index.md
    ├── <concept>.md
    └── <subdirectory>/
        └── …
```

A bundle MAY be distributed as:

- A git repository (recommended — provides history, attribution, diffs).
- A tarball or zip archive of the directory.
- A subdirectory within a larger repository.

### 3.1 Reserved filenames

The following filenames have defined meaning at any level of the
hierarchy and MUST NOT be used for concept documents:

| Filename     | Purpose                                                |
|--------------|--------------------------------------------------------|
| `index.md`   | Directory listing. See §6.                             |
| `log.md`     | Update history. See §7.                                |

All other `.md` files are concept documents.

Tags themselves remain a first-class concept — see the `tags`
frontmatter field in §4.1. OKF does not specify a separate file format
for aggregating documents by tag; producers that want a tag-browsing
view can synthesize one at consumption time by scanning frontmatter.

---

## 4. Concept Documents

Every concept is a UTF-8 markdown file. It has two parts:

1. A **YAML frontmatter block**, delimited by `---` on its own line at
   the start of the file and a closing `---` on its own line.
2. A **markdown body**, containing free-form content.

### 4.1 Frontmatter

```yaml
---
type: <Type name>                  # REQUIRED
title: <Optional display name>
description: <Optional one-line summary>
resource: <Optional canonical URI for the underlying asset>
tags: [<tag>, <tag>, …]            # Optional
timestamp: <ISO 8601 datetime>     # Optional last-modified time
# … other producer-defined key/value pairs
---
```

**Required:**

- `type` — A short string identifying the kind of concept. Consumers
  use this for routing, filtering, and presentation. Example values:
  `BigQuery Table`, `BigQuery Dataset`, `API Endpoint`, `Metric`,
  `Playbook`, `Reference`.

  Type values are **not** registered centrally. Producers SHOULD pick
  values that are descriptive and self-explanatory; consumers MUST
  tolerate unknown types gracefully (typically by treating them as
  generic concepts).

**Recommended (in priority order):**

- `title` — Human-readable display name. If omitted, consumers MAY
  derive a title from the filename.
- `description` — A single sentence summarizing the concept. Used by
  `index.md` generators, search snippets, and previews.
- `resource` — A URI that uniquely identifies the underlying asset the
  concept describes. Absent for concepts that describe abstract ideas
  rather than physical resources.
- `tags` — A YAML list of short strings for cross-cutting categorization.
- `timestamp` — ISO 8601 datetime of last meaningful change.

**Extensions:** Producers MAY include any additional keys. Consumers
SHOULD preserve unknown keys when round-tripping and SHOULD NOT reject
documents with unrecognized fields.

### 4.2 Body

The body is standard markdown. Producers SHOULD favor structural
markdown — headings, lists, tables, fenced code blocks — over freeform
prose, since structure aids both human reading and agent retrieval.

There are no required body sections. The following section headings have
**conventional** meaning and SHOULD be used when applicable:

| Heading        | Purpose                                                |
|----------------|--------------------------------------------------------|
| `# Schema`     | Structured description of an asset's columns/fields.   |
| `# Examples`   | Concrete usage examples, often as fenced code blocks.  |
| `# References`  | External sources backing claims in the body. See §8.   |

### 4.3 Example: a concept bound to a resource

```markdown
---
type: BigQuery Table
title: Customer Orders
description: One row per completed customer order across all channels.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders, revenue]
timestamp: 2026-05-28T14:30:00Z
---

# Schema

| Column        | Type      | Description                              |
|---------------|-----------|------------------------------------------|
| `order_id`    | STRING    | Globally unique order identifier.        |
| `customer_id` | STRING    | Foreign key into [customers](/tables/customers.md). |
| `total_usd`   | NUMERIC   | Order total in US dollars.               |
| `placed_at`   | TIMESTAMP | When the customer submitted the order.   |

# Joins

Joined with [customers](/tables/customers.md) on `customer_id`.

# References

[1] [BigQuery table schema](https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders)
```

### 4.4 Example: a concept not bound to a resource

```markdown
---
type: Playbook
title: Incident response — data freshness alert
description: Steps to triage a freshness alert on the orders pipeline.
tags: [oncall, incident]
timestamp: 2026-04-12T09:00:00Z
---

# Trigger

A freshness alert fires when `orders` lags more than 30 minutes behind
its expected SLA. See the [orders table](/tables/orders.md).

# Steps

1. Check the [ingestion job dashboard](https://example.com/dash).
2. …
```

---

## 5. Cross-linking

Concepts MAY link to other concepts using standard markdown links. Two
forms are supported:

### 5.1 Absolute (bundle-relative) links

Begin with `/`, interpreted relative to the bundle root.

```markdown
See the [customers table](/tables/customers.md) for the join key.
```

This is the **recommended** form because it is stable when documents are
moved within their subdirectory.

### 5.2 Relative links

Standard markdown relative paths.

```markdown
See the [neighboring concept](./other.md).
```

### 5.3 Link semantics

A link from concept A to concept B asserts a *relationship*. The
specific kind of relationship (parent/child, references, joins-with,
depends-on, etc.) is conveyed by the surrounding prose, not by the link
itself. Consumers that build a graph view typically treat all links as
directed edges of an untyped relationship.

Consumers MUST tolerate broken links — a link whose target does not
exist in the bundle is not malformed; it may simply represent
not-yet-written knowledge.

---

## 6. Index Files

An `index.md` file MAY appear in any directory, including the bundle
root. It enumerates the directory's contents to support **progressive
disclosure** — letting a human or agent see what is available before
opening individual documents.

Index files contain no frontmatter. The body uses one or more sections,
each grouping concepts under a heading:

```markdown
# Section / Group Heading

* [Title 1](relative-url-1) - short description of item 1
* [Title 2](relative-url-2) - short description of item 2

# Another Section

* [Subdirectory](subdir/) - short description of the subdirectory
```

Entries SHOULD include the description from the linked concept's
frontmatter. Producers MAY generate `index.md` automatically; consumers
MAY synthesize one on the fly when none is present.

---

## 7. Log Files (optional)

A `log.md` file MAY appear at any level of the hierarchy to record the
history of changes to that scope. The format is a flat list of
date-grouped entries, newest first:

```markdown
# Directory Update Log

## 2026-05-22
* **Update**: Added new BigQuery table reference for [Customer Metrics](/tables/customer-metrics.md).
* **Creation**: Established the [Dataplex Playbook](/playbooks/dataplex.md).

## 2026-05-15
* **Initialization**: Created foundational directory structure.
* **Update**: Added progressive-disclosure guidelines to the root [index](/index.md).
```

Date headings MUST use ISO 8601 `YYYY-MM-DD` form. Log entries are
prose; the leading bold word (`**Update**`, `**Creation**`,
`**Deprecation**`, etc.) is a convention, not a requirement.

---

## 8. References

When a concept's body makes claims sourced from external material,
those sources SHOULD be listed under a `# References` heading at the
bottom of the document, numbered:

```markdown
# References

[1] [BigQuery public dataset announcement](https://cloud.google.com/blog/products/data-analytics/...)
[2] [Internal data quality runbook](https://wiki.acme.internal/data/quality)
```

Citation links MAY be absolute URLs, bundle-relative paths, or paths
into a `references/` subdirectory that mirrors external material as
first-class OKF concepts.

---

## 9. Conformance

A bundle is **conformant** with OKF v0.1 if:

1. Every non-reserved `.md` file in the tree contains a parseable YAML
   frontmatter block.
2. Every frontmatter block contains a non-empty `type` field.
3. Every reserved filename (`index.md`, `log.md`) follows the structure
   described in §6 and §7 respectively when present.

Consumers SHOULD treat all other constraints as soft guidance. In
particular, consumers MUST NOT reject a bundle because of:

- Missing optional frontmatter fields.
- Unknown `type` values.
- Unknown additional frontmatter keys.
- Broken cross-links.
- Missing `index.md` files.

This permissive consumption model is intentional: OKF is meant to
remain useful as bundles grow, get refactored, and are partially
generated by agents.

---

## 10. Relationship to other formats

OKF is intentionally close to several established patterns:

- **LLM "wiki" repositories** that use markdown + frontmatter as
  agent-readable knowledge bases.
- **Personal knowledge tools** like Obsidian and Notion, which use
  hierarchical markdown with cross-links.
- **"Metadata as code"** approaches that store catalog metadata
  alongside source code rather than in a separate registry.

OKF differs primarily in being **specified** — pinning down the small
set of rules needed for interoperability without dictating tooling.

---

## 11. Versioning

This document specifies OKF version **0.1**. Future revisions will be
versioned in the form `<major>.<minor>`:

- A **minor** version bump introduces backward-compatible additions
  (new optional fields, new conventional section headings).
- A **major** version bump may make breaking changes (renaming required
  fields, changing reserved filenames).

Bundles MAY declare the OKF version they target by including
`okf_version: "0.1"` in a bundle-root `index.md` frontmatter block (the
only place frontmatter is permitted in an `index.md`). Consumers that
do not understand the declared version SHOULD attempt best-effort
consumption rather than refusing the bundle.

---

## Appendix A — Minimal example bundle

```
my_bundle/
├── index.md
├── datasets/
│   ├── index.md
│   └── sales.md
└── tables/
    ├── index.md
    ├── orders.md
    └── customers.md
```

`datasets/sales.md`:

```markdown
---
type: BigQuery Dataset
title: Sales
description: All sales-related tables for the retail business.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales
tags: [sales]
timestamp: 2026-05-28T00:00:00Z
---

The sales dataset contains transactional tables, including
[orders](/tables/orders.md) and [customers](/tables/customers.md).
```

`tables/orders.md`:

```markdown
---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders]
timestamp: 2026-05-28T00:00:00Z
---

# Schema

| Column        | Type      | Description                  |
|---------------|-----------|------------------------------|
| `order_id`    | STRING    | Unique order identifier.     |
| `customer_id` | STRING    | FK to [customers](/tables/customers.md). |
| `total_usd`   | NUMERIC   | Order total in USD.          |

Part of the [sales dataset](/datasets/sales.md).
```

# OKF spec — provenance

This directory's `SPEC.md` is a verbatim, vendored copy of the upstream
Open Knowledge Format specification. Do not hand-edit `SPEC.md`; refresh it
with `scripts/update-spec.sh` so this provenance stays accurate.

| Field | Value |
|---|---|
| Source repo | `GoogleCloudPlatform/knowledge-catalog` |
| Source path | `okf/SPEC.md` |
| Ref | `main` |
| Raw URL | https://raw.githubusercontent.com/GoogleCloudPlatform/knowledge-catalog/main/okf/SPEC.md |
| Retrieved | 2026-06-13T08:21:50Z |
| sha256 | `b9655e607346dbbdc6de21190e9a953313eda6a7eba68d4d272a65975940ad6e` |

# OKF notes

- `type` is the single point of required structure. Identifying/routing metadata → frontmatter; explanation and evidence → body.
- OKF references domain schemas (Avro, Protobuf, OpenAPI) rather than replacing them — link out, don't inline a competing schema.
- **living-docs vs. OKF:** living-docs governs a repo's *internal* decision/requirement records (ADR/PRD); OKF is the portable, exchange-oriented *format* for knowledge bundles meant to be shared or agent-consumed. They compose — a living-docs research corpus can be authored as a spec-conformant OKF bundle.

# OKF conformance (§9)

These five hard rules define OKF conformance. They summarize the vendored spec at
`reference/SPEC.md` §9 — when a detail is ambiguous, the vendored spec wins. If
`scripts/update-spec.sh` reports a changed spec, reconcile these rules against the new §9.

1. **Every non-reserved `.md` file has a parseable YAML frontmatter block** delimited by `---` on
   its own line at the top and a closing `---`.
2. **Every frontmatter block has a non-empty `type` field.** `type` is the only required field.
   Everything else is optional.
3. **Reserved filenames are reserved.** `index.md` (directory listing, §6) and `log.md` (update
   history, §7) must follow their defined structure and must **not** be used for concept documents.
4. **`index.md` carries no frontmatter** — the sole exception is the bundle-root `index.md`, which
   MAY declare `okf_version: "0.1"` (§11).
5. **Consume permissively.** Never reject a bundle for missing optional fields, unknown `type`
   values, unknown extra keys, broken cross-links, or a missing `index.md`. OKF stays useful as
   bundles grow and get partially agent-generated.

# OKF format details

## Core model (§2)

| Term | Meaning |
|---|---|
| **Knowledge Bundle** | Self-contained directory tree of knowledge docs — the unit of distribution (git repo, archive, or subdir). |
| **Concept** | One unit of knowledge = one markdown document. May describe a tangible asset (table, API) or an abstract idea (metric, process). |
| **Concept ID** | The file path within the bundle minus `.md`. `tables/users.md` → `tables/users`. |
| **Frontmatter** | YAML metadata block at the top of the file. |
| **Body** | Everything after the frontmatter. |
| **Link** | A markdown link asserting a relationship; its *kind* comes from surrounding prose, not the link. |
| **Citation** | A link to an external source backing a claim. |

---

## Frontmatter fields (§4.1)

```yaml
---
type: <Type name>                  # REQUIRED — e.g. "BigQuery Table", "API Endpoint", "Playbook"
title: <Display name>              # Recommended
description: <One-sentence summary># Recommended — feeds index/search/previews
resource: <Canonical URI>          # Recommended for real assets; omit for abstract concepts
tags: [<tag>, <tag>]               # Optional
timestamp: <ISO 8601 datetime>     # Optional — last meaningful change
# … any producer-defined keys are allowed
---
```

- `type` values are **not** centrally registered — pick descriptive, self-explanatory strings; consumers treat unknown types as generic concepts.
- Producers MAY add any extra keys; consumers SHOULD preserve unknown keys and never reject on them.

### Conventional body headings (§4.2)

There are no required body sections. Favor structural markdown (headings, tables, lists, fenced code) over prose. Use these headings when applicable: `# Schema` (asset columns/fields), `# Examples` (usage, often code blocks), `# References` (external sources, §8).

---

## Bundle structure (§3)

```
bundle/
├── index.md            # optional directory listing (progressive disclosure)
├── log.md              # optional update history
├── <concept>.md        # a concept at the root
└── <subdir>/
    ├── index.md
    └── <concept>.md
```

Directory layout is domain-independent — organize concepts however the knowledge wants. Reserved files (`index.md`, `log.md`) may appear at any level.

---

## Cross-linking (§5)

- **Absolute (bundle-relative), recommended:** start with `/`, stable across moves — `[customers](/tables/customers.md)`.
- **Relative:** standard markdown paths — `[other](./other.md)`.
- A link is an untyped directed relationship; the kind (joins-with, depends-on, references) lives in the prose. Broken links are tolerated (not-yet-written knowledge).

## References (§8)

List external sources under a trailing `# References` heading, numbered. Links MAY be absolute URLs, bundle-relative paths, or paths into a `references/` subdirectory that mirrors external material as first-class concepts.

# OKF procedure

## Procedure

### Author a concept
1. Copy `templates/concept.md`. Set a non-empty, descriptive `type` (hard rule 2).
2. Fill recommended fields (`title`, `description`, and `resource` if it maps to a real asset). Add `tags`/`timestamp` if useful.
3. Write the body in structural markdown; use `# Schema`/`# Examples` where they fit. Cross-link with bundle-relative `/…` paths.
4. Add a `# References` section for any externally-sourced claim.

### Maintain a directory
1. Keep `index.md` listing the directory's concepts, descriptions mirroring each concept's frontmatter `description` (`templates/index.md`).
2. If the scope tracks history, append a dated entry to `log.md` (newest first, ISO 8601 dates — `templates/log.md`).
3. Declare `okf_version: "0.1"` in the bundle-root `index.md` frontmatter only.

### Check conformance
Walk the five conformance hard rules (`guide conformance --skill okf-knowledge-format`): every non-reserved `.md` has parseable frontmatter; every block has non-empty `type`; reserved files follow §6/§7; root `index.md` is the only `index.md` with frontmatter; consumers stay permissive.

---

## Keeping the spec current

The spec is **vendored** (verbatim) at `reference/SPEC.md` with provenance in `reference/SPEC.source.md`. To pull the latest from GitHub:

```bash
skills/okf-knowledge-format/scripts/update-spec.sh          # default ref: main
skills/okf-knowledge-format/scripts/update-spec.sh v0.2     # a tag/branch/commit
```

The script overwrites `reference/SPEC.md`, rewrites `reference/SPEC.source.md` (URL, ref, retrieval time, sha256), and reports whether the content changed. **If it changed, review the diff and reconcile the conformance rules (`guide conformance --skill okf-knowledge-format`) and the field tables (`guide model --skill okf-knowledge-format`)** before committing — the topics must not drift from the vendored spec. The vendored copy is the offline source of truth; the script is the only sanctioned way to update it.

#!/usr/bin/env bash
# update-spec.sh
# Refreshes the vendored OKF specification from its upstream GitHub source.
#
# The skill ships a pinned, verbatim copy of the OKF SPEC.md under
# reference/SPEC.md so the format rules are usable offline and diffable in
# version control. This script re-pulls the upstream copy, overwrites the
# vendored one, and rewrites reference/SPEC.source.md with fresh provenance
# (URL, ref, retrieval time, sha256). Run it, then review the git diff before
# committing — a non-empty diff means upstream OKF changed and the SKILL.md
# rules may need to follow.
#
# Usage:
#   ./update-spec.sh                 # pull from the default ref (main)
#   ./update-spec.sh v0.2            # pull from a specific tag/branch/commit
#   OKF_RAW_URL=<url> ./update-spec.sh   # override the source entirely
#
# Exit 0 = spec fetched (whether or not it changed)
# Exit 1 = fetch failed

set -euo pipefail

# --- Upstream coordinates (single source of truth for where the spec lives) ---
OKF_REPO="GoogleCloudPlatform/knowledge-catalog"
OKF_PATH="okf/SPEC.md"
OKF_REF="${1:-main}"
OKF_RAW_URL="${OKF_RAW_URL:-https://raw.githubusercontent.com/${OKF_REPO}/${OKF_REF}/${OKF_PATH}}"

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REF_DIR="$(cd "$SCRIPT_DIR/../reference" && pwd)"
SPEC_FILE="$REF_DIR/SPEC.md"
SOURCE_FILE="$REF_DIR/SPEC.source.md"

tmp="$(mktemp)"
trap 'rm -f "$tmp"' EXIT

echo "Fetching OKF spec:"
echo "  repo: $OKF_REPO"
echo "  ref:  $OKF_REF"
echo "  url:  $OKF_RAW_URL"

if ! curl -fsSL "$OKF_RAW_URL" -o "$tmp"; then
  echo "ERROR: failed to fetch $OKF_RAW_URL" >&2
  echo "Network access may be restricted in this environment, or the ref does not exist." >&2
  exit 1
fi

if [[ ! -s "$tmp" ]]; then
  echo "ERROR: fetched spec is empty — refusing to overwrite vendored copy." >&2
  exit 1
fi

new_sha="$(sha256sum "$tmp" | awk '{print $1}')"
old_sha=""
[[ -f "$SPEC_FILE" ]] && old_sha="$(sha256sum "$SPEC_FILE" | awk '{print $1}')"

cp "$tmp" "$SPEC_FILE"

cat > "$SOURCE_FILE" <<EOF
# OKF spec — provenance

This directory's \`SPEC.md\` is a verbatim, vendored copy of the upstream
Open Knowledge Format specification. Do not hand-edit \`SPEC.md\`; refresh it
with \`scripts/update-spec.sh\` so this provenance stays accurate.

| Field | Value |
|---|---|
| Source repo | \`${OKF_REPO}\` |
| Source path | \`${OKF_PATH}\` |
| Ref | \`${OKF_REF}\` |
| Raw URL | ${OKF_RAW_URL} |
| Retrieved | $(date -u +%Y-%m-%dT%H:%M:%SZ) |
| sha256 | \`${new_sha}\` |
EOF

echo
if [[ "$new_sha" == "$old_sha" ]]; then
  echo "Spec unchanged (sha256 $new_sha)."
else
  echo "Spec UPDATED."
  echo "  old sha256: ${old_sha:-<none>}"
  echo "  new sha256: $new_sha"
  echo "Review 'git diff skills/okf-knowledge-format/reference/SPEC.md' and update"
  echo "SKILL.md rules if the conformance requirements changed."
fi

---
type: <Type name>                      # REQUIRED — short, descriptive, self-explanatory
title: <Display name>                  # Recommended
description: <One-sentence summary>     # Recommended — used by index generators / previews
resource: <Canonical URI>              # Recommended when the concept describes a real asset; omit for abstract ideas
tags: [<tag>, <tag>]                    # Optional
timestamp: <ISO 8601 datetime>          # Optional — last meaningful change, e.g. 2026-06-13T00:00:00Z
---

# Schema

<Use when the concept describes a structured asset. Prefer a table.>

| Column / Field | Type | Description |
|---|---|---|
| `field` | TYPE | What it is. Link related concepts like [other](/path/to/other.md). |

# Examples

<Concrete usage, usually fenced code blocks. Delete if not applicable.>

# References

[1] [External source backing a claim](https://example.com)

<!--
OKF index.md — directory listing for progressive disclosure (SPEC §6).
NO frontmatter, with ONE exception: the bundle-root index.md MAY carry a
frontmatter block declaring `okf_version: "0.1"` (SPEC §11). Delete this
comment and the frontmatter block in non-root index files.
-->
---
okf_version: "0.1"
---

# Group Heading

* [Title 1](relative-url-1) - short description (mirror the concept's frontmatter `description`)
* [Title 2](relative-url-2) - short description

# Another Group

* [Subdirectory](subdir/) - what this subdirectory groups

<!--
OKF log.md — chronological update history for this directory scope (SPEC §7).
No frontmatter. Date headings MUST be ISO 8601 YYYY-MM-DD, newest first.
The leading bold word (Update / Creation / Deprecation / Initialization) is a
convention, not a requirement.
-->

# Directory Update Log

## 2026-06-13
* **Creation**: Established the [concept](/path/to/concept.md).
* **Update**: Added a new field to the [other concept](/path/to/other.md).

## 2026-06-01
* **Initialization**: Created foundational directory structure.