documents: brief: extractor.md
Data license: Not yet licensed — internal review only · Data source: Ahmed ElBatanony, Innopolis University
This data as json
| name | text |
|---|---|
| brief: extractor.md | # Extractor brief (pub-10 main run, v1.1, 21.10.2026) You are extraction run **{RUN}** (a or b). Another model instance performs the other run independently. **Do not open, read or list any `extract-*.json` file other than the one you write.** Blindness between the two runs is part of the study design. Working directory: `/home/bat/dev/phd`. For each application id you are given: 1. Read `data/business-apps/run/<id>/app.json` (product name) and `data/business-apps/run/<id>/manifest.json` (which archived file came from which URL). 2. Read **every** archived source file `data/business-apps/sources/<id>/*.txt` in full. These are the only evidence. Do not use the web or your own knowledge of the product. 3. Apply the fixed extraction instructions below to the whole source set of the application. 4. Write the result to `data/business-apps/run/<id>/extract-{RUN}.json` with the Write tool. `sourceUrl` is the URL from the manifest for the file the excerpt came from. Every statement must begin with exactly `The system lets ` or `The system automatically `; the script drops any other form. Rules and constraints the system enforces are automations: write them as "The system automatically prevents … when …". Excerpts must be copied **character for character** from the source file (a script checks this; any mismatch drops the statement). Keep excerpts short: the shortest contiguous span that supports the statement, usually one sentence or list item. ## Fixed extraction instructions (extraction-protocol.md §3, verbatim) ``` You extract FEATURE STATEMENTS from software documentation for a research dataset. A feature statement describes ONE capability of the application, in one of two forms: "The system lets <actor> <action> <object> [<condition>]" — something a user does "The system automatically <action> <object> when <event>" — an automation Rules: 1. One capability per statement. Split "create, send and track quotes" into three. 2. Keep conditions — "approve invoices above a threshold" keeps "above a threshold". 3. The actor is a role ("a manager", "a customer"); use "a user" if none is stated. 4. Drop marketing words (fast, beautiful, powerful, seamless). 5. Name the KIND of integration, not the vendor: "exchange accounting records with an external accounting system", not "sync with QuickBooks". 6. Record each capability ONCE per application, even if the source repeats it. 7. Never infer beyond the excerpt. Every statement must be directly supported by the excerpt you quote, copied EXACTLY from the source. 8. Do NOT write statements for: qualities, compliance claims, deployment or hosting, pricing or plans, social proof, TESTIMONIALS OR CUSTOMER STORIES, claims about a platform the app is built on, or IT-infrastructure administration no business role uses. List those excerpts under "skipped" with a reason. User-facing sign-in features (two-factor, single sign-on) ARE capabilities. Return JSON only: {"features":[{"statement":"...","excerpt":"<verbatim source text>","sourceUrl":"..."}], "skipped":[{"excerpt":"...","reason":"quality|compliance|deployment|pricing|social-proof|testimonial|platform|other"}]} ``` If an application has no archived sources, write `{"features":[],"skipped":[],"note":"no sources"}`. Final answer: one line per application, `<id> <features> <skipped>`. Nothing else. <!-- v1.1 (21.10.2026, after the 3-app trial, before the main batches): added the form reminder above; the fixed instructions are unchanged. --> |