[Cross-repo] Consume LineageWeave for email lineage and project intelligence without duplicating authority

[seonghobae]

Buyer outcome

Naruon should be able to use LineageWeave as an optional evidence-analysis capability so that selected authorized email/thread evidence can be reconstructed into explainable lineage and project-history candidates, while Naruon remains the system of record for customer-owned mail/calendar/file state and its own project/task/commitment records.

This issue is the Naruon consumer-side counterpart to ContextualWisdomLab/LineageWeave#338.

Product scenario

Examples this integration should eventually support:

selected authorized email/thread evidence
→ LineageWeave reconstruction
→ explainable predecessor/successor / related-history candidates
→ project-history candidate links
→ Naruon buyer surface shows evidence + confidence + truth status
→ user or deterministic Naruon policy may adopt/correct a relation

and:

Naruon email / attachment / task / commitment evidence
→ LineageWeave project lineage
→ Naruon project workspace / timeline / Ask context

This must not become:

LineageWeave copied into Naruon
or
LineageWeave given Naruon DB/provider credentials
or
LineageWeave inference silently promoted to authoritative provider/project truth

Existing Naruon landing points

Coordinate with, do not duplicate:

• [Product Gap] Implement evidence-based email, media, and document resolution pipeline #1350 — canonical email identity, dedupe, thread graph, evidence-based resolution;
• Phase 0 — MVP: make the dense KG real (behind a stable extractor seam) #975/Phase 2 — Dense-KG inference (the discipline layer) #977 — project graph and dense-KG inference;
• Phase 1 — Platform / Plugin SDK #976 — signed/versioned plugin SDK and extension-point lifecycle;
• Phase 3 — Scheduling & conflict avoidance (killer scenario) #978 — commitment/calendar semantics;
• naruon: production connector lifecycle, protocol coverage, and OpenTelemetry operations #998 — production connector lifecycle;
• [Product Completion] Establish Naruon GA scope, release train, and buyer-visible acceptance evidence #1428 — GA boundary and cross-repository verticals.

Authority boundary

Naruon remains authoritative for

• provider source access and credentials;
• canonical email/message/instance/thread identities;
• tenant/workspace authorization and source visibility;
• tasks, commitments, and Naruon-owned project records;
• mail/calendar/file provider mutations and reconciliation;
• user confirmation and correction workflows.

LineageWeave remains authoritative for

• its released lineage reconstruction algorithm and run contract;
• channel-level evidence and reconstruction provenance;
• project-history inference produced from caller-supplied evidence;
• algorithm/profile/model versioning for its own analysis artifact.

LineageWeave output is inferred or proposed unless a particular field is simply echoing caller-supplied observed evidence. Naruon must never label a LineageWeave-inferred relation as provider truth solely because it came from a trusted CWL service.

Required consumer design

1. Explicit admission policy

Not every email is sent to LineageWeave. Add a versioned admission decision such as:

lineage_analysis_policy
lineage_analysis_candidate
lineage_analysis_request
lineage_analysis_receipt

Candidate reasons may include:

• explicit user request;
• project/commitment evidence already present;
• thread ambiguity requiring lineage analysis;
• configured workspace policy;
• project-history refresh.

Default must be fail-closed / no external analysis when authorization, purpose, data classification, or LineageWeave capability is unknown.

2. Bounded evidence projection

Project Naruon facts into the released LineageWeave contract without direct SQL or shared ORM models. Prefer opaque references and data minimization.

Possible evidence channels:

• Message-ID / References / In-Reply-To evidence;
• provider thread reference and duplicate provenance;
• sent/received/available timestamps;
• source-authorized subject/body excerpt or caller-computed text feature, according to policy;
• participant/organization evidence when explicitly authorized;
• attachment/content evidence references;
• Naruon project/task/commitment hints as observed/authoritative_in_caller, not LineageWeave-owned truth.

Provider credentials, browser sessions, raw access tokens, unrelated mailbox contents, and cross-tenant facts never leave Naruon.

3. Async and durable execution

Potentially model-backed lineage work must not block email request paths. Use a bounded durable job/analysis-run contract with:

• idempotency identity;
• exact source/evidence revisions;
• knowledge cutoff / available-time binding;
• timeout/cancellation;
• retry classification;
• explicit unavailable/degraded state;
• result artifact digest and LineageWeave version.

4. Result projection

Store a Naruon-owned projection/receipt, not a shadow copy of the full LineageWeave database.

Suggested normalized objects:

external_analysis_run
external_analysis_artifact
lineage_relation_candidate
lineage_candidate_evidence
lineage_candidate_decision

Use descriptive two-or-more-word snake_case, 3NF, and hot-partition-safe indexing/partitioning if persistence is added.

A candidate decision distinguishes at least:

proposed
accepted
rejected
superseded

Acceptance must record actor/policy, time, evidence revision, and the Naruon object actually updated. Provider mutation remains a separate confirmation path.

5. Buyer surface

Do not add a second product UI. Integrate results into existing email/thread/project surfaces:

• "Related history" / "Email lineage" evidence disclosure;
• project timeline/history candidate links;
• channel evidence and algorithm version;
• clear inferred wording and confidence/limitations;
• one-step accept/correct/reject where Naruon owns the resulting relation;
• no hover-only exact values;
• keyboard/screen-reader and print/export parity.

Plugin vs service decision

When LineageWeave publishes the reusable boundary from #338:

• prefer a released package only if it is truly store-agnostic, stateless, and does not pull LineageWeave persistence into Naruon;
• otherwise consume it as a separately released service or a Naruon Phase 1 — Platform / Plugin SDK #976 plugin using a reviewed extension point;
• no mutable git branch/submodule is acceptable as the production contract;
• package/service/plugin compatibility must be contract-tested on both repositories.

TDD acceptance

1. An authorized selected email can be analyzed without exposing Naruon credentials or unrelated mailbox data.
2. An unauthorized/private email never appears in a LineageWeave request, candidate, cache, log, metric, or fixture.
3. RFC reply/thread facts remain distinct from semantic lineage candidates.
4. Duplicate delivery/retry executes one logical analysis and produces one Naruon projection.
5. Later-available evidence cannot affect a historical knowledge_cutoff run.
6. LineageWeave outage/degraded state leaves normal Naruon mail/project operation available.
7. A returned inferred candidate cannot directly mutate provider mail/calendar state.
8. Accept/reject/correct decisions are auditable and preserve the original LineageWeave artifact reference.
9. Consumer contract tests run against an immutable released LineageWeave artifact and fail on incompatible schema/version.
10. Owned production statement/branch coverage and public docstrings remain 100%, plus exact-head security/review/release gates.

Delivery ordering

1. ContextualWisdomLab/LineageWeave#338 releases the provider contract/artifact.
2. Naruon adds consumer/admission contract behind a disabled-by-default capability.
3. Wire email/thread evidence from [Product Gap] Implement evidence-based email, media, and document resolution pipeline #1350 only after canonical identity/provenance is stable.
4. Add project-workspace projection after the project-history contract is proven.
5. Evaluate a Naruon Phase 1 — Platform / Plugin SDK #976 plugin packaging path only after plugin lifecycle is production-safe.

This is a future integration track and must not block current core mail/calendar/file operation.

[seonghobae]

The LineageWeave provider-side contract is now implemented in Draft PR ContextualWisdomLab/LineageWeave#339:

ContextualWisdomLab/LineageWeave#339

The Draft publishes a store-agnostic 1.0.0 contract with opaque caller references, available-time knowledge cutoffs, observed RFC/provider/manual parent relations, inferred continuation edges, exact channel evidence, proposed project groupings, deterministic digests, and pre-provider pair-budget enforcement. It performs no Naruon DB, mailbox, credential, or provider access.

Naruon consumption remains deliberately disabled. Continue in this order:

1. LineageWeave docs: organize Naruon UI/UX guidelines and mockups #339 passes exact-head hosted gates and is integrated normally.
2. LineageWeave publishes an immutable versioned artifact with digest/SBOM/provenance.
3. Naruon adds the admission/job/projection boundary behind a disabled-by-default capability.
4. Canonical email/thread evidence from [Product Gap] Implement evidence-based email, media, and document resolution pipeline #1350 is projected only after its identity/provenance contract is stable.
5. Project candidate decisions stay proposed/accepted/rejected/superseded inside Naruon; no LineageWeave result directly mutates provider or project authority.

Consumer contract tests must pin the released artifact and reject incompatible schema/version. Do not import the Draft branch, copy the source, or add direct SQL/shared ORM coupling.

[seonghobae]

Current contract routing correction: the bounded LineageWeave provider boundary is Draft PR ContextualWisdomLab/LineageWeave#343. PR #339 remains the separate TEPP project-history recovery lane, and the earlier #340 reference is stale.

Current exact provider state:

• base LineageWeave main@ef6f5a5ffcb467bd935dc1e53acc0029669b0bd7;
• head e51ec822fb939ac8aee1aa70a423ce548c8711fa;
• GitHub reports mergeable, but the PR remains Draft;
• Tests, Security Scan, and SAST Semgrep are queued;
• no independent review exists yet.

Naruon consumption stays disabled. PR #343 must pass exact-head hosted gates and independent review, merge normally, and publish an immutable provider artifact with digest/SBOM/provenance. Only then should Naruon add the admission/job/projection boundary with consumer contract tests. Do not import the Draft branch or share SQL/ORM state.

[seonghobae]

Provider update (2026-08-25): LineageWeave PR #343 is merged at 125a8069a1554874d8067a15047e19d780ea6b7b into feat/analysis-run-name-evidence-lineage. The provider contract repair is present on the current provider base, but gh release list currently reports no immutable release artifact.

Naruon consumption therefore remains disabled: no branch import, source copy, direct SQL/ORM coupling, or provider credential access. Enable the consumer admission/job/projection boundary only after a tagged immutable artifact with digest, SBOM, and provenance exists; pin that artifact in consumer contract tests.

[seonghobae]

2026-09-01 live consumer handoff refresh from the LineageWeave owner path:

• ContextualWisdomLab/LineageWeave protected/default main is currently cb187cadee5fb6c46d8a944815ccc154a1e028d1.
• The store-agnostic external-lineage contract source is present on that protected tree (lineageweave/external_lineage.py plus docs/contracts/external-lineage-analysis-v1.limitations.md).
• GitHub Releases currently returns no releases for LineageWeave, and the protected-main workflow inventory currently exposes Tests/Security/SAST/PROV-O/Ontology Pages but no immutable package/service release + SBOM/provenance publication lane for this contract.

Therefore the Naruon consumer activation gate remains closed. Do not pin a mutable LineageWeave branch or import its ORM/application database. Acceptance remains: one immutable released package/service artifact whose source identity, contract version/digest, SBOM/provenance and compatibility evidence are bound together; then Naruon can add the disabled-by-default durable consumer against that release. Existing mail/project operation must remain independent while this is unavailable.

This is evidence/acceptance handoff only; no Naruon source mutation is requested from the LineageWeave writer.