The Six-Day Guide

Everything you do, in order, from opening nine windows to having a citable dataset and two paper drafts. Written for the person running it, not the windows doing it.

Prepared 17 August 2026 Windows 9 parallel Scope 850 lemmas · 41,732 instances Prompts 54, pre-generated

Everything is built and tested. Day 0 is closed. 20 closure checks passed, an end-to-end simulation of a window completing a lemma passed 20 of 20, and the gate refuses 10 of 10 error types. Nine defects were found and fixed during preparation; six of them were in work already called finished.

How you run this: one word

The windows run autonomously. They never ask you anything. They do not stop to check in, do not ask permission, and do not summarise in their own window — because you are not reading those. They log every lemma as they finish it and write one closing line when the day is done.

You type status in your own window. That is the whole interface. You get every window, what it did, what it could not do, what went wrong, and whether the day is finished.

python 01-TOOLKIT\status.py           # today, all nine windows
python 01-TOOLKIT\status.py --day 3   # a particular day
python 01-TOOLKIT\status.py --full    # every day so far

What it shows you:

  WINDOW   STATE        LOGGED  ONDISK   SHARD   FLAGS   MIN/LEM
  win-1    DONE             23      23      93       4        21
  win-2    working          11      11      94       1        26
  win-3    STALLED           7       7      94       2        19  <<<

  FLAGS RAISED : thin=6, contested=3, hard=1
  PROBLEMS (2)
    - window 3 blocked on kAna - packet had no tafsir for 4 ayat
  ==>  DAY 2 NOT COMPLETE. 7 of 9 windows have reported done.

The single most important column is STATE.

You said that if a window stops you would assume the work was done. That assumption is only safe if a finished window says so. A window that finishes writes an end line and shows DONE. A window that crashed, stalled or was closed writes nothing — and appears as STALLED, in capitals, at the top of the report.

Without that distinction, silence and success look identical. Now they do not.

It also checks the windows against reality

LOGGED is what a window says it did. ONDISK is how many entry files actually exist. If they disagree, that is reported as a problem — the files are the truth, not the log.

Where everything lives

Path	What	Who writes it
`04-SENSE-LAYER\prompts\dayN\window-N.txt`	54 prompts, numbers already filled in	generated on day 0
`04-SENSE-LAYER\packets\<lemma>__rNNNN.txt`	850 packets — all the evidence for one word	built on day 0
`04-SENSE-LAYER\shards\shard-N.json`	which lemmas window N owns	built on day 0
`04-SENSE-LAYER\entries\window-N\`	THE DATASET. One JSON file per lemma	window N, and only window N
`04-SENSE-LAYER\logs\window-N\day-D.jsonl`	THE REPORT. One line per event	window N as it works
`04-SENSE-LAYER\entries\window-N\recheck\`	day 6 self-agreement work	window N on day 6
`04-SENSE-LAYER\entries\window-N\heldout\`	day 6 cross-window work	window N on day 6

Two directories per window, and they never overlap. Window 4 cannot write into window 3's entries or logs; nothing else writes into either. That is what makes nine parallel sessions safe, and what makes the day-6 agreement measurement meaningful.

Before you start: the one rule

Report what the commentators said. Never decide who is right.

Every entry may claim “N of M editions that gloss this word here render it X”. No entry may claim “this word means X”.

The first is a measurement any reader can check against the sources. The second is an act of scholarly authority. Keeping strictly to the first is what makes this publishable by someone without formal training — and it is simply what the method can establish.

The prompts are pre-generated. Do not edit them.

There are 54 prompt files, one per window per day. Each already carries its own window number and day number in the header, in every path and in every command.

04-SENSE-LAYER\prompts\
    INDEX.txt            what to paste where, in order
    day1\window-1.txt    day1\window-2.txt   ...  day1\window-9.txt
    day2\window-1.txt    ...
    ...  through day6

Why generated rather than templated. The earlier version said “change only the number” — 54 manual edits, each a chance to paste window 3's prompt into window 4. That failure is silent: window 4 writes into window 3's directory, both work the same shard, and the day-6 agreement check compares a window against itself. Nothing would refuse it, and the numbers would come out impossibly good.

Now every prompt opens with WINDOW 4 of 9 DAY 3 of 6 and the line “If this header does not say WINDOW 4, you have the wrong prompt.”

Day 1 — Calibration all nine on the same five words

What you do

Open nine windows. Paste prompts/day1/window-N.txt into window N. Check each header says the right number before you send it.
Let them work. Every window annotates the same five lemmas: maqām, umma, dīn, rūḥ, khalīfa — chosen because each carries more than one reading in the tradition, so a window that flattens them shows itself immediately.
When all nine report, compare their answers on the same five words.
Compute cross-window agreement: of all pairs of windows, on how many lemmas did they produce the same number of senses and the same assignment?
Read every “anything ambiguous?” report. This matters more today than the lemmas do.

The day-1 decision, and it is not optional.

Agreement 70% or better → proceed to day 2.

Below 70% → do not proceed. The rule is ambiguous, not the annotators. Find what they read differently, amend the wording once centrally, regenerate the prompts, and run day 1 again.

Losing a day here is the cheapest thing you will ever buy. The same disagreement found on day 6 costs the week and the paper.

Days 2–5 — Production each window on its own shard

Each window has 93–94 lemmas and about 30 hours of work, balanced to within 0.7% of each other. Target is roughly 23 lemmas per window per day.

What you do each day

Paste prompts/dayN/window-N.txt into each window.
Let them work. The loop is: packet.py --next → read → write one JSON file → audit_entries.py.
Check overall progress:
```
python 01-TOOLKIT\progress.py all
```
Review only the flagged entries, not all of them. Flags are thin, weak, contested, verse-only, hard, miqbas-present.
Where you overturn a window's judgement, log it with the reason. That log becomes the reliability section of the paper.
At the end of the day, commit everything yourself:
```
git add -A
git commit -m "day N: nine windows"
```
The windows never run git — nine of them share one .git/index.lock and would collide.

The day-4 checkpoint. If fewer than 40% of lemmas are done by the end of day 4, cut scope now and write the cut into SCOPE.md. Do not wait for day 6 and do not solve it by accepting weaker evidence. A smaller honest dataset is publishable; a complete guessed one is worthless in a way nobody outside can detect.

Day 6 — Independence check the day that decides publishability

No production today. Today measures whether the dataset is reliable.

Paste prompts/day6/window-N.txt. Each window does two things.
Part A — each window re-annotates the first 5 lemmas it did on day 2, without opening its previous answers. Output goes to entries/window-N/recheck/.
Part B — every window annotates the same five held-out lemmas nobody has touched: āya, sabīl, ḥaqq, nafs, ākhir. Output to entries/window-N/heldout/.
Compute self-agreement: how often a window reproduced its own day-2 answer.
Compute cross-window agreement on the held-out five.
Merge all nine directories. Any duplicate ID is a tooling bug, not a data decision.
Run the clean-room recount — recompute every n_glossing from the corpus, sharing no code with the annotation tools.

Publish both figures whatever they are. A resource with a stated agreement rate is usable; one without is not trusted. If a window's self-agreement is under 60%, its entries are re-reviewed before release. If cross-window agreement is under 70%, say so in the paper — it is a finding about how hard the task is, not a shameful number.

A rate that has been tidied up is a lie. The windows are instructed never to quietly correct a day-2 answer, and neither should you.

Day 7 — Release deposit and draft

Validate the merged dataset: every entry schema-valid, every n_agree ≤ n_glossing, every quote traceable.
Hand-check 40 random entries against the tafsīr yourself. Publish the sample error rate. Above 5%, stop and fix.
Produce JSON and tab-separated forms.
Write README, SCHEMA, LIMITATIONS. The last carries the flags, the contested entries and both agreement rates.
Licence CC BY 4.0 on the annotation. Credit the Quranic Arabic Corpus, Tanzil and every tafsīr source prominently.
Deposit on Zenodo, mint a DOI, tag v1.0.0, include the tooling.
Draft Paper A — the resource — for LREC or the Journal of Open Humanities Data.
Draft Paper B — the disagreements — for the Journal of Digital Islamicate Research. It exists only because minority readings were kept.
Re-run the literature search the morning you submit.

What success looks like

Eight tests, every one measured by a script rather than by opinion. All eight must hold.

#	Test	Threshold	How
1	Lemmas completed	≥ 700 / 850	`progress.py all`
2	Entries failing the gate at release	0	`audit_entries.py all`
3	Quotations traceable to the corpus	100%	clean-room checker
4	Cross-window agreement, held-out set	≥ 70%	day 6
5	Self-agreement	≥ 80%	day 6
6	Hand-checked sample error rate	≤ 5%	you, 40 entries
7	DOI minted, tooling included	yes	Zenodo
8	Every figure published, including the bad ones	yes	the papers

Being right is deliberately not on that list. Nobody can verify it from inside the project, and claiming it would need an ijāzah. What can be verified is that the method was applied consistently, that the evidence supports every claim, and that annotators agreed at a stated rate.

Partial success is still success

700+

full success

500–699

reduced scope, publishable

300–499

a paper, narrower claim

<300

stop, do not publish

What you will have on the evening of day 7

Artefact	What it is
The dataset	One entry per lemma-sense for up to 850 words, on Zenodo with a DOI, CC BY 4.0
The evidence	Verbatim quotations from every commentary that glosses each word, with edition, death date, language
The disagreements	Every contested word — the raw material of Paper B
The reliability figures	Cross-window agreement, self-agreement, sample error rate
The tooling	Every script, so anyone can rebuild the dataset from the corpus
Two paper drafts	The resource, and the disagreements
The v2 roadmap	What was cut, what was deferred, and the scholar review required before any of it is called a tafsīr

The three failures, and how you will know

Failure	Detected by	Response
Not enough done — under 300 lemmas by day 6	`progress.py all`, daily	Stop on day 6, publish nothing, reschedule smaller. Recoverable
Windows disagree — under 70% cross-window	Day 1, confirmed day 6	The rule is ambiguous. Rewrite, regenerate prompts, re-run day 1
The dataset says what the evidence does not support	The gate; the hand-checked sample	Do not publish. A resource that misrepresents the tradition is a negative contribution, not a smaller one

Commands you will actually use

# overall progress across all nine windows
python 01-TOOLKIT\progress.py all

# one window in detail - what is next, and pace
python 01-TOOLKIT\progress.py window-3

# validate everything before release
python 01-TOOLKIT\audit_entries.py all --summary

# end of day, once, for all nine
git add -A && git commit -m "day N"

One limitation to carry into the paper. Fourteen lemmas have under 50% āyah coverage, and for a few — such as makka from م-ك-ن — no skeleton match can ever work, because derived forms insert letters between the radicals. Those windows will see translations only and must flag verse-only. This is a property of the method, and it belongs in the limitations section rather than being quietly smoothed over.