Activities - Assess the Iteration

#	Name	Abbrev.	Guidance	Actions
Construction 6
1	Open an Assessment Run	AIN-1	Objective Create one traceable, immutable assessment snapshot without interfering with delivery work. Required inputs Project …	Read the 'AIN-1 Open an Assessment Run' activity from playbook 'Junior Edda' (workflow 'Assess the Iteration'). Follow its guidance when assisting me. ## Objective Create one traceable, immutable assessment snapshot without interfering with delivery work. ## Required inputs - Project Charter and Delivery Management Assignment. - Huginn Assessment Contract. - Project/repository/environment identity and the current iteration ID when one exists. ## Procedure 1. Validate that every tracked Charter variable has a stable `variable_id`, source, exact query/command, window, freshness limit, bands, Unknown behavior, owner, and gating policy. 2. Acquire the project assessment lock. If another run is active, return its run ID or wait according to the Huginn contract; never create overlapping side effects. 3. Create `run_id = AIN-<UTC timestamp>` and directory `docs/project/assessments/<run_id>/`. 4. Establish one snapshot boundary: repository revision, environment, iteration ID, source-system timestamps/cursors, Charter version, and artifact inventory timestamp. 5. Write `RUN.md` with trigger, initiator, timestamps, inputs, snapshot identifiers, expected outputs, lock state, and status `running`. 6. Freeze the snapshot for this run. Later source changes belong to the next run. ## Safety This activity is read-only except for the Assessment Run Record and lock. It does not modify the delivery manifest, code, Charter, tickets, or deployment. ## Completion evidence A unique run directory and record exist; input versions and snapshot boundary are reproducible; one-run-at-a-time behavior is demonstrated; and downstream activities can reference the same run ID.
2	Assess Charter Variables	AIN-2	Objective Measure every Charter variable from the run snapshot and produce evidence; do not create …	Read the 'AIN-2 Assess Charter Variables' activity from playbook 'Junior Edda' (workflow 'Assess the Iteration'). Follow its guidance when assisting me. ## Objective Measure every Charter variable from the run snapshot and produce evidence; do not create or update tickets here. ## Procedure 1. Read the variable contracts from the Charter version recorded in `RUN.md`. 2. If the ADE supports parallel workers, fan out one bounded worker per variable (or per non-overlapping source batch). Every worker is read-only and writes only `variables/<variable_id>.json`; no two workers share an output file or ticket key. 3. For each variable execute the exact declared query/command and record: - `variable_id`, definition, unit, source, query/command, window; - raw result or bounded evidence reference; - observed timestamp and source timestamp; - freshness and validation result; - current value; - prior and current band: `Green \| Yellow \| Orange \| Red \| Unknown`; - threshold calculation and owner; - measurement error, if any. 4. Missing, stale, inaccessible, malformed, or non-reproducible evidence is `Unknown`, never Green. Apply the Charter's declared Unknown policy without inventing a value. 5. After all workers finish, validate schema and coverage and produce `VARIABLE_RESULTS.json` sorted by stable variable ID. ## Completion evidence There is exactly one valid result per Charter variable; all results use the same run ID/snapshot; failures are explicit Unknowns; raw provenance is retained; and no ticket or delivery state was mutated.
3	Reconcile Risk and Problem Tickets	AIN-3	Objective Apply the measured variable results to a stable, idempotent Risk/Problem ticket lifecycle. Procedure Load …	Read the 'AIN-3 Reconcile Risk and Problem Tickets' activity from playbook 'Junior Edda' (workflow 'Assess the Iteration'). Follow its guidance when assisting me. ## Objective Apply the measured variable results to a stable, idempotent Risk/Problem ticket lifecycle. ## Procedure 1. Load `VARIABLE_RESULTS.json` and the configured GH/Jira adapter. 2. For each variable derive `concern_key = <project_id>:<variable_id>`. 3. Fan out read-only ticket lookup if useful, then serialize all creates/updates/closes per `concern_key`. Never let two workers mutate the same concern. 4. Apply this state machine: - Green with no open concern: no action. - Yellow/Orange: create or update one Risk ticket. - Red: create or update one Problem ticket; convert the same concern when the adapter supports type change, otherwise link/close the old representation atomically. - Unknown: never close or green a concern. Create/update the same concern as a measurement-health Risk unless the Charter declares a stricter treatment. - Return to Green: resolve the open concern only with fresh Green evidence. 5. On Yellow↔Orange, band changes, new evidence, changed severity, or gating-policy changes, update the existing ticket even when its type does not change. 6. Use `<run_id>:<variable_id>` as the idempotency key. Retry must yield the same ticket and action record. 7. Emit `TICKET_ACTIONS.json` with prior/new state, action, ticket ID/URL, evidence, gating policy, and errors. ## Failure handling A ticket-adapter failure does not erase the measurement. Mark the action failed, keep the run incomplete, and retry idempotently. Never create a substitute duplicate. ## Completion evidence Every non-Green/Unknown variable has exactly one stable concern; lifecycle changes reflect evidence; gating signals are explicit; and a repeated run/retry creates no duplicate ticket.
4	Measure Delivery Throughput	AIN-4	Objective Measure accepted delivery flow from the same assessment snapshot independently of variable assessment and …	Read the 'AIN-4 Measure Delivery Throughput' activity from playbook 'Junior Edda' (workflow 'Assess the Iteration'). Follow its guidance when assisting me. ## Objective Measure accepted delivery flow from the same assessment snapshot independently of variable assessment and ticket mutation. ## Procedure 1. Use the iteration ID, repository revision, and source cursors from `RUN.md`. 2. Read the authoritative delivery records declared in the Huginn contract (for example accepted scenario issues, merged changes, releases, and acceptance checks). 3. Count completed accepted items in the declared cadence/window. Also record cycle time and work-in-progress when the source supports them. 4. Story points are optional and must not replace item throughput unless the Charter explicitly defines their source and use. 5. Exclude reopened, rejected, duplicate, or unaccepted work and record the exclusion reason. 6. Write `THROUGHPUT.json` with window, sources/queries, counts, item IDs, exclusions, cycle-time summary, WIP, freshness, and errors. ## Completion evidence The result is reproducible from named records, uses the run snapshot and cadence window, distinguishes accepted work from activity volume, and expresses missing/stale data as Unknown rather than zero.
5	Assess Required-Artifact Coverage	AIN-5	Objective Verify the existence, validity, ownership, and freshness of every artifact the Charter marks required. …	Read the 'AIN-5 Assess Required-Artifact Coverage' activity from playbook 'Junior Edda' (workflow 'Assess the Iteration'). Follow its guidance when assisting me. ## Objective Verify the existence, validity, ownership, and freshness of every artifact the Charter marks required. ## Procedure 1. Read the required-artifact table from the Charter version in `RUN.md`. 2. If the ADE supports parallel workers, fan out one read-only worker per artifact. Each writes only `artifacts/<artifact_id>.json`. 3. For each artifact check its declared canonical path/system, validation command or schema, owner, version, freshness rule, and expected producer. 4. Record `present \| missing \| stale \| invalid \| inaccessible`; never infer coverage from a similarly named file. 5. Converge results into `ARTIFACT_COVERAGE.json` with covered/required counts, percentage when meaningful, missing/invalid list, evidence locations, and errors. 6. Do not create missing artifacts in this workflow; route remediation to RIN/backlog or a Project-Management Ticket according to Charter policy. ## Completion evidence Every required artifact has one evidence-backed status from the shared snapshot; validation was executed where declared; gaps have owners or routing; and coverage is not overstated.
6	Converge Assessment & Publish Report	AIN-6	Objective Join all assessment branches, publish one complete supervisory verdict, and release the project assessment …	Read the 'AIN-6 Converge Assessment & Publish Report' activity from playbook 'Junior Edda' (workflow 'Assess the Iteration'). Follow its guidance when assisting me. ## Objective Join all assessment branches, publish one complete supervisory verdict, and release the project assessment lock. ## Required inputs For the same run ID: Assessment Run Record, Variable Assessment Evidence, Ticket Action Record, Delivery Throughput Snapshot, and Required-Artifact Coverage Report. ## Procedure 1. Verify every required input exists, validates, and uses the same run ID, Charter version, iteration ID, and snapshot boundary. 2. If any branch is missing, stale, schema-invalid, or has an unresolved side-effect error, mark the run `incomplete`; do not publish a success verdict or release an ambiguous partial report. 3. Create `ITERATION_ASSESSMENT.md` containing: - run/snapshot identity and input versions; - executive verdict: `Green \| Yellow \| Orange \| Red \| Unknown`; - per-variable prior/current band, evidence, ticket action, owner, and gating policy; - throughput and cycle-time findings; - artifact-coverage findings; - active `observe \| pause_new_work \| block_release` signals; - required next actions with owner and due/decision point; - errors, Unknowns, and confidence/provenance limitations. 4. Derive the overall verdict from declared Charter policy. Never average away a Red, Unknown, or gating signal. 5. Update `RUN.md` to `complete` with output checksums/links and end time; release the lock. 6. Notify the Delivery Manager and the RIN/MIN execution context through the destinations in the Huginn contract. ## Completion evidence The report is reproducible, internally consistent, complete for all branches, explicit about Unknowns and gates, linked to stable tickets, and the run record is complete with the lock released.

Activities in Assess the Iteration