Skip to content

docs: add repository Pages landing source #905

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
seonghobae merged 1 commit into from
Sep 1, 2026
Merged

docs: add repository Pages landing source #905

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 30 additions & 0 deletions docs/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
# LineageWeave

@devin-ai-integration devin-ai-integration Bot Sep 1, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Pages ignores the new landing source

On Pages deployments, index.md never enters the generated artifact because the workflow publishes only _site. The public landing page remains unchanged.

Prompt for agents 
Integrate docs/index.md into the existing deterministic GitHub Pages publication path. The workflow in .github/workflows/ontology-pages.yml currently triggers only for ontology publication inputs and uploads the `_site` tree produced by scripts/publish_ontology_site.py. The renderer in scripts/build_ontology_site.py creates its own root index.html and never reads docs/index.md. Update the governed renderer/publication contract and workflow paths so this source deterministically produces the deployed root landing page, while preserving the ADR 0159 fail-closed publication and deterministic-output requirements. Add contract tests proving changes to docs/index.md affect the generated root page and trigger Pages validation/publication.
Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.


LineageWeave reconstructs evidence-bound lineage, project journeys, and relationship context from scattered enterprise records so people can inspect how events, claims, posts, and decisions relate over time.

## Start here

Use LineageWeave when source systems contain related records without reliable explicit cross-record links and you need a browsable, evidence-preserving view of branching histories rather than a flat search result.

The product combines deterministic lineage assembly with bounded retrieval/fusion and optional adjudication through shared ContextualWisdomLab components. It keeps source authority, authentication, tenant scope, measurement, and model-provider routing in their owning products and contracts.

## Product surfaces

- lineage reconstruction and project journeys;
- operations/dashboard views over governed records;
- evidence-aware Global Ask and related context navigation;
- authenticated API and web client over durable PostgreSQL state;
- integration with ThreadWeave, RankWeave, TEPP, contextual-orchestrator, and shared context contracts through explicit boundaries.

## Documentation

- [Repository overview and local stack](../README.md)
- [Architecture](../ARCHITECTURE.md)
- [Product requirements](product-requirements.md)
- [Product/technical gap baseline](product-technical-gap-baseline.md)
- [Architecture decisions](adr/)
- [Research notes](lineage-bi-research-notes.md)

## Status and evidence

The repository has progressed beyond its original synthetic reconstruction demo into a broader authenticated product stack, while synthetic fixtures remain important for safe examples and tests. Treat protected-main behavior, current release evidence, and repository verification as authoritative; do not infer production readiness from a documentation page or an open pull request alone.
Loading