Knowledge Architecture Standards — Metadata, Structure, and Lifecycles

Purpose and scope

This standards guide explains the minimum metadata, structural rules, lifecycle practices, and governance patterns required to keep content findable, reusable, and maintainable across teams and sites. It is intentionally pragmatic: use these rules as a consistent baseline, then adapt them to local context. The goal is to reduce duplication, improve search relevance, and make it simple to know who owns content and when it needs review.

What this standard covers

• Required and recommended metadata fields and their meanings.
• Category, tag, and taxonomy rules for consistent indexing and faceted search.
• Content types, templates, and small example schemas you can copy.
• Ownership, stewardship, review cadence, retirement and deprecation rules.
• Minimal change-log requirements and versioning guidance.
• Patterns for reuse, inheritance, canonicalization, and redirects.
• Practical author checklist and governance notes for maintainers.

Required metadata (baseline)

All content must include the following fields. Keep values short, consistent, and machine-friendly where possible.

• title — human-friendly title.
• slug — URL-safe identifier (lowercase, hyphens, no spaces).
• summary — one- or two-sentence description used in listings.
• contentType — one of: article, decision-record, experiment-record, checklist, procedure, policy, FAQ, dataset.
• author(s) — name(s) and email/ID for primary author(s).
• owner — team or person responsible for accuracy and review cadence.
• steward — person who manages lifecycle actions (may be same as owner).
• createdDate — ISO date.
• modifiedDate — ISO date (auto-updated on publish/edit).
• status — draft | published | archived | retired.
• version — semantic versioning with major.minor (e.g., 1.2).
• reviewDate — next planned review date (ISO date).
• tags — list of single-word or short phrase tags drawn from agreed tag vocabulary.
• categories — controlled taxonomy values for top-level grouping (one primary category recommended).
• audience — roles or groups who should read/use this content (e.g., operators, managers).
• license — reuse license where applicable.
• relatedResources — canonical IDs or URLs for related decision records, datasets, SOPs.

Recommended metadata (enhances reuse)

• readingTime — estimated minutes to read.
• primaryCustomerImpact — short phrase indicating benefit (quality, safety, uptime, etc.).
• kpiLinks — references to KPIs this content affects.
• canonicalSource — indicates where the authoritative version lives if mirrored.
• experimentTag — for content tied to experiments or trials.

Category, tag and taxonomy rules

Consistency in category and tag usage is essential for faceted search and curated collections.

• Categories are a small controlled list (5–12 values) used for top-level navigation. Select a single primary category.
• Tags are flexible but must come from a managed tag vocabulary. New tags require steward approval if they will be widely used.
• Tags should be singular nouns where practical ("onboarding", not "onboardings").
• Use explicit role-based audience tags (e.g., operator, supervisor) for permission and personalization rules.
• Maintain a synonyms and stoplist file to improve search mapping and avoid tag proliferation.

Content types and example schemas

Below are concise, copy-ready field schemas you can adapt to templates. Use required fields as a minimum; recommended fields add useful structure.

Article (knowledge article)

• Required: title, slug, summary, contentType=article, author(s), owner, createdDate, modifiedDate, status, version, tags, categories
• Recommended: readingTime, audience, relatedResources, canonicalSource

Decision record

• Required: title, slug, contentType=decision-record, date, decisionMadeBy, decisionSummary, rationale, alternativesConsidered, owner, relatedResources, status, version
• Recommended: impacts (list), implementationPlanLink, reviewDate

Experiment record

• Required: title, slug, contentType=experiment-record, hypothesis, startDate, endDate (or expectedEnd), owner, experimentStatus, resultsSummary, relatedResources
• Recommended: metricsTracked, rawDataLocation, lessonsLearned, nextSteps

Onboarding checklist

• Required: title, slug, contentType=checklist, items (ordered list with owner for each item), estimatedCompletionTime, audience, owner, status
• Recommended: prerequisiteContentLinks, version, changeLog

Ownership, review cadence, and stewardship

Clear accountability prevents neglected content. Assign both an owner (long-term responsibility) and a steward (tactical manager of reviews and updates).

• Owner: accountable for content accuracy and for deciding retirement or major changes.
• Steward: runs review cycles, coordinates edits, and updates metadata.
• Review cadence guidance: policies and regulatory content — every 6 months; operational procedures — annually; knowledge articles and experiments — 18 months. Adjust by risk and usage.
• Automatic reminders: set system reminders 30 days before reviewDate to the steward and owner.

Retirement, archiving, and deprecation

• Retire content when it is superseded, obsolete, or no longer accurate. Mark as retired and preserve for audit where required.
• Archive copies of retired items into a discoverable archive collection with clear reason-for-retirement metadata.
• Provide redirects from deprecated slugs to canonical or replacement content to avoid broken links.

Versioning and minimal change log

Maintain a concise, human-readable change log for every published item. At minimum, capture:

• version (major.minor)
• modifiedDate
• changedBy (name/ID)
• short summary of change (1–2 sentences)
• link to diff or attachment if available

Permissions and publishing rules

• Use role-based permissions: who can create, who can edit, who can publish, who can retire.
• Changes that affect safety, compliance, or production processes require owner approval and a documented implementation plan before status moves from draft to published.
• Keep published changes discoverable: highlight recent updates on a team or domain dashboard.

Patterns for reuse, inheritance, and canonicalization

• Prefer a single canonical source for authoritative content; allow copies for local tailoring but track their origin and divergence.
• Use templates and content fragments for repeatable elements (procedure steps, safety notes) so edits propagate when appropriate.
• Document when local copies must periodically reconcile with canonical sources and who is responsible for reconciliation.

Author checklist (quick)

1. Populate all required metadata fields.
2. Assign owner and steward and confirm reviewDate.
3. Pick one primary category and 3–8 tags from vocabulary.
4. Add relatedResources and canonicalSource if applicable.
5. Write a short summary and a concise change-log entry for this version.
6. Confirm publishing permissions and any necessary approvals for the content type.

Search, indexing, and discoverability tips

• Enable faceted search using categories, tags, audience, and contentType.
• Maintain a synonyms list and common misspellings mapping for high-value search terms.
• Curate landing pages for high-priority topics and make sure canonical content links are prominent.

Implementation & tooling notes

These standards are intentionally implementation-agnostic. Practical ways to apply them include:

• Provide templates that enforce required fields at creation time (forms or template scaffolds).
• Automate review reminders using the reviewDate metadata.
• Expose a simple content health dashboard showing items by next reviewDate, status, and owner.

Example: short decision record

• title: "Choose storage format for machine logs"
• contentType: decision-record
• date: 2026-03-21
• decisionMadeBy: "Operations Engineering Council"
• decisionSummary: "Standardize on compressed JSONL in S3 with daily rollups"
• rationale: "Balance between queryability and storage cost; consistent with analytics pipeline."
• owner: data-engineering

Governance and change management cautions (Mal Hungers to avoid)

• Avoid over-engineering: keep taxonomies small and practical to prevent brittleness.
• Do not treat architecture as a one-time project—budget ongoing stewardship and tuning.
• Prevent orphaned content by ensuring owners are real and active roles, not individuals who leave without handover.

Next practical steps

1. Adopt these baseline fields into your publishing templates and enforce required fields at creation.
2. Publish a short tag vocabulary and category list for the domain and solicit steward feedback.
3. Set up automated review reminders and a simple content health view for owners and stewards.

Capability opportunities

This guide can be paired with platform capabilities to make the standard operational:

• Use Interactive Form Rendering (CapabilityID 1) to create authoring forms that enforce required metadata and collect change-log entries.
• Use Content Data Submission and JSON Storage (CapabilityID 2) to store form submissions and allow dashboards to surface reviewDate, status, and ownership data.
• Package these templates and governance rules into an Adaptive Ownable Domain or Toolkit (CapabilityID 3) that teams can copy and tailor to local needs.

If desired, we can create interactive templates and an automated content health dashboard as a follow-up item.