Analysis lenses
Governing question
How do we allocate limited analysis resources across repositories whose code is too large to cover exhaustively? Resources include worker context, model and tool time, review effort, and the operator's cost of consuming the result.
The intended result is a defensible account of what to investigate, how deeply, when to stop, and how to report what remains unknown. The operator commissioned this workshop on 2026-10-11 after discussing the analysis audits, then clarified this resource-versus-coverage question as its main goal.
The analysis design brief already establishes the overall goals: map the design space and identify solutions worth borrowing for Commonplace. This workshop develops how analysis scope and worker responsibilities serve those goals; it does not replace the brief.
Standing premise
The process has only recently stabilized and has substantial supporting machinery. Preserve that investment. This is a design investigation, not authorization to redesign the engine or implement a new workflow. Retaining the current arrangement with clearer scope is a valid result.
The current method already has the shape discussed with the operator: a general runtime layer, question-driven memory and epistemic lenses that receive the runtime record, reconciliation, and independent verification. The workshop's real question is therefore depth, stopping and coverage reporting inside those roles, not whether to introduce the shape. See current arrangement before reading anything else.
Documents
| Document | Contents |
|---|---|
| Current arrangement | What the live plan and role instructions already decide about layers, lens inputs, stopping and coverage; the baseline every option is compared against |
| Design direction | Intentions established with the operator, preservation defaults and the least-disruptive-change ladder |
| Open questions | Each unresolved question with its current answer and the evidence that would discriminate |
| Evidence base | Audits, trace measurements and the frozen source worktrees; what each can and cannot show about coverage |
| First deliverable | The first comparison to produce, its evaluation criteria and the return-to-operator condition |
| Comparison plan | Executable handoff for correcting workshop premises and comparing three coverage policies using retained cases; no live method changes |
| Multi-repository scope plan | Use Ars Umbris to compare component analyses with a fixed repository bundle, balancing coverage against workflow and implementation complexity |
| Retained multi-repository scope comparison | Prefer one frozen source tree for the Ars Umbris cross-component question; retain component evidence, quotation/source-ID audit and change footprint |
| Proposal: multi-repository agentic-system analysis | Cover multi-repository systems using repository directories while preserving roles, source IDs and path-only quotations; unadopted |
| Coverage policy comparison | Adopted prose-only clarification: consequential-question omission checks with effort-sensitive stopping and brief coverage reporting; retained-case evidence and implementation footprint |
| Proposal: verification coverage bounds | Unadopted operator proposal of 2026-10-11: add structural accounting at runtime and bound lens omission checks; original exhaustive-duty premise qualified against the live type |
Scope and coordination
The operator also commissioned the multi-repository scope plan: use Ars Umbris to compare bounded component runs with an explicitly frozen repository bundle. This authorizes local read-only scoping and workshop design work, not acquisition, source-ID removal or bundle implementation.
This workshop owns resource allocation and coverage limits in analysis; lens and scope design are possible means of addressing that question. The audit evidence workshop continues to own audit accumulation and cross-run evidence, including any coverage audit this workshop asks for. The amendments workshop contains related correction and contract-design history; its candidates are not an implementation backlog for this workshop.
The initial commission authorized workshop framing, navigation and comparison. The operator subsequently authorized revising and implementing the comparison's prose-only recommendation: report-verifier stopping and search authority, and brief coverage reporting. That change is implemented in the canonical worker instructions and verification type; no roles, dependencies, schemas or engine code changed. Existing analyses and run state remain unchanged. Quality and cost improvements remain unmeasured. Commit the method before new runs; repeat-run commands requested by the operator are a separate invocation, not a run launched by this workshop. Transfer scans, integration, commits and worktree disposal still need separate authorization. Deterministic measurements over retained records and frozen worktrees are within scope when they write only under this workshop. Before separately authorized method work, follow method maintenance.
Closure
Close when the operator has accepted a minimal-change design, chosen to retain the current process, or explicitly deferred the question. Extract any adopted requirements and useful evidence to their appropriate durable locations. If implementation is commissioned, give it a bounded plan and explicit acceptance criteria; this framing is not that plan. Remove the workshop and its active-list entry only after extraction or explicit disposition.
Complete file listing (generated at build time)