[Cross-repo] Publish an evidence-bounded email/project lineage contract for Naruon consumption

[seonghobae]

Buyer / ecosystem outcome

LineageWeave should remain independently useful while also being consumable by Naruon for email lineage, project-history reconstruction, and buyer-facing evidence navigation. The integration must not be implemented by copying LineageWeave internals into Naruon or by giving Naruon direct SQL access to LineageWeave tables.

This issue establishes the provider-side reusable boundary owned by LineageWeave. The corresponding Naruon consumer issue must consume only a released/versioned contract or service/plugin artifact.

Why this is needed

LineageWeave already owns evidence-bounded reconstruction concepts that Naruon is beginning to need:

• post/email-like record lineage reconstructed from temporal, secondary-key, text, and optional contextual-orchestrator adjudication channels;
• persisted per-channel evidence and explicit inferred-vs-authoritative truth boundaries;
• project-history and responsibility/evidence projections;
• knowledge-cutoff and future-information-leakage controls;
• ontology / PROV-O / OWL-Time aligned evidence projection.

Naruon already owns customer mail/calendar/file source access, canonical email identity, source dedupe, thread graph, provider actions, projects/tasks, and buyer workspaces. It should be able to ask LineageWeave for lineage intelligence without making LineageWeave a mailbox, provider connector, or Naruon-owned submodule implementation detail.

Authority boundary

LineageWeave owns

• lineage reconstruction algorithm and run semantics;
• lineage-specific candidate generation and scoring;
• channel evidence (temporal, secondary_key, text, optional llm);
• reconstruction-run identity, configuration/model/profile references, confidence, abstention, and provenance;
• project-history inference from supplied evidence;
• explicit truth status for observed, inferred, proposed, and unavailable evidence.

Naruon owns

• customer-owned IMAP/JMAP/provider access and credentials;
• canonical email/message/thread/source identities;
• tenant/workspace authorization;
• project/task/commitment records owned by Naruon;
• provider mutation, mail/calendar writeback, retry, reconciliation, and audit;
• deciding which authorized Naruon evidence may be submitted to the LineageWeave boundary.

Neither repository may read the other's application database directly.

Required reusable contract

Provide one versioned integration surface that can be shipped independently. Preferred order:

1. a stable Rust/Python package only if the algorithm can remain store-agnostic and stateless; otherwise
2. a versioned service/plugin contract with generated SDKs.

The contract must accept bounded, already-authorized evidence, not Naruon credentials or arbitrary database access.

Suggested request objects:

lineage_analysis_request
lineage_evidence_record
lineage_secondary_key
lineage_project_hint
lineage_temporal_evidence
lineage_analysis_policy

Suggested response objects:

lineage_analysis_result
lineage_reconstruction_run
lineage_edge_result
lineage_channel_evidence
lineage_project_projection
lineage_limitation

Every input record must carry an opaque caller-owned evidence reference. Every output edge must point only to those opaque references and must include its truth status and provenance.

Email-specific invariants

• RFC Message-ID, References, In-Reply-To, provider thread identity, raw-content hash, sent/received/available time, participant evidence, subject/body similarity, and attachment evidence remain separate features; do not flatten them into one unexplained score.
• Do not silently turn a semantic relation into an RFC reply relation.
• Missing evidence is unavailable, never zero.
• Email body/subject/participants may be submitted only under the caller's explicit authorized scope and bounded payload policy.
• The contract must support content-minimized modes where only caller-computed features or evidence hashes are supplied.
• Knowledge-cutoff runs must bind to available_time <= knowledge_cutoff; later evidence cannot leak into historical reconstruction.

Project-management invariants

• A LineageWeave project projection is evidence/inference, not Naruon's authoritative project status.
• Naruon may adopt a proposed relation only through its own deterministic/human approval policy.
• A LineageWeave result may link mail → commitment/task/project evidence without creating provider actions or calendar writes.
• Responsibility/actor evidence remains observed/inferred context and is not an HR assignment ledger.

Packaging / plugin readiness

• Publish semantic version, immutable source commit, artifact digest, license, SBOM, SLSA provenance, and compatibility range.
• No mutable git branch/submodule is a production dependency.
• Add contract fixtures that Naruon can run consumer-side.
• If Naruon plugin SDK (#976) becomes the chosen runtime, expose only a bounded kg.extractor / workspace.surface / new reviewed lineage extension point rather than importing Naruon internals.

TDD acceptance

1. Naruon-shaped synthetic email evidence can be submitted without Naruon DB access and returns deterministic opaque-reference edges.
2. RFC reply/thread evidence remains distinguishable from semantic/project lineage evidence.
3. Optional LLM channel absence is explicit and does not fabricate a zero score.
4. Hidden/omitted evidence cannot appear in outputs.
5. Duplicate requests with the same analysis identity are idempotent.
6. Historical cutoff tests prove later-available evidence cannot influence earlier runs.
7. Project projection never emits an authoritative Naruon status or provider mutation.
8. Package/service contract is independently versioned and consumer contract tests run from a released artifact.
9. Changed production code keeps 100% statement/branch coverage and complete public docstrings.

Related work

• LineageWeave [Event Lineage] Persist and explain channel evidence #274 — persist/explain channel evidence
• LineageWeave [Buyer Gap] Open project evidence as a unified chronological history timeline #279/[Project history] 프로젝트 전 주기 이력 통합 조회와 담당 인수인계 구간 #280/[Project history] Add authoritative lifecycle ingestion and idempotent reconciliation #284 — project-history projection and authoritative source ingestion boundary
• LineageWeave Activate the optional lineage LLM channel through a bounded asynchronous rebuild #289 — bounded asynchronous optional LLM channel
• LineageWeave [Buyer Gap] Replace pseudo-CalDAV feed with a Naruon-owned calendar projection #336 / PR superseded: define Naruon-owned event projection contract #337 — Naruon calendar projection consumer boundary
• Naruon #976 — plugin SDK
• Naruon #977 — dense KG inference
• Naruon #1350 — evidence-based email/thread/document resolution

Delivery gate

Do not implement this by copying code into Naruon. First stabilize and release the LineageWeave contract/artifact; then Naruon may consume it behind an optional integration capability. Exact-head CI/security/coverage/review and independent approval remain mandatory.

[seonghobae]

Consumer-side counterpart created as ContextualWisdomLab/naruon#1437. Delivery order is now explicit: stabilize/release the LineageWeave provider contract first; Naruon then consumes it behind an optional admission policy and durable async analysis boundary. Calendar projection remains separately tracked by #336 / PR #337.

[seonghobae]

Provider-side contract implementation is opened as #340. It is based on origin/main and keeps Naruon DB access, credentials, provider mutations, and authoritative project status outside LineageWeave. Local verification: 14 tests passed, Ruff passed, diff check passed. Consumer-side work remains ContextualWisdomLab/naruon#1437.

[seonghobae]

Provider-side implementation is now open as Draft PR #339: #339

Implemented on a branch created from exact protected main@2feba74b75863810869cde680b19032a93fba413:

• strict external lineage contract 1.0.0;
• JSON Schema Draft 2020-12;
• bounded opaque caller evidence with no DB/mailbox/provider access;
• available-time knowledge-cutoff filtering;
• observed RFC/provider/manual parent relations kept distinct from inferred continuation;
• same-group, temporal, and cycle validation for explicit parents;
• candidate-pair budget enforcement before optional LLM activity;
• exact active channel scores/weights/contributions and explicit LLM availability;
• proposed, group-bounded project projections;
• deterministic SHA-256 request/result digests;
• public import surface at lineageweave.external_lineage;
• ADR 0124, APA 7th doctoring, design spec, implementation plan, and changelog.

Local exact-remote-branch verification: 58 focused tests passed; changed production statement/branch coverage 100%; docstrings complete; compile, JSON syntax, Ruff, and diff hygiene passed.

The PR remains Draft. Hosted exact-head CI/security/documentation/review and immutable release-artifact evidence remain mandatory before Naruon consumption. No self-approval, force-push, or protected-branch bypass is requested.

[seonghobae]

Current implementation routing correction: the provider-side external email/project lineage contract is Draft PR #343 (feat/external-lineage-integration-contract). PR #339 is the separate TEPP project-history recovery lane, and the earlier #340 reference is stale.

Current exact state after normal reconciliation with protected main:

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

The PR publishes the strict request/result contract, cutoff-aware store-agnostic execution adapter, channel evidence, explicit observed relation handling, proposed project projections, canonical digests, JSON Schema, ADR/doctoring, and focused contract tests. Naruon runtime consumption remains separately governed by ContextualWisdomLab/naruon#1437 and stays disabled until exact-head gates, independent approval, normal merge, and immutable release-artifact evidence are complete.

[seonghobae]

Provider contract status correction: #343 merged at 125a8069a1554874d8067a15047e19d780ea6b7b into the non-main stack base feat/analysis-run-name-evidence-lineage owned by root PR #258. Protected main exact head ef6f5a5ffcb467bd935dc1e53acc0029669b0bd7 does not contain or release that contract, so Naruon #1437 must remain disabled and this issue remains open. The current #258 changes-requested state is the shared central coverage-materialization evidence failure addressed by ContextualWisdomLab/.github#1210; after that control-plane repair lands, rerun #258 exact-head gates and only then integrate to protected main, publish the immutable artifact/SBOM/provenance, and enable consumer contract work.

[seonghobae]

Authority correction after reading the current LineageWeave PRD and ecosystem
product boundaries: LineageWeave owns authorization, evidence admission,
knowledge cutoffs, orchestration, provenance persistence, and evidence UI. It
does not own lineage arithmetic.

ADR 0225 is now proposed on PR #663. TEPP owns temporal/psychometric
measurement, fast-mlsirm owns multilevel estimation and weights, RankWeave owns
fusion/evaluation/policy selection, and ThreadWeave owns deterministic reference
threading. RankWeave issue #45 tracks the required Rust calculation core.

Therefore the closed stack implementation from PR #343 must not be republished
unchanged: it imports LineageWeave's local reconstruction arithmetic, including
fixed window/threshold behavior. Provider delivery for this issue resumes only
after released owning-library envelopes exist; LineageWeave will then expose a
fail-closed adapter that validates and persists those results without
recalculation. Naruon #1437 remains disabled until that released contract and
protected exact-head evidence exist.

[seonghobae]

PR #636 closed unmerged at exact head f7b9a65f. Although it required explicit calibrated weights, it republished closed #343's Python channel-score, candidate-budget, and fusion-input calculations, contradicting ADR 0225's non-calculating LineageWeave boundary. The branch remains recoverable; no checks or reviews transfer.

This issue remains open until RankWeave #45 publishes the Rust-backed fusion authority and a current-main LineageWeave PR contains only authorization, evidence admission, provenance, wire validation, and persistence/display orchestration. Naruon stays disabled until that replacement is protected-main and immutably released.