Repository navigation
[Cross-repo] Publish an evidence-bounded email/project lineage contract for Naruon consumption #338
Description
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, optionalllm); - 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:
- a stable Rust/Python package only if the algorithm can remain store-agnostic and stateless; otherwise
- 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 (a11y(reports): include buyer-visible LeftoverPairList evidence in actionable button names #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
- Naruon-shaped synthetic email evidence can be submitted without Naruon DB access and returns deterministic opaque-reference edges.
- RFC reply/thread evidence remains distinguishable from semantic/project lineage evidence.
- Optional LLM channel absence is explicit and does not fabricate a zero score.
- Hidden/omitted evidence cannot appear in outputs.
- Duplicate requests with the same analysis identity are idempotent.
- Historical cutoff tests prove later-available evidence cannot influence earlier runs.
- Project projection never emits an authoritative Naruon status or provider mutation.
- Package/service contract is independently versioned and consumer contract tests run from a released artifact.
- 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 a11y(reports): include buyer-visible LeftoverPairList evidence in actionable button names #976 — plugin SDK
- Naruon fix(a11y): include leftover-pair evidence in button names #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.
Activity
seonghobae commentedon Aug 21, 2026
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 commentedon Aug 21, 2026
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 commentedon Aug 21, 2026
Provider-side implementation is now open as Draft PR #339: #339
Implemented on a branch created from exact protected
main@2feba74b75863810869cde680b19032a93fba413:1.0.0;lineageweave.external_lineage;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 commentedon Aug 21, 2026
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:main@ef6f5a5ffcb467bd935dc1e53acc0029669b0bd7;e51ec822fb939ac8aee1aa70a423ce548c8711fa;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 commentedon Aug 22, 2026
Provider contract status correction: #343 merged at
125a8069a1554874d8067a15047e19d780ea6b7binto the non-main stack basefeat/analysis-run-name-evidence-lineageowned by root PR #258. Protected main exact headef6f5a5ffcb467bd935dc1e53acc0029669b0bd7does 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 commentedon Aug 25, 2026
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 commentedon Aug 25, 2026
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.
seonghobae commentedon Sep 1, 2026
Reopened because the issue state had drifted from its own latest acceptance evidence.
Fresh 2026-09-01 owner read:
main@cb187cadee5fb6c46d8a944815ccc154a1e028d1now containslineageweave/external_lineage.py, but GitHub Releases is still empty and no protected-main workflow currently publishes an immutable contract package/service artifact with SBOM/provenance/compatibility evidence;main: the latest owner-boundary record on this issue requires reusable retrieval/fusion calculation to come from RankWeave and deterministic RFC reference threading from ThreadWeave, with LineageWeave retaining authorization/evidence admission/provenance/wire validation/persistence-display orchestration;Next RED/GREEN acceptance for this issue is therefore not “publish the current Python module”: first prove any remaining local reusable reconstruction/fusion or RFC-threading computation that belongs to RankWeave/ThreadWeave, replace it through released owner contracts/ACLs, then bind source commit + contract version/digest + package/service artifact + SBOM/provenance + consumer fixture compatibility in one release lane. No mutable branch is an acceptable Naruon dependency.