# Package workflow ## Task and place Task: carry one act from raw source to a released, revisitable canon package. Place: this page is the map every role shares; later pages detail single stages. The pipeline runs preliminary scope, source, confirmed scope, model, package, scenarios, reviews, release, revisit — in that order, with loops back whenever a later stage exposes an earlier gap. Scope passes twice by design: a preliminary card from the first reading fixes the question before anything is pinned, and the confirmation pass after the source stage turns whole-article lines into branch-level fates. ## Inputs - A source pointer: where the act text lives and which edition counts. - A scope question: which articles and which case categories the package answers. - A working `law` tool and an empty package directory. - For the maintainer lane: write access to the shared canon and a reviewer. ## Actions Each stage lists what it receives, what it produces, and the check that lets work move on. - Scope, preliminary — Receives the act pointer and the question. Produces a preliminary card: question, candidate case categories, candidate provisions. Move on when the question fits in one sentence. - Source — Receives the act pointer. Produces pinned fragments with hashes plus a source inventory. Move on when every fragment used later is pinned and its hash verifies. - Scope, confirmed — Receives pinned fragments plus the preliminary card. Produces the confirmed card at branch granularity, with explicit exclusions for every branch the preliminary card implied but the model will not cover. Move on when the card states what is out as clearly as what is in. - Model — Receives the scope card. Produces rules with source links and a decision record for each modeling choice. Move on when every in-scope provision has a rule and every choice has a record. - Package — Receives rules and metadata. Produces a declared package: name, version, language, imports. Move on when the static check reports OK. - Scenarios — Receives the declared package. Produces tests with expected answers fixed before the run. Move on when every in-scope provision has at least one scenario and every expectation carries a reason. - Reviews — Receives package plus scenarios. Produces a review record with findings. Move on when every finding is resolved or deferred with a record. - Release — Receives the reviewed package. Produces a versioned release with notes. Move on when the release notes state scope, sources, and known limits. - Revisit — Receives change signals such as an amended act or a new finding. Produces an updated scope card and a new version, or a written decision to stay. This stage never closes; it loops back to source. Gap handling: a gap found late reopens the earliest stage it touches. A missing fragment reopens source, not review. An unclear boundary reopens scope, not modeling. A failing scenario reopens modeling or the expectation — never silently edits the expectation to match the run; the reason goes into the scenario or a decision record. A review finding reopens the stage it names. Record each loop in one line on the affected record. Lanes: the solo lane runs all stages with light records — scope card, short decision notes, self-review against the review record shape. The maintainer lane adds full records at every stage and requires independent review before release. Same stages, same order; only the record weight differs. ## Decisions - Lane choice: solo draft or shared canon. Shared canon always takes the maintainer lane. - Scope breadth: fixed at the scope stage; widening later reopens scope. - Modeling choices with reasons: tariff shape, boundary reading, rounding policy — each gets a decision record at the model stage. - Finding outcomes: fix now or defer with a record — decided at review, never by silence. ## Artifact The pipeline hands over the release bundle named on the landing page: scope card, pinned sources, rule sources, scenarios, decision records, review record, release notes. The workflow stage adds no separate file; its trace is the filled records with their loop notes. ## EAI example The employee accident insurance package walked this pipeline end to end. [Source snapshot]: four articles were pinned to edition EAI_EDITION with materialization PINNED_UNOFFICIAL_COPY — an Adilet API copy retrieved 2026-09-13, sha256 pinned, local copy kept in the package. The scope card covers the employer duty, tariff with premium, payout eligibility, and late penalty. The model holds strict tariff rules from class 1 at 0.12 percent to class 22 at 0.0296, premium as payroll times rate, payout for loss from 30 through 100 percent, penalty as unpaid times 0.015 times days. Decisions EAI-D1 (tariff as strict rules), EAI-D2 (inclusive thirty boundary), and EAI-D3 (penalty with no rounding policy) were recorded at the model stage; finding EAI-R1 was recorded at review. The static check reports OK and the scenario run passes seven of seven: loss thirty established while loss twenty-nine stays undecided, class 22 premium of 29600 KZT on a payroll of one million, penalty of 3000 KZT on one hundred thousand unpaid for two days. [Accepted candidate]: the same pipeline plus the R1 employer branch and the R3 premium re-grounding — five articles touched, decision EAI-D4 recorded, thirty-seven of thirty-seven passing. ## Pitfall Editing an expectation to match a surprising run. A failing scenario teaches either a model error or a wrong expectation; changing the expected answer without a reason erases the lesson and the scenario becomes decoration. Fix the model or justify the new expectation in writing. ## Verify Run the two checks below with the `law` tool (version 0.1.0, semantics law.core/0.2) against the package directory: ```sh $ law engine check corpus/laws/kz/laws/employee-accident-insurance check OK: corpus/laws/kz/laws/employee-accident-insurance ``` ```sh $ law test corpus/laws/kz/laws/employee-accident-insurance law test kz.corpus.employee_accident_insurance: [...] kz.corpus.employee_accident_insurance ok [kz.corpus.employee_accident_insurance#authored] tests/core.lawtest / EAI-EMPLOYER-MUST-INSURE ok [kz.corpus.employee_accident_insurance#authored] tests/core.lawtest / EAI-MINING-CLASS-22-PREMIUM ok [kz.corpus.employee_accident_insurance#authored] tests/core.lawtest / EAI-LOSS-THIRTY-QUALIFIES ok [kz.corpus.employee_accident_insurance#authored] tests/core.lawtest / EAI-LOSS-TWENTY-NINE-IS-NOT-INSURER-PAYOUT ok [kz.corpus.employee_accident_insurance#authored] tests/core.lawtest / EAI-SPECIAL-LATE-PAYMENT-PENALTY ok [kz.corpus.employee_accident_insurance#authored] tests/goals.lawtest / GoalEstablishedCapacityLossHasPayout-world ok [kz.corpus.employee_accident_insurance#authored] tests/goals.lawtest / urn:kz:corpus:clir:employee-accident-insurance#GoalEstablishedCapacityLossHasPayout [...] totals line in locale language: 7 checked, 7 passed, 0 failed, 0 unexecuted ``` Both runs above were executed for this page; `[...]` marks elided locale-language words, and the counts stated match the run. Criterion: the static check reports OK and the scenario run reports seven checked, seven passed, zero failed. A package that fails either check has not left its stage — the static check belongs to the package stage, the scenario run to the scenarios stage. ## Limits The pipeline fits one act in one package. It does not cover multi-act bridges, corpus-wide migrations, or disputes about what the act means — those rise to maintainer review and, when needed, outside legal counsel. Time-boxed drafts may stop after scenarios, but they must not release as canon. ## Next step Continue with [Scope card](/handbook/scope/), which fixes what your package covers before any rule is written. ## Sources - [Vocabulary](/constructs/vocabulary/) - [Real article source](/tutorials/real-article-source/) - [Four states of support](/tutorials/four-states/) - [Language](/language/) - [Fact protocol](/protocols/fact-protocol/) - [Decision protocol](/protocols/decision-protocol/) - [Reading an answer](/guide/reading-an-answer/) - [Diagnostics](/diagnostics/)