{"id":"facb86d4-c8eb-4bb1-9f3d-ec024a4a9871","arxiv_id":"2607.22953","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A new protocol formalizes minimum-necessary selective disclosure over temporal knowledge graphs of personal data, but is not yet implemented.","lead":"This paper proposes a protocol called Provenance Preserving Chronicles that decides the smallest piece of a person's data graph to share with an AI agent, based on who asks, why, and what they need. It is a design sketch for privacy-respecting data sharing, not a working system.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Planner incompleteness breaks the guarantee: if I(Q) drops a genuine need, S* is compact but under-informative, and Algorithm 1 cannot detect it; the paper's own AFib example shows this failure.","rationale":"The reader's weakest assumption correctly identifies the same load-bearing point I find. The entire formal machinery—Eq. (1)'s minimization, Algorithm 1's sufficiency check, the protocol's pruning—is parameterized by I(Q). Nothing in the design independently verifies that I(Q) covers all genuine information needs. The paper is unusually candid about this: §4.3 and §5.1 both flag it as the condition on which soundness depends. The AFib example is not a hypothetical edge case; it is the paper's own illustration that the structural baseline can certify a release that is clinically insufficient. That means the central 'sufficient for the request' claim is only as strong as the planner, and the paper provides no evidence that any planner achieves completeness. I considered the alternative concern about inference leakage (a correct S* can still imply denied attributes), but the paper's design deliberately separates access-control guarantees from post-disclosure inference and lists inference closure as an optional mitigation; within the paper's scoped definition of 'authorized' (element-wise A), the argument is internally consistent. Therefore the planner-completeness assumption is the most load-bearing. Because the paper itself presents the work as a position/protocol design and explicitly conditions soundness on this open problem, the appropriate verdict remains CONDITIONAL rather than ACCEPT or REJECT. The concrete test above would determine whether the assumption is merely an acknowledged open problem or an actual failure in practice.","tokens_in":16194,"tokens_out":6068,"duration_ms":62201,"concrete_test":"Build a small benchmark of, say, 30 clinical queries on a synthetic polypharmacy Chronicle, each with a gold I*(Q) annotated by a clinician (including diagnosis indications, allergy context, and other task-relevant needs). Run an LLM-based planner (the paper's default hybrid mode) to produce I(Q), and compile S* per §6 using Algorithm 1. Then compute recall of the gold needs: |I(Q) ∩ I*(Q)| / |I*(Q)|. If recall < 1 on any query for which a clinician judges the released S* to change the recommended action, the sufficiency guarantee is violated. Also run the same test with a symbolic planner to see whether the failure is planner-specific.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central guarantee of Eq. (1)—that S* is both minimal and sufficient—is defined entirely relative to I(Q), the planner's decomposition of Q into schema-level information needs. The paper states this explicitly in §4.3: 'sufficiency, minimization, and authorization are all defined relative to I(Q), so a planner that drops a genuine need yields an S* that is compact but under-informative.' Algorithm 1 validates S* only against the supplied I(Q): it checks PathCov, PredComplete, connectivity, and provenance for the needs in I(Q), but it has no mechanism to detect a missing need. The protocol's minimization step (Prize-Collecting Steiner Tree in §6(3c)) then actively makes things worse by pruning authorized-but-unneeded elements that would have compensated for the missing need. The AFib example in §5.1 is a concrete instance: under a literal reading of the query, the planner omits the AFib indication, and Algorithm 1 passes S* without it, even though a cardiologist assessing an amiodarone/warfarin interaction needs exactly that diagnosis. The paper itself calls the minimization target 'an open question, not a settled default' (§5.1). Thus the paper's own worked example demonstrates that the protocol can produce a release that satisfies its formal definition of sufficiency but fails the ordinary-language claim of being sufficient for the request. This is the load-bearing assumption: if request planning cannot be made complete (or audited), the whole 'minimum-necessary' compilation collapses into 'minimum relative to a possibly-incomplete decomposition.'","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes Provenance Preserving Chronicles (PPC), a federated protocol for minimum-necessary disclosure of personal context represented as temporal knowledge graphs (Chronicles). The central idea is to compile, per request, a compact authorized evidence subgraph that is both minimal under a stated objective and sufficient according to an explicit structural check. The paper formalizes this as a constrained minimization problem (Eq. 1), defines an authorization function over relationship and purpose, presents a two-phase interaction model (provenance-linked text first, raw artifacts only after explicit holder approval), and instantiates the design in medical and litigation scenarios. It also provides an explicit threat model and honestly states that it is a position/protocol-design paper without an implementation or empirical evaluation.","tokens_in":16536,"tokens_out":5709,"duration_ms":60006,"significance":"If the framework were realized, it would provide a principled compilation layer over existing federated storage and policy substrates, giving operational meaning to concepts such as purpose limitation and minimum-necessary disclosure in structured personal data. The paper's strengths include a clear separation between a sufficiency validator (Algorithm 1) and a compiler that searches for S*, an explicit two-phase release protocol that reduces disclosure blast radius, and a fair positioning against existing systems (Solid + VC + policy engine) rather than an overstated break from them. The paper also deserves credit for explicitly surfacing its own load-bearing assumptions—notably the completeness of request planning—and for labeling the distributional sufficiency tier as aspirational rather than shipped. The worked AFib example is particularly valuable for exposing the tension between structural minimization and clinical utility.","major_comments":[{"comment":"The central guarantee of Eq. (1)—that S* is both minimal and sufficient—is defined relative to I(Q), the planner's decomposition of Q into schema-level information needs. The paper explicitly acknowledges (§4.3) that a planner dropping a genuine need yields an S* that is compact but under-informative, and the AFib example (§5.1) concretely shows the resulting clinically insufficient release. However, the abstract and conclusion state that the system releases a subgraph 'sufficient for the request' without this qualification. Since this caveat is load-bearing for the paper's main claim, the abstract, Eq. (1), and the conclusion should consistently phrase the guarantee as 'sufficient relative to the request decomposition I(Q)' and clearly flag that the protocol does not, in its current form, provide an absolute minimum-necessary guarantee. The paper should also consolidate the planning-com","section":"§4.3 and §5.1"},{"comment":"The AFib example itself is used to illustrate the 'minimality can fight utility' tension, but the paper stops at stating the problem and does not propose even a heuristic mitigation. Since the example directly undermines the ordinary-language reading of 'share no more than the request requires' (the released S* omits context a cardiologist would reasonably need), the paper should discuss potential directions—e.g., expanding I(Q) with indications for retrieved medications, or allowing the requester to challenge/refine the decomposition in a second round—even if only as future work. As written, the paper's own worked example shows that the protocol can satisfy its formal definitions while failing the clinical purpose it is meant to serve, and the reader is left without any guidance on how to close this gap.","section":"§5.1 and Table 2"}],"minor_comments":[{"comment":"The phrase 'sufficient for the request' appears without the caveat 'relative to the request decomposition I(Q)'. Adding this qualifier would make the paper's claims more precise and prevent overstatement of the protocol's guarantees.","section":"Abstract and Conclusion"},{"comment":"The notation 'S ⊆ G_Cu' is slightly ambiguous because S is defined as a pair (V_S, E_S). It would be clearer to write 'V_S ⊆ V_Cu and E_S ⊆ E_Cu' explicitly, as done elsewhere in the text.","section":"Eq. (1)"},{"comment":"The distributional check in lines 22–24 is vague: what is the sample space over which P_M is defined, and what does 'semantic equivalence classes of answer strings' mean operationally? A brief clarification would help, especially because the paper labels this tier as aspirational.","section":"Algorithm 1"},{"comment":"PPC's row shows '✓' for all capabilities, but since the system is not implemented, these checkmarks represent design intent rather than demonstrated functionality. Adding a footnote to distinguish 'designed' from 'implemented' would be more precise.","section":"Table 1"},{"comment":"The paper mentions Prize-Collecting Steiner Tree as an example solver but does not note that the underlying minimization is NP-hard or discuss approximation guarantees. Since the protocol explicitly does not certify minimality, a one-sentence acknowledgement would prevent readers from assuming that the solver produces the exact optimum of Eq. (1).","section":"§6, step (3c)"}],"recommendation":"minor_revision","confidential_remarks":"This is a well-written position paper that openly acknowledges its limitations, including the absence of an implementation and the open problem of request planning. The main concern about planner completeness is explicitly surfaced by the authors and illustrated with a concrete example; it does not invalidate the paper's contribution as a framing and protocol-design paper, but it should be more carefully reflected in the abstract and conclusion. I believe the paper is suitable for the workshop audience after minor revisions that consistently qualify the guarantees as relative to the information-need decomposition."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper is worth taking seriously, but the headline is this: it is a position and protocol-design paper, not a validated system, and the central guarantee is explicitly conditional on a step the paper does not solve. The authors know this and say it plainly. That honesty is the best thing about the paper.\n\nWhat is actually new: framing Chronicle disclosure as policy-constrained subgraph compilation over temporal, predicate-labeled knowledge graphs. Eq. (1) is a clean formal objective, and Algorithm 1 is a sensible structural sufficiency validator. The two-phase text-first/artifact-second release is a concrete, defensible design for reducing blast radius. The related-work section is genuinely good—the comparison against Solid pods plus credentials is fair, and the distinction between ledger-based access management and exchange-time minimization is well argued. The worked medical example is useful: it does not just show the happy path; it shows the minimizer dropping the AFib diagnosis and discusses why that is a problem. That is more intellectual honesty than most protocol papers manage.\n\nThe soft spot, as the stress-test note says, is that the whole sufficiency guarantee in Eq. (1) is relative to I(Q). If the planner drops a genuine information need, Algorithm 1 will happily certify an under-informative subgraph. The AFib example is not a hypothetical edge case; it is the paper's own central example, and the paper admits the result is 'structurally sufficient yet clinically insufficient.' So the ordinary-language claim that PPC releases 'the smallest authorized subgraph sufficient for the request' is not actually guaranteed. The authors call this an open question, which is fair, but it is a load-bearing open question, not a minor implementation detail. Anyone citing this paper for the guarantee should read Section 5.1 first.\n\nThe other soft spots are less severe. No implementation, no benchmark—fine for a position paper, but it means the protocol's operational claims are unvalidated. Cross-holder entity alignment is assumed, not solved. Those are acknowledged.\n\nNet: this is a solid framing paper that would likely lead to useful follow-up work. It does not deserve desk rejection, but it should go to referees who understand that they are judging a problem statement and a protocol sketch, not a working system. The serious weakness is not fatal to the stated goal, but it should be front and center in any review or citation.\n\nI'd bring it to a reading group discussion, and I would cite it for the problem formulation, with the caveat about the planner. Recommend: send to peer review as a position paper; expect the authors to either narrow their claims or make progress on planning completeness.","headline":"A honest position paper that frames minimum-necessary disclosure as subgraph compilation, with a central caveat the authors themselves flag: the guarantee is only as good as the request planner.","tokens_in":17035,"tokens_out":2348,"would_cite":true,"duration_ms":23919,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper argues that selective disclosure of a person's Chronicle should be formalized as minimum-necessary subgraph compilation: given a relationship, purpose, and query, release the smallest authorized evidence subgraph that is sufficien","keywords":["minimum-necessary disclosure","selective disclosure","Chronicle","knowledge graph","federated networks","purpose-based access control","relationship-based access control","data sovereignty"],"falsifier":"Find a query and a Chronicle where Algorithm 1 accepts a subgraph as structurally sufficient—path coverage, predicate-type completeness, connectivity, provenance—yet a competent human consumer or an LLM demonstrably cannot answer the query from that subgraph without additional context, as in the paper's own AFib example. A direct test of the completeness assumption: take a set of purpose-annotated queries, have domain experts enumerate the information needs, and check whether the planner's I(Q) matches; any dropped genuine need falsifies the guarantee.","tokens_in":16027,"feed_emoji":"🔐","tokens_out":6576,"duration_ms":59817,"temperature":0.7,"pith_summary":"This paper proposes that selective disclosure of a person's Chronicle—a temporal knowledge graph of their lived situations—should be treated as a constrained minimization problem: given who asks, why they ask, and what they ask, release the smallest authorized evidence subgraph sufficient for the request. The authors formalize this as a minimization objective over the holder's consolidated Chronicle, subject to every node and edge passing an authorization function based on requester relationship and stated purpose, and subject to a structural sufficiency predicate. They provide a validator that checks path coverage, predicate-type completeness, connectivity, and provenance, plus an optional distributional refinement for LLM consumers. The two-phase protocol releases provenance-linked text first and raw artifacts only after explicit per-artifact holder approval, which the authors argue reduces disclosure blast radius. This is a protocol-design proposal rather than an implemented system, and the paper explicitly flags the minimization target and the request-planner completeness assumption as open questions.","feed_headline":"Share no more: release shrinks to the smallest authorized subgraph","feed_subtitle":"A knowledge-graph protocol ties every release to relationship, purpose, and query; raw files await explicit approval.","key_machinery":"The central object is the authorized evidence subgraph S*, defined as the solution to a minimization problem over the holder's consolidated Chronicle: minimize |S| subject to S being drawn from the holder's graph, every node and edge passing the authorization function A(relationship, purpose, element), and the sufficiency predicate holding. Sufficiency is enforced by a validator that checks four structural conditions—path coverage of each information-need template (with ontology subsumption), predicate-type completeness, connectivity of the evidence paths, and provenance completeness—plus an optional distributional check comparing the consuming LLM's answer distribution over S* versus the fu","core_discovery":"The central claim is that a Chronicle holder can—and should—answer a requester's query by compiling a compact authorized evidence subgraph S*, rather than by returning all data the requester is allowed to see. The subgraph is defined as the minimum-size subgraph drawn from the holder's consolidated Chronicle that passes the authorization function A for every node and edge and satisfies a structural sufficiency check: every information need is covered by a connected predicate-typed path with predicate-type completeness and full provenance. The authors argue that existing federated storage, policy engines, and blockchain systems provide pieces—sovereign storage, allow/deny policies, tamper-evi","pith_inferences":["A natural extension would be to make the information-need set I(Q) a negotiated object rather than a one-shot planner output, letting the requester clarify or expand the need set before minimization runs.","The structural validator is consumer-agnostic, so a similar compile-time minimization layer could be applied to any predicate-typed graph retrieval system that must respect purpose and relationship constraints, not only PAi Chronicles.","Making the distributional sufficiency tier computable would turn the protocol from a compile-time guarantee into an empirical one, but it conflicts with the federated no-central-materialization stance; a per-holder local divergence check aggregated by the coordinator is a plausible middle path.","The AFib case suggests a testable variant of the minimization objective: instead of pure size, require inclusion of diagnosis-indication edges whenever a linked prescription is released, and measure whether task outcomes improve."],"forward_implications":["If a holder releases only S*, denied predicate categories (e.g., billing, psychiatric notes) never cross the holder boundary, making the access-control guarantee enforceable at hold time rather than by post-hoc redaction.","Because sufficiency is checked structurally against path templates and re-run on the assembled cross-holder subgraph, the protocol can guarantee that every information need is covered by connected, provenance-traceable paths even when fragments come from multiple federated holders.","The two-phase text-first/artifact-after-approval flow means high-fidelity raw data never rides along with a text response, limiting the blast radius of a disclosure even if the requester's agent is compromised after receipt.","Purpose limitation and relationship-based access become first-class inputs to a formal minimization objective, turning 'minimum necessary' regulatory requirements into a concrete per-request optimization target.","The AFib example shows a direct corollary: a structurally sufficient S* can still omit context a competent consumer needs, so structural sufficiency lower-bounds task sufficiency without implying it."],"fun_headline_variants":["Chronicle shrinks to the minimum subgraph your request can see","Your query gets a tiny evidence subgraph, nothing extra leaks out","Minimum-necessary disclosure: only the connected proof for your request","Provenance-preserving: the subgraph answers, raw files wait for your OK","From 'allowed to see' to 'required to see': a sharper disclosure rule"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is that the request planner can reliably decompose a natural-language query into a complete set of schema-level information needs; if the planner drops a genuine need, the released subgraph is compact but under-informative, and the 'smallest sufficient' guarantee collapses.","fun_headline_variants_meta":{"raw":{"variants":["Chronicle shrinks to the minimum subgraph your request can see","Your query gets a tiny evidence subgraph, nothing extra leaks out","Minimum-necessary disclosure: only the connected proof for your request","Provenance-preserving: the subgraph answers, raw files wait for your OK","From 'allowed to see' to 'required to see': a sharper disclosure rule"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000118,"raw_usage":{"total_tokens":961,"prompt_tokens":826,"completion_tokens":135,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":570,"completion_tokens_details":{"reasoning_tokens":52}},"tokens_in":570,"tokens_out":135,"duration_ms":3026,"temperature":1.0,"reasoning_tokens":52,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T04:01:21.304006+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Find a query and a Chronicle where Algorithm 1 accepts a subgraph as structurally sufficient—path coverage, predicate-type completeness, connectivity, provenance—yet a competent human consumer or an LLM demonstrably cannot answer the query from that subgraph without additional context, as in the paper's own AFib example. A direct test of the completeness assumption: take a set of purpose-annotated queries, have domain experts enumerate the information needs, and check whether the planner's I(Q) matches; any dropped genuine need falsifies the guarantee.","supporting_citations":[],"review_version":1}