## EVIDENCE STATE Mode: EVIDENCE. Current-source requirement: check the official WordPress.org Detailed Plugin Guidelines and current Plugin Check documentation before treating this as a submission decision. The supplied code-model evidence is already enough to identify two review-critical surfaces: bundled paid functionality controlled only by license validation, and outbound telemetry without an evidenced opt-in. Plugin Check showing no required-check failures is useful evidence, but it does not prove manual-review compliance. ## SUBMISSION SCOPE **DIRECTORY CODE** The submitted ZIP contains Free plus Pro scheduling/PDF-export functionality. **COMMERCIAL LAYER** `license.php` contacts the seller server only to validate a paid key. A valid result unlocks functionality already present locally. **EXTERNAL SERVICE** The license endpoint is evidenced as license validation, not as substantive remote processing. **TELEMETRY** Activation posts site URL, PHP version, and plugin version to a metrics endpoint. **DOCUMENTATION** readme.txt says “freemium” but does not disclose the telemetry. ## GUIDELINE EVIDENCE MAP ### G1 — Paid/trialware boundary **Status: BLOCKER** Evidence: - Pro functionality is already in the directory ZIP. - Payment/license validation controls whether that local functionality becomes usable. - The external endpoint is described only as license validation. Under the current official directory model, this needs to be checked against the trialware/serviceware rules. On the supplied facts, the commercial split is not a genuine remote service providing the paid functionality; the paid key unlocks code already shipped in the free plugin. This is a model-level problem, not a style warning. ### G2 — Outbound tracking/consent **Status: BLOCKER** Evidence: activation immediately posts site URL plus runtime/plugin metadata to the seller endpoint, and no opt-in is supplied. The current official tracking rule must be applied here. The key review issue is not whether the payload feels “anonymous”; it is whether the plugin contacts an external server for tracking/metrics without explicit authorized consent. ### G3 — readme disclosure **Status: REVIEW-RISK** The readme does not describe the telemetry behavior that the code performs. Even after consent is fixed, documentation should accurately explain external data collection and its purpose. ### G4 — Plugin Check result **Status: PASS-EVIDENCED, limited scope** The supplied result says required checks pass. That does not override G1/G2 because Plugin Check covers many automated checks while manual policy surfaces still exist. ## PLUGIN CHECK TRIAGE **SUBMISSION-RELEVANT** None are reported as failed in the supplied output. **BEST-PRACTICE / OTHER** Not supplied. **Manual-review delta** License/business-model behavior and telemetry still require review even with a clean automated result. Conclusion: “Plugin Check passes” means the automated evidence is cleaner; it does not mean “ready for directory approval.” ## MONETIZATION & SERVICE BOUNDARY Current flow: free plugin ZIP → bundled Pro code exists locally → license server says valid/invalid → local code unlocks. That is materially different from: free connector plugin → paid external service actually performs substantive functionality → plugin displays/uses the service result. For this submission, the smallest defensible commercial redesign is to keep the WordPress.org plugin fully functional within its free scope and move premium implementation into either: 1. a separate paid add-on distributed outside WordPress.org; or 2. a genuine external service where the paid functionality is substantively performed by that service and the directory plugin is its interface. Do not manufacture a fake service merely to move code offsite. ## README & METADATA INTEGRITY **READ-ME SAYS** “Freemium.” **CODE DOES** Ships premium implementation locally and unlocks it by license validation. **REVIEW RISK** The term does not explain the actual boundary. **FIX** Describe the real free scope, any separate add-on or genuine external service, and all external connections. Telemetry: **READ-ME SAYS** Nothing. **CODE DOES** Sends site/runtime/plugin metadata on activation. **FIX** Do not merely add disclosure. First change the behavior so consent matches the current official rule, then document what is sent, why, when, and where. ## SUBMISSION VERDICT **DO NOT SUBMIT** Strongest blockers: 1. the supplied monetization architecture appears incompatible with the current directory trialware/service boundary; 2. telemetry is sent without evidenced opt-in consent. These should be redesigned before spending time polishing minor review warnings. ## REMEDIATION DELTA 1. Remove bundled paid-only implementation from the directory ZIP or redesign it as genuine serviceware. 2. Remove automatic activation telemetry. 3. Add explicit opt-in before optional metrics are sent, if metrics remain. 4. Update readme.txt so external services/data flows and the free/paid boundary match the actual code. 5. Re-run Plugin Check after the code split. 6. Re-run this manual policy map against the final ZIP. ## RECHECK PLAN Recheck: - current official trialware/serviceware guidance; - current tracking/consent guidance; - final ZIP contents; - every outbound HTTP call; - Plugin Check; - readme disclosure. No approval is guaranteed. The goal is to remove evidenced blockers before submission.