{"id":"e7d45b17-938e-4395-84dc-969b098d9a34","arxiv_id":"2608.00248","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A hash-keyed dedicated consent object, with keyword-scoped opt-in and cross-keyword opt-out, enforces SMS consent in multi-tenant CRM packages without modifying customer schema.","lead":"This paper describes a data model for recording SMS opt-in/opt-out consent inside Salesforce CRM managed packages, using a dedicated consent record object and hash-based deduplication. It is useful to engineers and compliance teams building multi-tenant messaging tools that must honor TCPA consent rules.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Consent-check query in §6.2 cannot be a single query for arbitrarily large campaigns; Salesforce IN-clause limits break the claimed bulk-scale efficiency.","rationale":"The reader's verdict is CONDITIONAL, and we agree with that verdict, but for a different, more concrete reason. The phone-number identity issue is a domain assumption that could be scoped; the SOQL IN-clause limit is an internal inconsistency that directly invalidates the stated efficiency guarantee. The paper provides a clear design and useful patterns, but the claim of 'exactly one query regardless of campaign size' cannot hold on the Salesforce platform it references. A batching strategy or a revised bounded claim would address this. Therefore we recommend CONDITIONAL: accept with required revisions, rather than rejecting the architecture entirely.","tokens_in":4553,"tokens_out":5172,"duration_ms":50355,"concrete_test":"Create a Salesforce org with a custom object and a SOQL query using a bind variable list of 30,000 distinct IDs (or the documented maximum + 1) in the IN clause. Execute the query as described in §6.2. If the query returns a governor-limit error (or requires chunking), the paper's claim of 'exactly one query regardless of campaign size' is false. Alternatively, analytically compute the maximum campaign size for a single query given Salesforce's SOQL limits and hash length; if that maximum is orders of magnitude below the claimed 'bulk scale', the design needs a batching mechanism.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"§6.2 claims the consent check 'consumes exactly one query regardless of campaign-member count' by using `WHERE active = true AND uniqueId IN :hashSet`. This ignores Salesforce SOQL limits on the number of bind values (typically 20,000) and on query text length. For a bulk campaign with more members than that limit, the single query either fails outright or must be split into multiple queries, increasing governor-limit consumption and contradicting the stated 'arbitrary size' scalability. The paper offers no batching strategy or limit-based sizing analysis, so the central efficiency claim is unsupported. This is not a matter of external consensus; it is an internal inconsistency because the paper cites [1] Salesforce governor limits yet claims unbounded single-query execution. The correctness claim may survive, but the efficiency claim at the heart of 'consent suppression at bulk scale' does not.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a consent-record architecture for SMS opt-in/opt-out compliance in multi-tenant Salesforce managed packages. The design centers on a dedicated custom consent object with polymorphic Contact/Lead references, keyword-scoped consent records, a deterministic hash-based external ID for idempotent upsert, cross-keyword opt-out deactivation by phone number, and service-layer suppression checks at bulk send time. The central claim is that this architecture correctly and efficiently enforces TCPA consent requirements at bulk scale while respecting the schema-immutability and governor-limit constraints of managed-package distribution.","tokens_in":4798,"tokens_out":4769,"duration_ms":52755,"significance":"If the design performs as claimed, it is a useful reference pattern for ISVs building compliance-sensitive messaging on CRM platforms. The paper is strongest in its precise articulation of managed-package constraints—no standard-object modification, permission-enforcing data access, bounded governor limits—and in its explicit pseudocode for consent capture, deactivation, re-opt-in, and suppression. The hash-based external-ID upsert and service-layer suppression are sensible, reusable ideas. However, the paper provides no empirical validation, code artifact, or even a limit-based sizing analysis, so the efficiency and production-readiness claims remain unverified. The contribution is a credible architecture proposal rather than a demonstrated system.","major_comments":[{"comment":"The claim that the consent check 'consumes exactly one query regardless of campaign-member count' is internally inconsistent with the Salesforce governor limits cited in [1]. An SOQL IN clause has a hard bound on the number of bind values (typically 20,000) and on query text length. For a campaign larger than that cap, the single-query form either fails or must be split into multiple queries, making query consumption a function of campaign size. The paper neither states the limit nor provides a batching or chunking strategy. This is a load-bearing issue because the stated contribution is explicit 'resource-limit compliance at bulk-send scale'; the correctness of the consent check is not affected, but the efficiency claim is unsupported as written.","section":"§6.2"},{"comment":"The composite key UniqueId = normalize(phoneNumber)∥keywordId is used both as the idempotent upsert key and, in §4.2, as the basis for deactivating 'all active consent records associated with the sending phone number.' This equates a phone number with a consenting individual. The paper does not address shared phones, number reassignment, or the same natural person appearing as both Contact and Lead. Under any of these conditions, consent can be attached to the wrong person or suppressed for the wrong person, which breaks the TCPA compliance guarantee that is the central motivation of the paper. The authors should either add a resolution/matching step that ties consent to a resolved CRM person ID, or explicitly scope the design to a single-individual-per-phone assumption with stated limitations.","section":"§3.3, §4.2"},{"comment":"The manuscript repeatedly asserts that the architecture is 'generalized from patterns implemented' in a production managed package spanning healthcare, financial services, and sales operations, but no measurements, tests, or reproducible artifacts are provided. For a design/pattern paper this alone is not disqualifying, but the efficiency claims in §8 ('at scale ... this reduction matters') depend on quantities that are never measured or bounded. The paper should include at minimum a limits-based sizing table (e.g., maximum campaign size under the IN-clause cap, transaction query/DML counts per batch) or an explicit statement that the claims are design-level and not yet empirically validated.","section":"Abstract, §8"}],"minor_comments":[{"comment":"The phrase 'suppress all messages from that program to that number' is a bit ambiguous: the pseudocode deactivates all consent records for the phone number regardless of keyword, which is broader than 'that program' if a tenant runs multiple programs. Clarify whether suppression is organization-wide or program-wide.","section":"§4.2"},{"comment":"The pseudocode assumes every member has a non-null mobilePhone when an opt-in keyword is configured. If mobilePhone is null, buildUniqueHash may generate a misleading hash or fail. Add an explicit null-check and decide whether such members should be excluded from the consented set.","section":"§5.2"},{"comment":"The query string is shown as string concatenation with a bind variable. The pseudocode is illustrative, but it may confuse readers about SOQL binding semantics; consider showing the query with a named bind parameter and noting that the IN clause must be chunked under the limit identified in the major comment.","section":"§6.2"},{"comment":"Reference [5] is a blog-style source ('CQRS Documents'). If possible, cite a peer-reviewed or more stable treatment of idempotent upsert patterns, or at least describe the practice as an established pattern in the text.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The paper's core design is plausible and the managed-package constraints are well described, but two load-bearing claims need work before publication: the 'exactly one query at arbitrary bulk size' claim is contradicted by the platform's own IN-clause limits, and the phone-number-as-person identity assumption undermines the correctness claim in realistic shared/reassigned-number scenarios. The stress-test concern about the IN-clause limit lands. I would not reject the paper—these issues are addressable with scoping, batching design, and a limits-based analysis—but the manuscript is not ready as-is."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper is a clear, honest engineering report on a consent record architecture for SMS opt-in/opt-out in Salesforce managed packages. The core design is sensible: a dedicated consent object with a composite hash (normalized phone + keyword) as external ID for idempotent upsert, keyword-scoped consent with cross-keyword opt-out, and service-layer suppression. The multi-tenant constraints it addresses are real, and the schema-immutability framing is genuinely useful. I agree with the reader that this combination appears absent from the published literature, so there's a real contribution here, albeit a narrow one.\n\nThe main soft spot is the efficiency claim in §6.2. The stress-test is correct: the paper says the consent check \"consumes exactly one query regardless of campaign-member count\" and scales to \"arbitrary size,\" but Salesforce caps the number of bind values in an IN clause (typically 20,000) and query text length. For a campaign over that size, the single query fails or must be split, and the paper offers no batching plan. This overstatement is load-bearing for the \"bulk scale\" part of the contribution, but it is fixable — the same design works with chunked queries. The paper should acknowledge the limit and describe a chunking strategy.\n\nThe other weakness, which the reader flagged, is the phone-number-as-identity assumption. A shared or reassigned number can attach or suppress consent for the wrong person. That is a compliance-relevant gap, and the paper should at least scope the claim to SMS consent being number-agnostic, or discuss mitigations.\n\nOn the positive side, I don't see a circularity problem. The companion papers [6,7] are dependencies, not validation of this design. The self-citation is ordinary.\n\nThere is no empirical data, no code, and no governor-limit testing. For an experience report that's acceptable, but it means the paper can only claim a plausible design, not a validated one. The pseudocode is concrete enough to implement from, which is a point in its favor.\n\nI'd send this to peer review rather than desk-reject. The referee workload is manageable, and the niche community — Salesforce ISV architects dealing with TCPA — would benefit from a corrected version. The revision demands should be to fix the IN-clause overclaim, add a batching strategy, and explicitly scope the phone-number identity assumption. With those changes, this becomes a solid pattern write-up.","headline":"A coherent consent-architecture pattern for Salesforce managed packages, but the bulk-scale efficiency claim overreaches the platform limits.","tokens_in":5198,"tokens_out":2497,"would_cite":false,"duration_ms":23013,"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 claims that a dedicated consent record keyed by a deterministic hash of normalized phone number and keyword can enforce TCPA opt-in/opt-out requirements correctly and efficiently in multi-tenant CRM managed packages without modify","keywords":["consent record","TCPA compliance","SMS opt-in/opt-out","managed packages","multi-tenant CRM","hash-based deduplication","service-layer suppression","idempotent upsert"],"falsifier":"Find a scenario where the same normalized phone number maps to two distinct individuals (e.g., a Contact and a Lead for different people, or a number reassigned after opt-out). If an opt-in from one of them activates a single consent record that is then used to suppress or allow messages for the other, the central uniqueness claim fails. Concretely, create two Contact and Lead records with the same mobile number, have the Lead opt in with keyword JOIN, then send a campaign message to the Contact with the same campaign keyword; the single hash would grant send permission to the Contact even tho","tokens_in":4469,"feed_emoji":"📱","tokens_out":3961,"duration_ms":34262,"temperature":0.7,"pith_summary":"The paper argues that regulatory SMS consent can be modeled as a first-class record in a multi-tenant CRM managed package without touching the installing organization's schema. It proposes a dedicated consent object keyed by a deterministic hash of normalized phone number and keyword, which enables idempotent upserts on inbound opt-in/opt-out messages and a single-query suppression check at bulk send time. If this pattern holds, it gives independent enterprise tenants a reusable, resource-limit-compliant way to enforce opt-in consent and immediate opt-out under the TCPA.","feed_headline":"Hash-keyed consent records enforce SMS opt-out at bulk scale","feed_subtitle":"A deterministic phone-keyword hash lets managed packages track consent without modifying the host CRM schema.","key_machinery":"The load-bearing mechanism is the composite unique key UniqueId = normalize(phoneNumber) ∥ keywordId, stored as an external ID. normalize strips all non-digit characters, so E.164, local, and raw formats collide to one digits-only form. This key lets the platform's native upsert deduplicate by external ID, making consent-capture idempotent without a prior query; the same hash set is then used to fetch all active consents for a campaign batch in one WHERE ... IN query, and a STOP triggers a number-wide deactivation that sets active=false on every matching record. The service-layer suppression check with hash-set membership is what keeps the pattern within platform query limits at bulk scale.","core_discovery":"The central discovery is that a consent record with a composite external ID formed by concatenating the normalized digits-only phone number with the keyword ID can serve as the sole stable key for consent state. This key makes repeated inbound messages converge to one record, lets a STOP to any keyword deactivate all active consent records for that number, and lets the send pipeline filter a batch of campaign members with exactly one query against the consent table. The architecture places suppression in the service layer rather than per-record triggers, so the consent check does not grow with message volume. The author presents this as a production pattern generalized from a deployed CRM-na","pith_inferences":["The same hash-keyed consent object could be extended to multi-channel consent (email, push, voice) by broadening the composite key to include a channel dimension, giving a single consent record per contact-channel-keyword triple.","The number-wide deactivation on STOP implicitly assumes a phone number identifies a single consenting individual; if numbers are shared or reassigned, a future opt-in by the new owner could silently re-opt-in the previous owner — a testable edge case for the pattern.","The resource-limit argument suggests a general design principle: validation gates that must scale to bulk operations belong in the service layer, not per-record triggers; this could be carried to other compliance checks, such as suppression lists or jurisdiction-specific rules.","The stale-deliverability invalidation on consent change is a lazy-recompute approach that could be benchmarked against eager recomputation to see which better balances send-latency against consistency."],"forward_implications":["Any inbound opt-in message from a phone number and keyword upserts to exactly one active consent record, eliminating duplicate records under webhook retries.","A STOP, QUIT, CANCEL, or UNSUBSCRIBE from a phone number deactivates all active consent records for that number, regardless of which keyword triggered the original opt-in, matching the cross-program suppression regulators expect.","Re-opt-in after opt-out is accepted only when the new message is newer and carries a distinct source message identifier, so replays cannot reactivate consent.","The send-time filter retrieves active consent for an entire campaign batch in one query, so the suppression check stays O(n) map lookups and consumes a constant number of platform queries independent of campaign size.","Because consent lives entirely in the package's custom objects, the pattern installs into organizations without relying on custom fields or schema changes to core CRM objects."],"fun_headline_variants":["Hash-keyed consent records dedup SMS opt-ins and opt-outs","Composite phone-keyword hash locks SMS consent state","Consent suppression in service layer scales SMS compliance","One deterministic key tracks SMS consent across tenants"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The design assumes a phone number plus keyword uniquely identifies one consenting individual within an organization, so a shared, reassigned, or duplicated phone number never attaches consent to the wrong person.","fun_headline_variants_meta":{"raw":{"variants":["Hash-keyed consent records dedup SMS opt-ins and opt-outs","Composite phone-keyword hash locks SMS consent state","Consent suppression in service layer scales SMS compliance","One deterministic key tracks SMS consent across tenants"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000199,"raw_usage":{"total_tokens":1171,"prompt_tokens":668,"completion_tokens":503,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":412,"completion_tokens_details":{"reasoning_tokens":441}},"tokens_in":412,"tokens_out":503,"duration_ms":5965,"temperature":1.0,"reasoning_tokens":441,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T00:53:40.053868+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Find a scenario where the same normalized phone number maps to two distinct individuals (e.g., a Contact and a Lead for different people, or a number reassigned after opt-out). If an opt-in from one of them activates a single consent record that is then used to suppress or allow messages for the other, the central uniqueness claim fails. Concretely, create two Contact and Lead records with the same mobile number, have the Lead opt in with keyword JOIN, then send a campaign message to the Contact with the same campaign keyword; the single hash would grant send permission to the Contact even tho","supporting_citations":[],"review_version":1}