# Create Epistemology Document

> Creates or updates EPISTEMOLOGY.md from repository evidence and architecture context. Use when a project needs to define, repair, or review how it acquires and validates knowledge.

- Skill: `egohygiene/create-epistemology-document` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add egohygiene/create-epistemology-document`
- Raw SKILL.md: https://api.skillmd.com/api/skills/egohygiene/create-epistemology-document/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: egohygiene (https://skillmd.com/u/egohygiene)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/egohygiene/create-epistemology-document

---


# Create Epistemology Document

<!-- aether-continuity-disposition: reader-writer -->

## Repository continuity composition

For repository-scoped work, compose `maintain-repository-continuity` in
**Resume** mode before selecting work. After an authorized repository change
passes domain validation, compose **Refresh** and **Verify** immediately before
presenting the pull request, and include the reconciled root `CONTINUITY.md` in
the same change. A policy-permitted no-change or exemption result must be
documented instead of fabricating an edit.

- **Contribute:** Knowledge sources, evidence labels, validation methods, uncertainty, and open questions
- **Never claim:** That unknown, inferred, or unavailable evidence is verified knowledge

## Purpose

Create or update `EPISTEMOLOGY.md` in conformance with `architecture-epistemology`.

The document must answer:

> How do we determine whether a claim is sufficiently supported, how certain we are, and how that knowledge may change?

## Use this skill when

- the canonical document does not exist
- the existing document is incomplete or inconsistent
- upstream architecture changed materially
- the repository architecture system is being established or repaired
- a repeatable, validated authoring workflow is needed

## Do not use this skill for

- treating authority as proof
- hiding disagreement
- using undefined confidence labels
- presenting decisions as facts

## Required inputs

- governing specification and version
- required upstream architecture documents
- applicable policies and decisions
- existing repository evidence
- known conflicts, assumptions, and open questions

Missing evidence must be recorded rather than invented.

## Workflow

1. inventory existing evidence, provenance, confidence, and decision practices
2. identify recurring knowledge failures and ambiguity
3. define claim states and their meanings
4. define source and evidence evaluation criteria
5. define confidence and uncertainty language
6. define conflict-resolution and canonicalization rules
7. test the model against contradictory and incomplete evidence
8. validate applicability to humans and AI systems

## Output contract

Produce:

- `EPISTEMOLOGY.md`
- governing specification identifier and version
- assumptions and unresolved questions
- validation results
- downstream review recommendations

## Constraints

- Preserve canonical terminology.
- Separate evidence, inference, proposal, and decision.
- Do not invent organizational intent or authority.
- Do not silently resolve contradictions.
- Do not claim completion when required inputs are missing.
- Keep implementation detail outside the document unless the specification
  explicitly requires it.

## Validation

Use:

    references/validation-checklist.md

and the acceptance criteria in:

    architecture-epistemology

## Completion criteria

- [ ] The governing specification is identified.
- [ ] Required upstream evidence has been read.
- [ ] The document answers its primary question.
- [ ] Responsibilities and non-responsibilities are respected.
- [ ] Assumptions and unresolved questions are visible.
- [ ] Structural, semantic, relationship, and evidence checks pass.
- [ ] Downstream review needs are reported.