documents: verification-prompt.md

The exact instructions every agent role received (briefs), the verification prompt, the extraction protocol, screening criteria and the release datasheet.

Data license: Not yet licensed — internal review only · Data source: Ahmed ElBatanony, Innopolis University

This data as json

name	text
verification-prompt.md	# pub-10 verifier instructions (fixed; v1.1, 17.10.2026) You 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. ## What a valid feature statement is One user-observable capability of the application, in one of two forms: - "The system lets ⟨actor⟩ ⟨action⟩ ⟨object⟩ [⟨condition⟩]", for something a user does; - "The system automatically ⟨action⟩ ⟨object⟩ when ⟨event⟩", for an automation. Rules: 1. One capability per statement. 2. Conditions in the source are kept. 3. The actor is a role; "a user" if none is stated. 4. No marketing words. 5. Integrations name the kind of exchange, not the vendor. 6. The statement must be directly supported by the excerpt, and the excerpt must be about this application. Not capabilities (reject if stated as one): - qualities (fast, secure, easy); - compliance claims, deployment or hosting, pricing and plans; - social proof; - claims about a platform the app is built on; - IT-infrastructure administration that no business role uses; - 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. Are capabilities: user-facing sign-in and access features (two-factor authentication, single sign-on, social login). Do not reject these as "security measures". Record each capability once per application: if two statements say the same thing, reject the later one with reason "duplicate of <id>". ## Your task For every statement, return: - `verdict`: - `confirmed`: supported and well formed; - `corrected`: supported but badly formed, so give `corrected` (the fixed statement). Use this when a user-action statement describes an automation, or vice versa; - `rejected`: not supported, not a capability, or testimonial evidence only; - `reason`: one short sentence, required for `corrected` and `rejected`. Then 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. ## Output JSON only, exactly this shape: ```json {"verdicts":[{"id":"F1-P01-001","verdict":"confirmed"}, {"id":"F1-P01-002","verdict":"corrected","corrected":"The system …","reason":"…"}, {"id":"F1-P01-003","verdict":"rejected","reason":"…"}], "missed":[{"appId":"F1-P01","statement":"The system …","excerpt":"<verbatim>"}]} ``` Every input statement id must appear exactly once in `verdicts`.

name

text

verification-prompt.md

# pub-10 verifier instructions (fixed; v1.1, 17.10.2026) You 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. ## What a valid feature statement is One user-observable **capability** of the application, in one of two forms: - *"The system lets ⟨actor⟩ ⟨action⟩ ⟨object⟩ [⟨condition⟩]"*, for something a user does; - *"The system automatically ⟨action⟩ ⟨object⟩ when ⟨event⟩"*, for an automation. Rules: 1. **One** capability per statement. 2. Conditions in the source are kept. 3. The actor is a role; "a user" if none is stated. 4. No marketing words. 5. Integrations name the **kind** of exchange, not the vendor. 6. The statement must be **directly supported by the excerpt**, and the excerpt must be about **this** application. **Not capabilities** (reject if stated as one): - qualities (fast, secure, easy); - compliance claims, deployment or hosting, pricing and plans; - social proof; - claims about a platform the app is built on; - IT-infrastructure administration that no business role uses; - **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. **Are** capabilities: user-facing sign-in and access features (two-factor authentication, single sign-on, social login). Do not reject these as "security measures". Record each capability once per application: if two statements say the same thing, reject the later one with reason "duplicate of <id>". ## Your task For every statement, return: - `verdict`: - `confirmed`: supported and well formed; - `corrected`: supported but badly formed, so give `corrected` (the fixed statement). Use this when a user-action statement describes an automation, or vice versa; - `rejected`: not supported, not a capability, or testimonial evidence only; - `reason`: one short sentence, required for `corrected` and `rejected`. Then 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. ## Output JSON only, exactly this shape: ```json {"verdicts":[{"id":"F1-P01-001","verdict":"confirmed"}, {"id":"F1-P01-002","verdict":"corrected","corrected":"The system …","reason":"…"}, {"id":"F1-P01-003","verdict":"rejected","reason":"…"}], "missed":[{"appId":"F1-P01","statement":"The system …","excerpt":"<verbatim>"}]} ``` Every input statement id must appear exactly once in `verdicts`.