diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index e6f2e50..01b24ce 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -43,6 +43,16 @@ Each independently versioned module contains:
 7. Mark rapidly changing information with a verification date.
 8. Keep entries concise enough to scan but detailed enough to teach.
 
+## Contribution paths and editorial guidance
+
+Use the narrowest contribution path that fits the change. Improvements to existing knowledge are as valuable as new modules when they strengthen accuracy, depth, evidence, or discovery.
+
+- [Contribution paths](docs/CONTRIBUTION_PATHS.md) — corrections, source upgrades, examples, architecture, relationships, deepening, and discovery work.
+- [Source quality guidance](docs/SOURCE_QUALITY.md) — claim-level evidence hierarchy, freshness, security-sensitive sourcing, and comparison discipline.
+- [Kind-specific editorial checklists](docs/KIND_EDITORIAL_CHECKLISTS.md) — review prompts for tools, languages, frameworks, infrastructure, databases, security, protocols, AI/ML, concepts, and open-source ecosystems.
+- [Relationship suggestions and validation](docs/RELATIONSHIP_SUGGESTIONS.md) — precise graph-edge selection, directionality, evidence, and anti-inflation rules.
+- [Generated index/search preview](docs/GENERATED_PREVIEW.md) — deterministic local preview and representative search checks before review.
+
 ## Local checks
 
 Before opening a pull request that changes core tooling or catalogs, run:
diff --git a/docs/CONTRIBUTION_PATHS.md b/docs/CONTRIBUTION_PATHS.md
new file mode 100644
index 0000000..c5c2382
--- /dev/null
+++ b/docs/CONTRIBUTION_PATHS.md
@@ -0,0 +1,121 @@
+# Contribution paths
+
+OpenDevIndex contributions do not need to add a new technology module. Small, well-scoped improvements to existing knowledge are often more valuable because they strengthen trust, depth, discovery, or navigation without expanding the catalog unnecessarily.
+
+Use the narrowest contribution path that matches the change you can support with evidence.
+
+## Correct a factual weakness
+
+Use this path when an existing statement is inaccurate, misleading, obsolete, or too absolute.
+
+Expected change:
+
+- identify the exact claim that needs correction;
+- replace it with the narrowest accurate wording;
+- add or update an authoritative source that supports the corrected claim;
+- update verification metadata when the corrected fact is time-sensitive;
+- avoid unrelated editorial rewrites in the same pull request.
+
+A correction should improve factual reliability without silently changing unrelated architecture, taxonomy, maturity, or graph data.
+
+## Improve sources or provenance
+
+Use this path when the module is directionally correct but its evidence is weak, stale, secondary when a primary source exists, or broader than the claim it supports.
+
+Expected change:
+
+- prefer official specifications, documentation, release notes, design documents, or project-maintained references;
+- match each replacement source to the claim it actually proves;
+- preserve useful secondary sources when they add independent context rather than merely duplicating a primary source;
+- do not increase confidence or maturity only because more URLs were added.
+
+See `docs/SOURCE_QUALITY.md` for the detailed source-quality workflow.
+
+## Add a practical example or workflow
+
+Use this path when a module explains what a technology is but does not yet help a reader perform a representative task.
+
+Good additions include:
+
+- a minimal command sequence;
+- a small API or configuration example;
+- a troubleshooting or recovery workflow;
+- a concrete lifecycle walkthrough;
+- an example that exposes an important boundary or failure mode.
+
+Examples should teach the concept without becoming a substitute for upstream documentation. Prefer small, stable examples over large copied configurations.
+
+## Add or clarify architecture
+
+Use this path when the module names components but does not explain ownership, data flow, control flow, process boundaries, protocol boundaries, or where state actually lives.
+
+Expected change:
+
+- identify the reader question the architecture explanation answers;
+- distinguish components that own state from components that only observe or transform it;
+- separate control-plane and data-plane behavior where relevant;
+- call out important external dependencies and failure boundaries;
+- support non-obvious architecture claims with authoritative evidence.
+
+Avoid decorative diagrams or terminology lists that do not improve the mental model.
+
+## Add a graph relationship
+
+Use this path when an existing module is missing a meaningful connection that helps readers navigate architecture, dependencies, compatibility, history, or alternatives.
+
+Before editing graph data:
+
+1. start from a concrete reader or architecture question;
+2. choose the narrowest supported relationship type;
+3. verify directionality;
+4. ensure the target module actually exists;
+5. add evidence for non-obvious claims;
+6. run the relationship validator and generated-index checks.
+
+Do not add links only to increase graph density. See `docs/RELATIONSHIP_SUGGESTIONS.md` for the complete workflow.
+
+## Deepen an existing module
+
+Use this path when an overview is correct but not yet useful enough as a guide or deep dive.
+
+Prefer depth that adds one or more of the following:
+
+- a stronger mental model;
+- architecture or internals;
+- realistic workflows;
+- recovery and failure diagnosis;
+- performance or reliability trade-offs;
+- security or privacy boundaries;
+- meaningful alternatives;
+- a beginner-to-advanced learning path.
+
+Do not raise maturity mechanically. Use `docs/MODULE_DEEPENING_CHECKLIST.md` and the kind-specific editorial checklist before claiming a maturity change.
+
+## Improve discovery without changing knowledge claims
+
+Use this path for search metadata, taxonomy fit, comparison discovery, generated navigation, or other findability improvements that do not alter substantive technical claims.
+
+Expected change:
+
+- explain which discovery problem is being solved;
+- keep ranking or taxonomy changes narrow and deterministic;
+- preview generated catalog/search artifacts;
+- test representative queries or navigation paths;
+- verify that existing stable module addresses do not regress.
+
+See `docs/GENERATED_PREVIEW.md` before opening the pull request.
+
+## Keep pull requests narrow
+
+A contribution is easier to review when it has one primary purpose. If a correction uncovers a separate architecture rewrite or new comparison opportunity, prefer a follow-up pull request unless the changes are inseparable.
+
+For every path:
+
+- preserve stable module identifiers;
+- do not copy upstream manuals wholesale;
+- do not treat generated text as an authoritative source;
+- do not make unrelated schema, maturity, or graph changes;
+- run the relevant local validators before requesting review;
+- describe what was intentionally left unchanged.
+
+The goal is not to maximize changed lines. The goal is to leave one useful part of the map more accurate, teachable, connected, or discoverable than it was before.
diff --git a/docs/GENERATED_PREVIEW.md b/docs/GENERATED_PREVIEW.md
new file mode 100644
index 0000000..04cb0aa
--- /dev/null
+++ b/docs/GENERATED_PREVIEW.md
@@ -0,0 +1,65 @@
+# Preview generated index and search changes
+
+OpenDevIndex keeps generated discovery artifacts deterministic so contributors can review the public effect of a catalog or metadata change before opening a pull request.
+
+## Build the preview
+
+From the repository root:
+
+```bash
+python -m pip install -r requirements-ci.txt
+python scripts/validate_catalog.py catalog/v0.1.yaml
+python scripts/build_index.py --catalog-dir catalog --output-dir dist/index
+```
+
+The generated preview lives under `dist/index/`:
+
+- `catalog.json` — API-friendly public catalog records and aggregate counts.
+- `search.json` — searchable records and normalized search text.
+- `catalog.md` — human-readable browse/index rendering.
+
+If your change also affects comparison metadata, first generate the comparison index using the repository's comparison tooling and pass that file to `build_index.py` with `--comparison-index` so backlinks are included in the preview.
+
+## Review the diff
+
+Keep generated review separate from hand-authored source changes. A useful local sequence is:
+
+```bash
+git status --short
+git diff -- catalog quality comparisons docs
+python scripts/build_index.py --catalog-dir catalog --output-dir dist/index
+git diff --no-index /dev/null dist/index/catalog.md || true
+```
+
+For JSON artifacts, prefer structural inspection over reading minified fragments. Useful checks include:
+
+```bash
+python -m json.tool dist/index/catalog.json >/tmp/opendevindex-catalog.pretty.json
+python -m json.tool dist/index/search.json >/tmp/opendevindex-search.pretty.json
+```
+
+Then inspect the records affected by your module, kind, domain, coverage area, maturity level, or comparison.
+
+## Search the preview
+
+Run representative queries against the generated search index:
+
+```bash
+python scripts/search_index.py "your query" --index dist/index/search.json
+```
+
+Use at least one query that should find the changed module and, when relevant, one nearby query that should not become noisier or misleading because of the change.
+
+## What to verify
+
+Before opening a pull request, confirm that:
+
+- module counts and facet counts changed only when expected;
+- the changed module appears under the intended kind/domain/coverage facets;
+- maturity metadata is reflected correctly;
+- comparison backlinks appear only for validated curated comparisons;
+- search text gains only relevant terms and does not introduce accidental keyword spam;
+- generated Markdown links resolve to the intended stable module address;
+- rebuilding the same source state produces the same generated artifacts.
+
+Generated output is a review aid, not a replacement for source review. The catalog, schemas, maturity metadata, comparison definitions, and module sources remain the authoritative inputs.
diff --git a/docs/KIND_EDITORIAL_CHECKLISTS.md b/docs/KIND_EDITORIAL_CHECKLISTS.md
new file mode 100644
index 0000000..4d2fafb
--- /dev/null
+++ b/docs/KIND_EDITORIAL_CHECKLISTS.md
@@ -0,0 +1,104 @@
+# Kind-specific editorial checklists
+
+Use these prompts after the general module standard and deepening checklist. They are review aids, not rigid section templates: omit a prompt when it is genuinely irrelevant and explain unusual scope choices in the pull request.
+
+## Tools
+
+- Explain the task boundary: what the tool owns and what it deliberately delegates.
+- Show the normal workflow from input/configuration through observable output.
+- Document important local, remote, cache, state, and credential boundaries.
+- Include failure recovery for interrupted or partially successful operations.
+- Distinguish convenience defaults from production-safe practice.
+- Cover plugin/extension or supply-chain risk when third-party code is executable.
+- Compare at least one credible alternative on workflow and operational trade-offs.
+
+## Languages and runtimes
+
+- Separate language semantics from compiler/interpreter/runtime implementation details.
+- Explain execution and memory models at the depth appropriate to module maturity.
+- Identify concurrency, error, module/package, and interoperability boundaries.
+- Note compatibility/versioning commitments and common migration hazards.
+- Include representative build/run/debug/test workflows rather than syntax catalogs.
+- Cover package/dependency supply-chain controls where applicable.
+
+## Frameworks and libraries
+
+- State the abstraction the framework provides and what remains application-owned.
+- Explain lifecycle, dependency injection/state/data-flow, extension, and configuration models where relevant.
+- Distinguish framework behavior from host language/runtime/platform behavior.
+- Document performance costs, deployment constraints, upgrade boundaries, and escape hatches.
+- Include testing, observability, and failure-debugging workflows.
+- Compare alternatives using architectural fit rather than popularity.
+
+## Cloud, infrastructure, and distributed systems
+
+- Draw clear control-plane, data-plane, and trust boundaries.
+- Explain reconciliation, scheduling, replication, consistency, or orchestration semantics as applicable.
+- Identify durable state, identity, tenancy, region/failure-domain, and network assumptions.
+- Cover rollout, rollback, backup/restore, disaster recovery, and degraded-mode behavior.
+- Include capacity, latency, cost, security, and availability trade-offs.
+- Make managed-service versus self-hosted responsibility boundaries explicit.
+
+## Databases and storage
+
+- Explain logical data model and physical/storage-engine boundaries separately.
+- Cover transactions, isolation/concurrency, locking or conflict behavior, and durability.
+- Describe indexing/query-planning or access-path behavior where relevant.
+- Include backup, restore, replication, failover, corruption/integrity, and migration workflows.
+- State consistency and filesystem/network assumptions.
+- Connect tuning advice to measurable bottlenecks instead of generic settings lists.
+
+## Security, cryptography, and privacy
+
+- State threat model, protected assets, attacker capabilities, and out-of-scope assumptions.
+- Separate preventive, detective, recovery, and operational controls.
+- Prefer standards, specifications, vendor advisories, and primary security documentation for consequential claims.
+- Avoid presenting configuration snippets as universally safe defaults.
+- Cover key/secret lifecycle, trust anchors, identity, logging, update, and compromise-recovery boundaries when applicable.
+- Time-scope rapidly changing vulnerability or advisory claims and record verification dates.
+
+## Protocols and standards
+
+- Identify authoritative specification versions and status.
+- Explain actors, state machines, message/data model, negotiation, and failure semantics.
+- Separate normative requirements from common implementation choices.
+- Cover compatibility, extension/versioning, security, privacy, and deployment assumptions.
+- Include at least one end-to-end exchange or workflow when it improves understanding.
+- Note important interoperability tests or implementation pitfalls.
+
+## AI and machine learning
+
+- Distinguish model architecture, training/inference system, product wrapper, and deployment runtime.
+- State data, compute, evaluation, latency, cost, privacy, and safety assumptions.
+- Explain inputs/outputs, context/state behavior, failure modes, and observability.
+- Avoid benchmark claims without dataset, metric, version, and evaluation context.
+- Cover reproducibility and model/dependency provenance where practical.
+- Compare alternatives by workload and constraints rather than headline capability.
+
+## Concepts
+
+- Define the concept independently of any single implementation or vendor.
+- Explain the mental model, invariants, and boundaries before examples.
+- Use multiple implementations when that prevents accidental product-specific framing.
+- Include common misconceptions, failure modes, and trade-offs.
+- Link naturally to prerequisite and next-step modules without manufacturing graph edges.
+
+## Open-source projects and ecosystems
+
+- Separate project governance, technical architecture, distribution, and hosted/commercial offerings.
+- Identify upstream release/support policy and dependency/plugin ecosystem boundaries.
+- Explain contribution, extension, upgrade, and compatibility models where relevant.
+- Cover supply-chain, maintainer, signing/release, and provenance considerations for critical projects.
+- Avoid equating repository activity or popularity with technical quality.
+
+## Final kind-aware review
+
+Before requesting review, verify that:
+
+1. the module's kind-specific architecture and ownership boundaries are clear;
+2. practical workflows are present where the subject is operational;
+3. consequential security/reliability claims are source-backed and appropriately scoped;
+4. trade-offs and alternatives are technically fair;
+5. version-sensitive statements identify their scope or verification date;
+6. links and relationships help readers navigate rather than inflate graph density;
+7. the module still satisfies the general `MODULE_STANDARD.md` and repository validation rules.
diff --git a/docs/RELATIONSHIP_SUGGESTIONS.md b/docs/RELATIONSHIP_SUGGESTIONS.md
new file mode 100644
index 0000000..14983f9
--- /dev/null
+++ b/docs/RELATIONSHIP_SUGGESTIONS.md
@@ -0,0 +1,120 @@
+# Relationship Suggestions and Validation
+
+OpenDevIndex relationships are editorial claims, not graph-decoration metadata. A useful edge should help a reader understand architecture, dependency, compatibility, history, alternatives, or a sensible next topic.
+
+This guide provides a lightweight workflow for proposing relationship changes without creating artificial graph density.
+
+## Start from a reader question
+
+Before adding an edge, state the question it answers. Good examples include:
+
+- What does this technology depend on at runtime or build time?
+- Which protocol or standard does it implement?
+- Which component is this part of?
+- Which technology is a realistic alternative under similar requirements?
+- Which predecessor or successor explains an important historical transition?
+- What adjacent module should a reader learn next to understand this subject?
+
+If the edge does not answer a useful question, do not add it.
+
+## Choose the narrowest relationship type
+
+Prefer the most specific relationship that accurately describes the connection:
+
+- `depends-on` — the source requires the target as a dependency or operational prerequisite.
+- `uses` — the source deliberately uses the target, but the target is not necessarily a hard dependency.
+- `implements` — the source implements a protocol, standard, interface, or specification represented by the target.
+- `integrates-with` — the technologies interoperate through a supported integration without implying dependency.
+- `part-of` — the source is a component or sub-system of the target.
+- `alternative-to` — the modules address sufficiently similar needs that a real engineering choice may exist between them.
+- `based-on` — the source is materially derived from, built on, or architecturally founded on the target.
+- `predecessor-of` / `successor-of` — use only for a meaningful historical or product-line succession relationship.
+- `related-to` — reserve for useful adjacency that cannot be expressed more precisely.
+
+Do not use `related-to` as a fallback merely because a precise relationship requires more research.
+
+## Evidence expectations
+
+Relationship edges should be supportable by the same source discipline as module content.
+
+Prefer:
+
+1. official architecture or product documentation;
+2. standards/specifications for implementation relationships;
+3. canonical repositories or release/migration documentation for lineage;
+4. authoritative compatibility or integration documentation;
+5. high-quality secondary sources only when primary material does not establish the claim clearly.
+
+For `alternative-to`, avoid relying on marketing comparison pages from either vendor alone. The relationship should reflect overlapping engineering use cases, not popularity or branding.
+
+## Direction matters
+
+Read the proposed edge as a sentence before committing it.
+
+Examples:
+
+- `tool/docker` **uses** `tool/containerd`
+- `tool/containerd` **implements** `standard/oci-runtime-spec`
+- `cloud/helm` **integrates-with** `cloud/kubernetes`
+
+Do not assume every relationship is symmetric. Add a reverse edge only when the reverse statement is independently meaningful and allowed by the model.
+
+## Avoid graph inflation
+
+Do not add edges solely because two technologies:
+
+- appear in the same stack;
+- are often mentioned in the same article;
+- share a broad domain;
+- are maintained by the same organization;
+- can technically be used together;
+- would make a module appear better connected.
+
+A small number of specific, teachable edges is better than a dense graph of weak associations.
+
+## Suggested review workflow
+
+For each proposed edge:
+
+1. confirm both module references exist in the catalog;
+2. write the relationship as a plain-language sentence;
+3. choose the narrowest accurate type;
+4. confirm the direction is correct;
+5. identify evidence that supports the exact claim;
+6. check whether an existing edge already expresses the same relationship;
+7. consider whether the edge improves discovery, comparison, architecture understanding, or learning navigation;
+8. reject the edge if its main benefit is graph-count growth.
+
+## Validate locally
+
+Run the repository relationship validator after editing catalog relationship metadata:
+
+```bash
+python scripts/validate_relationships.py catalog/*.yaml
+```
+
+For catalog changes, also run the normal repository checks:
+
+```bash
+python -m unittest discover -s tests -v
+python scripts/validate_catalog.py catalog/v0.1.yaml
+python scripts/build_index.py --catalog-dir catalog --output-dir dist/index
+```
+
+Validation confirms structural correctness, known targets, and supported relationship types. It does not prove that the relationship is factually or editorially justified.
+
+## Review checklist
+
+Before opening a pull request, verify that:
+
+- the target module exists;
+- the edge type is supported and as specific as practical;
+- the direction reads correctly;
+- the relationship is useful to a reader;
+- authoritative evidence exists for consequential claims;
+- the edge does not duplicate an existing connection;
+- the edge was not added merely to increase graph density;
+- `scripts/validate_relationships.py` passes;
+- generated discovery changes are reviewed when the catalog change affects navigation.
+
+Relationship suggestions should make the map easier to reason about, not merely larger.
diff --git a/docs/SOURCE_QUALITY.md b/docs/SOURCE_QUALITY.md
new file mode 100644
index 0000000..8a8597b
--- /dev/null
+++ b/docs/SOURCE_QUALITY.md
@@ -0,0 +1,106 @@
+# Source quality guidance
+
+OpenDevIndex prefers evidence that is close to the technology, claim, or event being documented. Source quality is not a popularity score: a useful source is one that is authoritative for the specific claim, current enough for the claim's volatility, and precise enough to audit.
+
+## Evidence hierarchy
+
+Use the strongest practical source for each claim.
+
+### Tier 1 — primary and canonical
+
+Prefer these whenever they directly support the claim:
+
+- official project documentation and release notes;
+- standards bodies and published specifications;
+- canonical source repositories and maintained design documents;
+- original security advisories and vendor bulletins;
+- original research papers, protocol drafts, and architecture documents;
+- official licensing, governance, compatibility, and support-policy pages.
+
+Tier 1 is the default for architecture, protocol behavior, lifecycle guarantees, compatibility promises, security boundaries, licensing, and version-specific claims.
+
+### Tier 2 — high-quality secondary
+
+Use reputable secondary material when primary sources are incomplete, inaccessible, or insufficiently explanatory. Examples include established technical publications, conference material from identified practitioners, and well-maintained independent documentation that links back to primary evidence.
+
+Secondary sources should add context, synthesis, operational experience, or comparison—not silently replace a primary source that already exists.
+
+### Tier 3 — discovery only
+
+Search results, forum posts, social posts, generated summaries, marketing pages, aggregator sites, and unsourced tutorials may help discover terminology or locate better evidence. They should not be the sole support for consequential factual claims.
+
+## Match the source to the claim
+
+A source can be authoritative for one claim and weak for another. For example:
+
+- a protocol specification is strong evidence for wire semantics but may not describe one implementation's operational behavior;
+- a project's own benchmark is evidence that the project published those numbers, not proof of universal performance superiority;
+- a security advisory is strong evidence for the affected versions and remediation it names, but not for unrelated architectural claims;
+- a repository README can establish project intent while implementation details may require code, design docs, or maintained technical documentation.
+
+Avoid citing a generic homepage when a specific specification, release note, or design document supports the exact statement.
+
+## Freshness and version scope
+
+Before using a source for a fast-moving claim, verify that its version and date match the module text.
+
+Review especially carefully when documenting:
+
+- supported versions or platforms;
+- APIs, flags, defaults, and configuration behavior;
+- licensing or governance changes;
+- security posture and advisories;
+- cloud-service features;
+- compatibility guarantees;
+- performance characteristics;
+- rapidly evolving AI, browser, mobile, and infrastructure tooling.
+
+If the source is historically correct but no longer current, scope the prose explicitly to the relevant version or period rather than presenting it as timeless behavior.
+
+## Claim discipline
+
+For each non-trivial technical claim, ask:
+
+1. What exactly is being asserted?
+2. Which source directly supports that assertion?
+3. Does the source describe the same version, mode, platform, and deployment boundary?
+4. Is the wording more confident than the evidence permits?
+5. Would a reader be able to audit the claim without guessing which paragraph or document was intended?
+
+When evidence is ambiguous, narrow the claim or state the uncertainty. Do not combine several weak sources into a stronger-sounding conclusion than any of them support.
+
+## Comparisons and trade-offs
+
+Comparison content needs evidence on both sides. Avoid using one project's documentation to characterize a competing technology unless the statement is independently supported.
+
+Prefer architecture and requirement language over universal rankings:
+
+- describe the deployment boundary, failure model, consistency model, authorization model, lifecycle, or operational trade-off;
+- distinguish measured facts from contextual judgment;
+- avoid context-free "faster", "better", "more secure", or "enterprise-grade" claims;
+- state when two technologies solve overlapping but non-equivalent problems.
+
+## Security-sensitive material
+
+For vulnerabilities, cryptography, authentication, sandboxing, privilege boundaries, supply-chain controls, and destructive recovery procedures:
+
+- prefer original advisories, specifications, canonical security documentation, or primary research;
+- record affected versions and prerequisites precisely;
+- do not generalize a single vulnerability into a claim that an entire technology is insecure;
+- separate mitigation guidance from factual vulnerability description;
+- avoid reproducing exploit detail that is unnecessary to explain the engineering boundary.
+
+## Source-list review checklist
+
+Before considering a module or substantial revision ready for editorial review, check that:
+
+- important architecture and behavior claims have direct authoritative support;
+- version-sensitive claims use current or explicitly version-scoped evidence;
+- source links are specific enough to audit;
+- secondary sources add value instead of replacing available primary documentation;
+- marketing copy, generated text, snippets, and community discussion are not acting as sole authority;
+- alternatives and comparisons are sourced fairly;
+- licensing, security, compatibility, and support claims use first-party or canonical evidence where available;
+- the module's `verified_at` date reflects an actual review of the cited evidence.
+
+Automated source-health checks only establish that a URL can be reached. They do not establish that the source proves the claim. Editorial review remains responsible for that judgment.