documents: brief: adjudicator.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
brief: adjudicator.md	# Adjudicator brief (pub-10 main run, v1.2, 27.10.2026) You are the adjudicator (extraction-protocol.md §2). An independent verifier has judged statements that two blind extraction runs produced. You rule on every item where the verifier did not simply confirm, and on every missed capability it proposed. Working directory: `/home/bat/dev/phd`. For each application id you are given, read: - `data/business-apps/verification-prompt.md` — the rules both the verifier and you apply; - `data/business-apps/run/<id>/adjudication-input.json` — everything you rule on, prepared by script: `items` (non-confirmed verdicts other than duplicates, with statement, excerpt, the verifier's correction and reason), `duplicates` (each rejected statement next to the statement it duplicates), `missed` (the verifier's proposed additions; `verbatimFound` says whether the script found the excerpt in the sources), `confirmedStatements` (the surviving statements, to judge whether a missed item is already covered). Open a source file (`data/business-apps/sources/<id>/<sourceFile>`) only when an excerpt's surrounding context is needed to decide; use `grep -n` around the excerpt rather than reading whole files. Do not read `candidates.json` or `verify.json`. Rules for rulings: - For each verdict `corrected` or `rejected`: decide `final` = `confirmed`, `corrected` or `rejected`. If `corrected`, give the final `statement` (usually the verifier's correction). Give a one-sentence `reason`. Duplicates: confirm the rejection when the two statements describe the same capability; overturn it when they describe different capabilities. - For each missed item: `accepted` true or false with a `reason`. Accept only if it is a real capability, supported by its excerpt, not already covered by a surviving statement, and `verbatimFound` is true. Copy its `statement` (or your corrected statement) and `excerpt` into your output entry. - You may add a capability that both runs and the verifier missed, only if it is clearly advertised; give `foundBy: "adjudicator"`, a statement in one of the two forms and a verbatim excerpt. - If you genuinely cannot decide, put the item in `undecidable` with the question for the human owner. Use this sparingly. - Be consistent with these standing rulings: user-facing sign-in features are capabilities; testimonial-only evidence never counts; claims about an underlying platform are not capabilities of the app; marketing qualities are not capabilities. Write `data/business-apps/run/<id>/adjudication.json` with the Write tool, exactly this shape: ```json {"appId":"F1-001", "rulings":[{"id":"F1-001-A003","verifierVerdict":"rejected","final":"rejected","reason":"…"}, {"id":"F1-001-B010","verifierVerdict":"corrected","final":"corrected","statement":"The system …","reason":"…"}], "missed":[{"statement":"The system …","excerpt":"<verbatim>","accepted":true,"foundBy":"verifier","reason":"…"}], "duplicatesUpheld":["F1-001-B004"], "undecidable":[]} ``` Duplicates: most rejections are `duplicate of <id>` because two runs extracted the same capability. Check each pair; list every duplicate rejection you uphold in `"duplicatesUpheld":["<id>", …]` instead of writing a ruling for it. Write a ruling only for duplicates you overturn and for all other non-confirmed verdicts. Every non-confirmed verdict must appear exactly once, either in `rulings` or in `duplicatesUpheld`. Do not include confirmed statements. Final answer: one line per application, `<id> rulings=<n> overturned=<n> missed_accepted=<n>/<m> undecidable=<n>`. Nothing else. <!-- v1.2 (27.10.2026): reads the script-prepared adjudication-input.json instead of whole sources, to cut cost (protocol v1.5). -->

name

text

brief: adjudicator.md

# Adjudicator brief (pub-10 main run, v1.2, 27.10.2026) You are the adjudicator (extraction-protocol.md §2). An independent verifier has judged statements that two blind extraction runs produced. You rule on every item where the verifier did **not** simply confirm, and on every missed capability it proposed. Working directory: `/home/bat/dev/phd`. For each application id you are given, read: - `data/business-apps/verification-prompt.md` — the rules both the verifier and you apply; - `data/business-apps/run/<id>/adjudication-input.json` — everything you rule on, prepared by script: `items` (non-confirmed verdicts other than duplicates, with statement, excerpt, the verifier's correction and reason), `duplicates` (each rejected statement next to the statement it duplicates), `missed` (the verifier's proposed additions; `verbatimFound` says whether the script found the excerpt in the sources), `confirmedStatements` (the surviving statements, to judge whether a missed item is already covered). Open a source file (`data/business-apps/sources/<id>/<sourceFile>`) only when an excerpt's surrounding context is needed to decide; use `grep -n` around the excerpt rather than reading whole files. Do not read `candidates.json` or `verify.json`. Rules for rulings: - For each verdict `corrected` or `rejected`: decide `final` = `confirmed`, `corrected` or `rejected`. If `corrected`, give the final `statement` (usually the verifier's correction). Give a one-sentence `reason`. Duplicates: confirm the rejection when the two statements describe the same capability; overturn it when they describe different capabilities. - For each missed item: `accepted` true or false with a `reason`. Accept only if it is a real capability, supported by its excerpt, not already covered by a surviving statement, and `verbatimFound` is true. Copy its `statement` (or your corrected statement) and `excerpt` into your output entry. - You may add a capability that **both** runs and the verifier missed, only if it is clearly advertised; give `foundBy: "adjudicator"`, a statement in one of the two forms and a verbatim excerpt. - If you genuinely cannot decide, put the item in `undecidable` with the question for the human owner. Use this sparingly. - Be consistent with these standing rulings: user-facing sign-in features are capabilities; testimonial-only evidence never counts; claims about an underlying platform are not capabilities of the app; marketing qualities are not capabilities. Write `data/business-apps/run/<id>/adjudication.json` with the Write tool, exactly this shape: ```json {"appId":"F1-001", "rulings":[{"id":"F1-001-A003","verifierVerdict":"rejected","final":"rejected","reason":"…"}, {"id":"F1-001-B010","verifierVerdict":"corrected","final":"corrected","statement":"The system …","reason":"…"}], "missed":[{"statement":"The system …","excerpt":"<verbatim>","accepted":true,"foundBy":"verifier","reason":"…"}], "duplicatesUpheld":["F1-001-B004"], "undecidable":[]} ``` Duplicates: most rejections are `duplicate of <id>` because two runs extracted the same capability. Check each pair; list every duplicate rejection you **uphold** in `"duplicatesUpheld":["<id>", …]` instead of writing a ruling for it. Write a ruling only for duplicates you overturn and for all other non-confirmed verdicts. Every non-confirmed verdict must appear exactly once, either in `rulings` or in `duplicatesUpheld`. Do not include confirmed statements. Final answer: one line per application, `<id> rulings=<n> overturned=<n> missed_accepted=<n>/<m> undecidable=<n>`. Nothing else.