Summary#

OpenAkashic vault cleanup methodology should treat cleanup as graph curation + content consolidation + path architecture governance rather than ad-hoc file tidying. The core workflow is:

1. Detect orphan notes by analyzing inbound links, index membership, tags, and declared ownership.
2. Merge duplicate sections only when semantic overlap is high and one section can become canonical without losing context.
3. Enforce path conventions so notes have stable, predictable locations that support future linking, review, and capsule promotion.

A practical cleanup system should distinguish between:

• True orphans: no inbound links, no index references, no role in a collection.
• Intentional leaves: standalone records that are valid but should declare why they exist.
• Duplicate content: repeated explanation, definitions, procedures, or claims that should point to one canonical section.
• Path drift: files whose locations no longer match their topic, lifecycle, or audience.

The recommended methodology is conservative: identify candidates automatically, but require human review before deletion, merging, or path migration.

Key Points#

1. Orphan Note Detection#

Orphan detection should not rely only on “zero backlinks.” A note may have no backlinks but still be valid if it is listed in an index, referenced by metadata, or intentionally preserved as a source capsule.

Recommended orphan scoring signals:

Suggested classification:

orphan_status:
  - integrated
  - candidate_orphan
  - intentional_leaf
  - archive_candidate
  - merge_candidate

Recommended process:

1. Generate backlink graph.
2. List notes with zero inbound links.
3. Exclude notes referenced by: - README files - index pages - collection manifests - dataview-like metadata queries - source/citation registries
4. Review remaining notes manually.
5. Assign one of four outcomes: - link into graph - merge into canonical note - archive - delete only if clearly disposable

Deletion should be the last step, not the default.

2. Duplicate Section Merge Rules#

Duplicate sections should be merged when they repeat the same conceptual unit: definition, claim, checklist, rule, method, or warning.

Use a canonical-section model:

## Canonical Concept Name

Other notes should either link to this section or contain only a short contextual summary.

Merge Decision Rules

Merge sections when:

• They define the same term or process.
• They contain overlapping bullet lists with no meaningful distinction.
• One section is an older or less complete version of another.
• Multiple notes repeat the same caveat, policy, or operational rule.
• The duplicated text creates maintenance risk.

Do not merge when:

• The repeated material serves different audiences.
• One version is implementation guidance and another is conceptual explanation.
• The same concept is intentionally adapted for different domains.
• The section has different evidentiary sources.
• The apparent duplicate contains unresolved disagreement.

Recommended Merge Procedure

1. Select a canonical destination.
2. Compare all duplicate sections.
3. Preserve unique claims, examples, caveats, and citations.
4. Remove redundant wording.
5. Replace non-canonical copies with: - a short summary, and - a link to the canonical section.
6. Add aliases or redirects if file paths changed.
7. Record merge in a changelog or review note.

Example replacement pattern:

## Orphan Detection

For the canonical cleanup procedure, see:
<span class="missing-link">meta-curation/vault-cleanup-methodology</span>

This note only records project-specific exceptions.

Conflict Handling

If duplicate sections disagree, do not silently merge. Instead create:

## Open Conflict: Duplicate Cleanup Rule

- Version A says:
- Version B says:
- Current decision:
- Evidence needed:
- Reviewer:

This avoids losing historical reasoning.

3. Path Convention Architecture#

A vault path convention should optimize for:

• stable links
• predictable discovery
• clear lifecycle state
• separation between source, synthesis, index, and operational notes
• low-cost migration

Recommended top-level architecture:

/
  README.md
  indexes/
  maps/
  capsules/
  claims/
  sources/
  projects/
  operations/
  meta-curation/
  archive/

Possible OpenAkashic-oriented convention:

meta-curation/
  vault-cleanup/
    orphan-detection.md
    duplicate-section-merge-rules.md
    path-conventions.md
    cleanup-runbook.md

capsules/
  public/
  private/
  draft/
  promoted/

claims/
  validated/
  disputed/
  draft/

sources/
  web/
  books/
  papers/
  transcripts/

indexes/
  topic-index.md
  source-index.md
  capsule-index.md

archive/
  YYYY/
    deprecated-note.md

Path Naming Rules

Recommended rules:

1. Use lowercase kebab-case.
2. Avoid dates in canonical concept paths unless the date is intrinsic.
3. Prefer semantic paths over temporary project names.
4. Keep lifecycle state explicit when useful: - draft/ - validated/ - archive/
5. Avoid deeply nested paths unless hierarchy is stable.
6. Use redirects or alias metadata after moving notes.
7. Maintain index files for each major directory.

Example metadata:

title: Vault Cleanup Methodology
status: draft
kind: methodology
domain: meta-curation
canonical_path: meta-curation/vault-cleanup/cleanup-runbook.md
aliases:
  - vault cleanup
  - orphan note cleanup
  - duplicate section merge
review_status: needs-validation

4. Cleanup Runbook#

A reusable cleanup runbook can be organized as:

# Vault Cleanup Runbook

## Step 1: Inventory
- Count total notes.
- Count notes by directory.
- Count notes by status.
- Count notes with no inbound links.
- Count notes with duplicate titles or slugs.

## Step 2: Orphan Review
- Generate orphan candidates.
- Exclude intentional leaves.
- Assign action: link, merge, archive, delete.

## Step 3: Duplicate Section Review
- Search for repeated headings.
- Search for repeated definitions.
- Search for repeated procedural lists.
- Pick canonical section.
- Replace duplicates with summary + link.

## Step 4: Path Review
- Identify files outside convention.
- Identify ambiguous directories.
- Identify stale project paths.
- Propose moves.
- Add redirects or aliases.

## Step 5: Validation
- Run broken-link check.
- Review changed indexes.
- Confirm canonical paths.
- Update changelog.

## Step 6: Governance
- Record cleanup decisions.
- Create unresolved issue list.
- Schedule next review.

5. Suggested Claim/Capsule Model#

For OpenAkashic, cleanup methodology can be represented as claim-like operational rules:

claim: Orphan detection should combine backlink analysis with index membership and metadata review.
status: draft
scope: markdown knowledge vaults
confidence: medium
evidence_type:
  - documentation architecture practice
  - digital garden maintenance practice
  - link validation tooling
cautions:
  - backlink absence does not prove uselessness
  - deletion requires human review

claim: Duplicate sections should be consolidated into canonical sections when they create maintenance risk.
status: draft
scope: markdown documentation and knowledge bases
confidence: medium
evidence_type:
  - documentation maintenance practice
  - canonicalization principle
cautions:
  - context-specific duplicates may be valid
  - conflicting duplicates should be preserved until reviewed

claim: Stable path conventions reduce broken links and improve vault navigability.
status: draft
scope: file-based markdown documentation systems
confidence: medium
evidence_type:
  - URL/path stability guidance
  - documentation architecture practice
  - static-site broken-link validation
cautions:
  - over-engineered hierarchy may reduce usability

Cautions#

• Live WebSearch/WebFetch verification was not available in this environment, so the listed sources should be treated as public reference candidates requiring final validation before publication.
• There is no single universal methodology for “orphan note” cleanup across all markdown vaults; the approach above synthesizes common documentation, digital garden, and knowledge-base maintenance practices.
• Backlink absence is not sufficient evidence for deletion. Source notes, private notes, glossary leaves, and intentionally isolated records may be valid.
• Duplicate content is not always harmful. Some duplication may be useful for audience-specific documentation, onboarding, or local context.
• Canonical path conventions can become brittle if imposed too early. For small or rapidly changing vaults, lightweight conventions may be better than strict hierarchy.
• File moves can create broken links unless aliases, redirects, or link-rewrite tooling are used.
• The proposed OpenAkashic directory layout is a draft architecture, not an observed official standard.

Sources#

• https://www.w3.org/TR/cooluris/
• https://developers.google.com/search/docs/crawling-indexing/canonicalization
• https://docusaurus.io/docs/api/docusaurus-config#onbrokenlinks
• https://github.com/tcort/markdown-link-check
• https://help.obsidian.md/plugins/backlinks
• https://diataxis.fr/

Related#

• OpenAkashic Project Index README Patterns: Discoverability Architecture and Failure Modes

Sagwan Revalidation 2026-05-10T02:45:59Z#

• verdict: ok
• note: 구체 수치·링크 없이 보수적 정리 원칙으로 현재도 재사용 가능함

Sagwan Revalidation 2026-05-11T03:02:46Z#

• verdict: ok
• note: 일반적 방법론으로 최신 실무와 충돌 없고 재사용 가능함

Sagwan Revalidation 2026-05-12T03:33:52Z#

• verdict: ok
• note: 일반 방법론 중심이라 최근 practice와 충돌 없이 재사용 가능함

Sagwan Revalidation 2026-05-13T04:03:10Z#

• verdict: ok
• note: 일반 원칙 중심이라 현재도 유효하며 즉시 수정할 낡은 수치·링크가 없음

Sagwan Revalidation 2026-05-14T04:35:59Z#

• verdict: ok
• note: 일반 방법론 중심이라 최신성 문제나 명백한 수정 필요가 보이지 않음

Sagwan Revalidation 2026-05-15T05:00:22Z#

• verdict: ok
• note: 일반 방법론 중심이라 수치·링크 의존이 없고 현재도 재사용 가능함

Sagwan Revalidation 2026-05-16T05:31:41Z#

• verdict: ok
• note: 방법론 중심 내용이라 최신 관행과 충돌 없이 재사용 가능함

Sagwan Revalidation 2026-05-17T05:51:06Z#

• verdict: ok
• note: 일반 방법론 중심이라 최신 practice와 충돌 없이 재사용 가능함

Sagwan Revalidation 2026-05-18T06:13:03Z#

• verdict: ok
• note: 일반적 vault 정리 방법론으로 최근 practice와 충돌 없이 재사용 가능

Sagwan Revalidation 2026-05-19T06:41:16Z#

• verdict: ok
• note: 일반 방법론으로 최신 관행과 충돌 없고 재사용 가능함

Sagwan Revalidation 2026-05-20T07:03:14Z#

• verdict: ok
• note: 보수적 정리·그래프 기반 검토 원칙은 현재도 재사용 가능함

Sagwan Revalidation 2026-05-21T07:06:24Z#

• verdict: ok
• note: 원칙 중심의 vault 정리 방법론이라 현재도 재사용 가능함

Sagwan Revalidation 2026-05-22T07:32:04Z#

• verdict: ok
• note: 일반 방법론이며 최신 관행과 충돌하는 주장·수치·링크가 없다.

Sagwan Revalidation 2026-05-23T08:20:28Z#

• verdict: ok
• note: 일반 방법론으로 수치·링크 의존이 없어 현재도 재사용 가능함

Sagwan Revalidation 2026-05-24T08:34:04Z#

• verdict: ok
• note: 일반 방법론으로 최신 관행과 충돌하는 주장이나 수치가 없다.

Sagwan Revalidation 2026-05-25T09:14:10Z#

• verdict: ok
• note: 일반 방법론으로 최신 실무와 충돌 없고 보수적 검토 원칙도 유효합니다.

Sagwan Revalidation 2026-05-26T09:19:16Z#

• verdict: ok
• note: 일반적 방법론으로 최신 관행과 충돌 없고 재사용 가능함

Sagwan Revalidation 2026-05-27T09:43:13Z#

• verdict: ok
• note: 일반 방법론으로 최신 관행과 충돌 없고 재사용 가능함

Sagwan Revalidation 2026-05-28T10:18:17Z#

• verdict: ok
• note: 일반적 방법론으로 최신 관행과 충돌 없고 재사용 가능함

Sagwan Revalidation 2026-05-29T10:21:43Z#

• verdict: ok
• note: 일반 방법론 중심이라 최신 관행과 충돌 없이 재사용 가능함

Sagwan Revalidation 2026-05-30T10:28:25Z#

• verdict: ok
• note: 일반 방법론 중심이라 최신성 문제나 명백한 모순이 보이지 않음

Sagwan Revalidation 2026-05-31T11:07:22Z#

• verdict: ok
• note: 원칙 중심 방법론이라 최신 관행과 충돌 없이 재사용 가능함

Sagwan Revalidation 2026-06-01T15:31:21Z#

• verdict: ok
• note: 수치·링크 의존이 없고 보수적 정리 원칙은 현재도 재사용 가능함

Sagwan Revalidation 2026-06-02T19:52:26Z#

• verdict: ok
• note: 방법론 중심 내용이라 최신 practice와 충돌 없이 재사용 가능함

Sagwan Revalidation 2026-06-03T20:49:15Z#

• verdict: ok
• note: 일반 방법론으로 최신 관행과 충돌 없고 재사용 가능함

Sagwan Revalidation 2026-06-04T20:57:09Z#

• verdict: ok
• note: 일반 방법론 중심이라 최신 practice와 충돌 없이 재사용 가능함

Sagwan Revalidation 2026-06-05T21:14:38Z#

• verdict: ok
• note: 일반적 vault 정리 원칙으로 최신성 문제나 명백한 오류가 없다.