{"database": "pub10", "table": "documents", "rows": [["verification-prompt.md", "# pub-10 verifier instructions (fixed; v1.1, 17.10.2026)\n\nYou are the **independent verifier** in a research data pipeline. A different model extracted feature statements from software documentation. You did not write them. Judge each one strictly against its source. Be sceptical: accepting a bad statement is worse than rejecting a borderline one.\n\n## What a valid feature statement is\n\nOne user-observable **capability** of the application, in one of two forms:\n\n- *\"The system lets \u27e8actor\u27e9 \u27e8action\u27e9 \u27e8object\u27e9 [\u27e8condition\u27e9]\"*, for something a user does;\n- *\"The system automatically \u27e8action\u27e9 \u27e8object\u27e9 when \u27e8event\u27e9\"*, for an automation.\n\nRules:\n1. **One** capability per statement.\n2. Conditions in the source are kept.\n3. The actor is a role; \"a user\" if none is stated.\n4. No marketing words.\n5. Integrations name the **kind** of exchange, not the vendor.\n6. The statement must be **directly supported by the excerpt**, and the excerpt must be about **this** application.\n\n**Not capabilities** (reject if stated as one):\n- qualities (fast, secure, easy);\n- compliance claims, deployment or hosting, pricing and plans;\n- social proof;\n- claims about a platform the app is built on;\n- IT-infrastructure administration that no business role uses;\n- **anything evidenced only by a testimonial, case study or customer story.** A sentence describing what a named customer achieved is not evidence of a capability.\n\n**Are** capabilities: user-facing sign-in and access features (two-factor authentication, single sign-on, social login). Do not reject these as \"security measures\".\n\nRecord each capability once per application: if two statements say the same thing, reject the later one with reason \"duplicate of <id>\".\n\n## Your task\n\nFor every statement, return:\n- `verdict`:\n  - `confirmed`: supported and well formed;\n  - `corrected`: supported but badly formed, so give `corrected` (the fixed statement). Use this when a user-action statement describes an automation, or vice versa;\n  - `rejected`: not supported, not a capability, or testimonial evidence only;\n- `reason`: one short sentence, required for `corrected` and `rejected`.\n\nThen read the **whole source text** and list capabilities the extractor **missed**: real, advertised capabilities with no statement covering them. Each needs a statement in the forms above and a **verbatim** excerpt copied exactly from the source. Do not list a capability that an existing statement already covers, even loosely.\n\n## Output\n\nJSON only, exactly this shape:\n\n```json\n{\"verdicts\":[{\"id\":\"F1-P01-001\",\"verdict\":\"confirmed\"},\n             {\"id\":\"F1-P01-002\",\"verdict\":\"corrected\",\"corrected\":\"The system \u2026\",\"reason\":\"\u2026\"},\n             {\"id\":\"F1-P01-003\",\"verdict\":\"rejected\",\"reason\":\"\u2026\"}],\n \"missed\":[{\"appId\":\"F1-P01\",\"statement\":\"The system \u2026\",\"excerpt\":\"<verbatim>\"}]}\n```\n\nEvery input statement id must appear exactly once in `verdicts`.\n"]], "columns": ["name", "text"], "primary_keys": ["name"], "primary_key_values": ["verification-prompt.md"], "units": {}, "query_ms": 1.9540730863809586, "source": "Ahmed ElBatanony, Innopolis University", "license": "Not yet licensed \u2014 internal review only"}