psyclaw 0.27.23 → 0.28.1

package/vendor/ars/shared/references/submission_packet_manifest_protocol.md

@@ -0,0 +1,292 @@
+# Deterministic Submission-Packet Manifest Protocol (#667)
+
+This protocol governs mechanical human-subjects packet inventory checks. It is
+not a committee, legal opinion, prose review, institutional acceptance,
+submission authorization, approval, exemption, compliance result, or review
+pathway.
+
+Canonical artifacts:
+
+- `shared/contracts/human_subjects/submission_packet_inventory.schema.json`
+- `shared/contracts/human_subjects/submission_packet_manifest.schema.json`
+- `scripts/build_submission_packet_manifest.py`
+- `shared/contracts/human_subjects/irb_context_record.schema.json`
+- `shared/contracts/human_subjects/resolved_authority_context.schema.json`
+- `shared/human_subjects_authority_registry.json`
+- `scripts/resolve_human_subjects_authority.py`
+- `docs/design/2026-08-09-667-submission-packet-manifest-spec.md`
+
+The schemas govern local field shape. This protocol governs safe consumption.
+
+## Authority gate
+
+Accept the #666 authority inputs only as a complete context, registry, and
+resolved-result triplet. Before dereferencing any authority pointer, call:
+
+```python
+validate_resolved_context(resolved, context, registry)
+```
+
+Then require both:
+
+```text
+resolution_state=resolved
+downstream_gate.profile_dependent_result_allowed=true
+```
+
+A replay mismatch is a contract error. Do not convert it to an ordinary
+unresolved status. If the triplet is intentionally absent, emit a context-free
+`APPLICABILITY_UNRESOLVED` result with
+`AUTHORITY_INPUT_NOT_PROVIDED`; do not infer a profile from locale, affiliation,
+language, filename, packet content, or model memory.
+
+Consume only `requirement_results[]` rows whose `consumer_scopes` includes
+`submission_packet`. Preserve all exact requirement, authority, digest, and
+pointer fields. Resolve `requirement_pointer` only in the replay-bound registry.
+Keep different authorities and collisions parallel. Fail before output if one
+requirement would copy more than 512 consumer scopes, or if applicable evidence
+entries or excluded requirements would exceed 4,096 rows. Also reject a final
+canonical manifest larger than 8 MiB, including its self digest, so a successful
+build always round-trips through the CLI input limit.
+
+## Evidence boundary
+
+For an applicable requirement, V1 consumes only these exact
+`evidence_expected[]` fields:
+
+- `evidence_id`
+- `held_by`
+- `artifact_type`
+
+It computes and preserves an `evidence_pointer` and `evidence_digest`. It never
+interprets, evaluates, or copies `evidence_expected.description`; the exact
+evidence row is canonical-hashed only to bind replay integrity.
+
+V1 must not interpret, evaluate, or repurpose `structured_expectations`, including
+rows with `operator=present`. The exact requirement row, including those bytes,
+is canonical-hashed only to verify its #666 pointer and digest. Those rows concern
+semantic consent or information coverage and belong to #681. Do not interpret or
+copy requirement titles, summaries, packet prose, or attachment text. Hashing
+bytes for replay integrity is not permission to extract or judge them.
+
+## Inventory handling
+
+The inventory is author-owned and declaration-only. It names packet-responsible
+roles, exact attachment paths and hashes, exact expected-evidence bindings,
+declared structure metadata, optional waiver/exception claims, and one
+caller-supplied authorization-status object.
+
+Open only inventory-listed paths below the explicit packet root. Reject absolute,
+dot, dot-dot, non-normalized, repeated-separator, directory, and symlink targets.
+Do not scan siblings or follow links. Enforce 512 files, 64 MiB per file, and
+256 MiB total observed bytes.
+
+The authorization object contains exactly:
+
+```json
+{
+  "value": "documented",
+  "source_reference": "institution.record.1",
+  "provenance": "caller_supplied_no_derivation"
+}
+```
+
+`documented` requires a non-null reference; `not_provided` and `cannot_verify`
+require null. Copy the entire object unchanged. A packet finding cannot promote,
+downgrade, verify, or replace it.
+
+`packet_responsibility_role_ids` classifies evidence ownership only. A row is
+packet-owned only when both its replay-bound exact `obligated_actor` and exact
+expected `held_by` role occur in the list; composite actor ids are never split or
+expanded. If either role is outside the list, the row is an
+`external_dependency`. Never turn committee-, IRB-, controller-, or other
+authority-held evidence into an investigator omission.
+
+Declared version, date, signature-block, and certificate fields receive only
+closed syntax and internal-consistency checks. V1 has no universal rule that
+each artifact requires any of them. Without a separately versioned,
+source-backed mechanical expectation, a null version/date, a `not_located` or
+`unknown` signature row, a null certificate, or a certificate whose interval is
+future/stale relative to `applicability_as_of` cannot become a gap or conflict.
+Only internal contradictions such as expiry before issue or a present
+certificate's holder mismatch are mechanical conflicts.
+
+## Capability envelope
+
+The checker supports only the seven exact author-declared facts below:
+
+```text
+packet_v1.non_clinical=true
+packet_v1.single_institution=true
+packet_v1.competent_adults_only=true
+packet_v1.biospecimens_involved=false
+packet_v1.regulated_clinical_trial=false
+packet_v1.cross_border_material_transfer=false
+packet_v1.multisite_reliance=false
+```
+
+This is a software capability envelope, not a legal characterization. Missing,
+unknown, or different facts emit `APPLICABILITY_UNRESOLVED`. They do not select a
+pathway or establish non-applicability.
+
+## Status and readiness
+
+After the authority and capability gates permit packet observation, every
+explicit inventory row produces a packet observation with
+`status=DOCUMENTED|CONFLICTING` and closed reasons for located bytes, absence,
+declared hash/size mismatch, an internally impossible certificate interval, or
+a certificate holder that differs from the artifact's declared holder. This
+observation accounting also covers extra artifacts that no selected requirement
+consumes. It is visibility, not an authority requirement:
+observation status alone does not change readiness. Only an applicable,
+packet-owned evidence entry can turn the same mechanical conflict into a packet
+gap.
+When either gate is closed, observations remain empty and the checker does not
+open the packet root.
+
+The closed entry vocabulary is:
+
+```text
+DOCUMENTED
+NOT_LOCATED
+CONFLICTING
+APPLICABILITY_UNRESOLVED
+ACCEPTANCE_UNVERIFIED
+```
+
+Apply it as follows:
+
+- one exact, located, byte-matched, type-matched, holder-matched, internally
+  consistent packet-owned artifact → `DOCUMENTED`, readiness effect `none`;
+- no packet-owned evidence binding → `NOT_LOCATED`, effect `gap`;
+- duplicate binding, missing declared attachment, byte/type/holder mismatch, or
+  declared-structure conflict → `CONFLICTING`, effect `gap`;
+- missing authority, closed gate, unresolved/outside envelope, or missing overlay
+  selection → `APPLICABILITY_UNRESOLVED`, effect `unresolved`;
+- evidence whose obligated actor or expected holder is outside packet
+  responsibility → `ACCEPTANCE_UNVERIFIED`, responsibility
+  `external_dependency`, effect `none`;
+- a packet-owned claim whose route ids exactly equal a profiled route and whose
+  located decision artifact is bound to every route requirement →
+  `ACCEPTANCE_UNVERIFIED`, effect `unresolved`.
+
+A profiled waiver/exception route means only that a route exists. Only the exact,
+located, route-bound structural case above suppresses a false gap; a bare,
+unsupported, mismatched, or unlocated claim does not. Neither a claim nor a
+located decision artifact proves applicability, request, or grant, and neither
+can become `DOCUMENTED`.
+
+Aggregate readiness in this order:
+
+1. a global unresolved condition or packet-owned `unresolved` effect →
+   `unresolved`;
+2. otherwise a packet-owned `gap` effect → `gaps_located`;
+3. otherwise → `no_listed_gaps_located`.
+
+An external dependency and the fixed top-level institutional-acceptance boundary
+do not affect packet readiness. `overlay_selection_state=not_provided` does;
+`none_declared_by_author` remains visibly distinct and does not by itself prevent
+`no_listed_gaps_located`.
+
+`DOCUMENTED` is a mechanical uppercase entry state. It is not the lowercase
+authorization value `documented`.
+
+## Pointer, digest, and accounting rules
+
+Use canonical JSON with UTF-8, sorted keys, compact separators, and non-finite
+numbers forbidden. Reject control, format, and escaped lone-surrogate code points
+before digesting, rendering, or opening any path.
+
+- digest the semantic inventory for `inventory_digest`: sort packet-responsibility
+  roles; sort claims by requirement id and nullable decision-artifact id and sort
+  their route ids; sort artifacts by artifact id and relative path; sort each
+  artifact's evidence bindings by requirement/evidence id and signature blocks by
+  role/state; leave every scalar unchanged;
+- digest packet observations sorted by artifact id and relative path for
+  `observation_digest`;
+- recompute every dereferenced requirement and match `requirement_digest`;
+- derive `evidence_pointer` from the exact requirement pointer and evidence index,
+  then digest the exact evidence row;
+- copy #666 context and registry pointers and the resolved digest exactly; and
+- digest the completed manifest with `manifest_digest` excluded.
+
+Sort matched artifact ids lexically; entries by axis, authority kind, authority
+id, requirement id, and evidence pointer; excluded requirements by axis,
+authority kind, authority id, and requirement id; unresolved reasons by code,
+nullable fact id, and nullable overlay kind; and capability facts in the fixed
+seven-fact order. Never use #666 `trace_order` as a semantic sort key.
+
+Do not compute a raw context digest. #666 uses a semantic digest that excludes
+`confirmed_at` and normalizes unordered fields.
+
+Account for every selected `submission_packet` requirement exactly once:
+
+- applicability true: one entry for every expected-evidence row;
+- applicability false: one `excluded_requirements` row with
+  `resolved_predicate_false`;
+- applicability unknown: never crosses the #666 gate.
+
+Do not invent `NOT_APPLICABLE`, suppress a parallel authority, merge evidence
+rows, or let display precedence affect semantic output.
+
+Before accepting or rendering a serialized manifest, call
+`validate_submission_packet_manifest` with the same inventory, packet root, and
+authority-input mode. It replays the entire build and requires canonical exact
+equality. Shape validation or a self-consistent manifest digest alone is not
+sufficient.
+
+Treat every rendered identifier, pointer, and inventory path as untrusted data.
+Escape it deterministically so it cannot create raw HTML, a Markdown link/image,
+an extra table row, or another structural token.
+
+## Fixed administrative output
+
+Rendered output includes these four fixed #665 status lines:
+
+```text
+Review pathway: institutional determination required
+Submission readiness: gaps_located | no_listed_gaps_located | unresolved
+Authorization status: documented | not_provided | cannot_verify
+Review timeline: unknown — obtain current institutional estimate
+```
+
+Two additional lines preserve the caller-supplied authorization source reference
+and `caller_supplied_no_derivation` provenance without changing any status.
+
+and ends with:
+
+> **Human-subjects boundary:** This output does not authorize recruitment,
+> consent, access to identifiable data, intervention, or data collection.
+
+The JSON carrier preserves the same fixed text exactly:
+
+```text
+Human-subjects boundary: This output does not authorize recruitment, consent, access to identifiable data, intervention, or data collection.
+```
+
+It never emits a review level, content verdict, approval, adequacy finding, prose,
+quote, excerpt, or legal conclusion.
+
+## #681 handoff
+
+#681 consumes only a manifest that first passes
+`validate_submission_packet_manifest(...)` against the exact inventory, packet
+root, context, registry, and resolved artifact, plus separately and explicitly
+session-held content keyed by matched artifact id. Its finalizer is
+`scripts/build_content_coverage_advisory.py`, and its closed carrier/protocol are
+`shared/contracts/human_subjects/content_coverage_advisory.schema.json` and
+`shared/references/authority_content_coverage_advisory_protocol.md`.
+
+The advisory groups exact requirement refs without merging parallel
+authorities, copies every deterministic entry ref, and dereferences only the
+matching replay-bound `structured_expectations[]` rows. `DOCUMENTED` remains a
+structural signal, not content coverage. A packet gap, external-holder row,
+waiver/exception boundary, or applicability-false exclusion cannot be converted
+into a semantic missing-element finding.
+
+The output must carry `LLM-ADVISORY`, a separate
+`advisory_coverage_status`, and `evaluation_status=UNMEASURED`. It may not update
+any deterministic status, readiness, authorization, acceptance, pointer, or
+digest field. Missing or unavailable session content is an explicit
+`not_checked` result with null advisory status, never a fabricated
+`NOT_LOCATED`. UNMEASURED is not a scored measurement row or an efficacy claim.

package/vendor/ars/shared/references/word_count_conventions.md

@@ -0,0 +1,124 @@
+# Word Count Conventions
+
+**Spec:** v3.6.7 §7.1 — pattern protection reference for `report_compiler_agent` (abstract-only mode).
+
+**Audience:** Agents budgeting word counts under a hard cap (abstract, executive summary, INSIGHT block). Human authors verifying that an agent's word count matches the publisher's.
+
+**Why this exists:** Different word-count algorithms produce different totals on the same text. The differential is small per sentence but compounds: on a 250-word abstract, the choice between whitespace-split and hyphenated-as-1 can swing the total by ~12 words. An agent that uses a different algorithm than the publisher believes it is meeting the cap when it is over by 5%. This reference fixes a single canonical algorithm for ARS pipelines, documents how publishers diverge, and specifies the buffer rule that makes minor publisher variation safe.
+
+---
+
+## The canonical algorithm: whitespace-split
+
+ARS pipelines count words as `len(body.split())` in Python — that is, splits on any whitespace run and counts the resulting non-empty tokens.
+
+### Why whitespace-split
+
+1. **Reproducible.** Anyone running `len(body.split())` on the same UTF-8 text gets the same number. No hidden tokenizer state.
+2. **Matches Microsoft Word default.** Most authors check word count in Word, which uses a whitespace-equivalent algorithm. Aligning with the dominant authoring environment minimises surprise.
+3. **Conservative under hyphenation.** "State-of-the-art" counts as 1 token under whitespace-split. Under hyphenated-as-N this would count as 4. Whitespace-split therefore systematically reports a lower total than hyphenated-as-N — which is the safer direction when chasing a hard cap.
+4. **Language-neutral.** CJK text without spaces is a separate problem (see "Non-space-delimited languages" below), but for English / European languages, whitespace-split is the universal lower bound.
+
+### What whitespace-split counts
+
+| Token | Whitespace-split count |
+|---|---|
+| `state-of-the-art` | 1 |
+| `2020-2024` | 1 |
+| `Smith, John-Paul` | 2 (`Smith,` and `John-Paul`) |
+| `e.g.,` | 1 |
+| `123,456` | 1 |
+| `(n=42)` | 1 |
+| `https://example.org/path` | 1 |
+
+### What whitespace-split does NOT count
+
+- Whitespace runs collapse to one delimiter; they do not contribute tokens.
+- Empty strings between consecutive whitespace characters are filtered by `split()` with no argument.
+- Markdown formatting (`**bold**`, `*italic*`, `` `code` ``) is part of the surrounding token; the asterisks and backticks are not separate tokens.
+- ARS HTML-comment markers (see next section) — strip them before splitting.
+
+### HTML-comment markers (#390 — one rule for all marker kinds)
+
+ARS working drafts carry HTML-comment markers: `<!--ref:slug-->` / `<!--anchor:kind:value-->` (v3.7.1/v3.7.3, inline after citations) and `<!--block:BNNNN-->` (#390, one standalone line per block). **Strip every `<!--...-->` comment before computing `len(body.split())`.** Inline ref/anchor markers usually glue onto the preceding token (zero count impact) but add a token whenever whitespace precedes them; block markers are standalone lines and would inflate the total by one token per block — on a 60-block paper that is ~60 phantom words, and it would also corrupt `word_count_delta` (Schema 8) across patch-mode revision rounds. One rule covers every marker kind, current and future: markers are audit metadata, never countable content. (Phase 7 separately strips markers from converted final outputs — `formatter_agent.md` § ARS Marker Stripping — so publisher-side counts never see them either.)
+
+---
+
+## Publisher conventions and how to adapt
+
+Most publishers use a whitespace-equivalent algorithm in practice but state different conventions in their author guidelines. The 3–5% buffer rule (below) makes ARS pipelines robust to the convention divergence without per-publisher adapters.
+
+### Common publisher families
+
+| Publisher / venue | Stated algorithm | Practical effect |
+|---|---|---|
+| Springer / Nature | whitespace-equivalent for abstract, no explicit definition | matches ARS canonical |
+| IEEE | "approximately N words" — whitespace-equivalent in their submission tool | matches ARS canonical |
+| ACM | whitespace-equivalent in CCS submission | matches ARS canonical |
+| Elsevier (Cell, Lancet families) | whitespace-equivalent in EM submission | matches ARS canonical |
+| Wiley | whitespace-equivalent | matches ARS canonical |
+| arXiv | no hard cap on abstract; advisory ~250 words | guideline only |
+| ICLR / NeurIPS / ACL workshop tracks | hyphenated-as-1 in their LaTeX `\abstract{}` counter | matches ARS canonical |
+| Some social-science journals (variable) | "page-based" — abstract must fit visually on submission template | not a true word count; check template |
+
+### When the publisher uses a stricter algorithm
+
+Some non-English-medium publishers and a small number of style guides count hyphenated compounds as multiple words. If the publisher explicitly states "hyphenated words count as separate words":
+
+1. Calibration should compute both totals: `len(body.split())` and the hyphenated-as-N variant.
+2. The dispatch context to the abstract compiler should carry both numbers.
+3. The compiler should use the stricter (higher) total when budgeting.
+
+If the publisher's algorithm is ambiguous, default to ARS canonical (whitespace-split) plus the 3–5% buffer.
+
+---
+
+## The 3–5% buffer rule
+
+ARS pipelines reserve **3–5% below the publisher's stated hard cap** as buffer. For a 250-word abstract:
+
+- 3% buffer → target 242 words
+- 5% buffer → target 237 words
+
+### Why this range
+
+1. **Algorithm divergence absorbs into the buffer.** Even if the publisher's tool counts ~3% higher than `len(body.split())`, the abstract still meets the cap.
+2. **Editor-side trimming room.** Reviewers and copy editors occasionally request a phrase change that adds 2–3 words. Abstract that lands at exactly the cap forces a downstream cut; abstract that lands at cap minus 5% accommodates the change without cut.
+3. **Title plus abstract pages.** Some publishers count the running title or running header; the buffer absorbs that too.
+
+### When to use 3% vs. 5%
+
+- **3%** when the calibration's `protected_hedges` block is large (≥10% of cap word budget). Tighter buffer keeps room for substantive content.
+- **5%** when the publisher's algorithm is unstated or the protected hedges are minimal. Looser buffer absorbs more uncertainty.
+
+### When NOT to use buffer
+
+If the publisher imposes a strict character count instead of word count (rare, but happens with some Asian-language journals), the buffer rule does not apply directly. Calibration should compute character count under the publisher's stated encoding and apply a 1–2% buffer at the character level.
+
+---
+
+## Non-space-delimited languages
+
+Mandarin, Japanese, Korean, Thai, and Lao do not delimit words with whitespace. ARS canonical algorithm produces meaningless totals on these texts.
+
+For abstracts in non-space-delimited languages:
+
+1. Use **character count**, not word count. Most publishers serving these languages specify character caps (e.g., Mandarin abstract often capped at 300 or 500 characters).
+2. Apply 1–2% buffer at the character level.
+3. The dispatch context to the abstract compiler should carry both `cap_unit: "character"` and the character cap, so the compiler does not erroneously apply word-budget logic.
+
+For mixed-language abstracts (e.g., Mandarin abstract with English technical terms), count each segment in its native unit and report both numbers; the publisher's authoritative count usually applies the language-specific rule per segment.
+
+---
+
+## Where this convention is enforced
+
+The `report_compiler_agent` abstract-only mode prompt enforces the canonical algorithm, the 3–5% buffer, and the post-draft re-verification step. The authoritative protection clause lives in `deep-research/agents/report_compiler_agent.md` under `PATTERN PROTECTION (v3.6.7)`. This file defines the algorithm, the buffer rationale, and the publisher-convention escape hatches; the agent prompt cites this file by path.
+
+---
+
+## Cross-references
+
+- `shared/references/protected_hedging_phrases.md` — protected hedging phrases share the abstract budget; budget allocation order specified there.
+- `shared/templates/codex_audit_multifile_template.md` — audit dimensions including word-count verification.
+- ARS feedback memory `feedback_word_count_convention_mismatch.md` — original empirical observation of whitespace-split vs. hyphenated-as-1 differential (~12 words on a 250-word abstract).

package/vendor/ars/shared/research_workflow_profiles/field_general.json

@@ -0,0 +1 @@
+{"alternative_categories":{"categories":[],"state":"unresolved"},"authority_points":[],"branch_budget":3,"content_sha256":"2d69b4a6536f9a84c227ab751ca4ee8ca8bcfcd9af8fdece5801eecc6c8378b4","display_name":{"en":"Field-general fallback","zh_TW":"領域通用後備設定"},"known_exclusions":[],"overflow_behavior":"ask_merge_park_archive","profile_id":"field_general","profile_version":"1.0.0","provenance":{"freshness_state":"current","last_reviewed_at":"2026-08-24","source":"shipped_default","source_pointer":"shared/research_workflow_profiles/field_general.json"},"research_family":"field_general","schema_version":"research-workflow-profile/1.0","stage_map":{"drafting":{"state":"unresolved_fit"},"finalization":{"state":"unresolved_fit"},"integrity_check":{"state":"applicable"},"methodology":{"state":"unresolved_fit"},"retrieval":{"state":"unresolved_fit"},"review":{"state":"unresolved_fit"},"revision":{"state":"unresolved_fit"},"rq_formation":{"state":"unresolved_fit"},"synthesis":{"state":"unresolved_fit"}},"unresolved_fit_note":"Field-specific stage applicability, alternative categories, and authority requirements remain unvalidated; ask the user before treating them as resolved."}

package/vendor/ars/shared/review_criteria_registry.json

@@ -0,0 +1,207 @@
+{
+  "schema_version": "review-criteria-registry/1.0",
+  "registry_id": "ars-field-general-review-criteria",
+  "registry_version": "2026.08.24",
+  "as_of": "2026-08-24",
+  "authority_classes": {
+    "official_venue_type": [
+      "official.msr2027.technical.full.scope",
+      "official.msr2027.technical.full.validity",
+      "official.msr2027.technical.full.open-science"
+    ],
+    "field_society_standard": [
+      "field.sigsoft.empirical.general-essential"
+    ],
+    "reporting_design_overlay": [
+      "overlay.sigsoft.repository-mining.essential"
+    ],
+    "broad_field_fallback": [
+      "broad.claim-evidence-alignment",
+      "broad.method-evidence-alignment",
+      "broad.limitation-calibration",
+      "broad.submission-traceability"
+    ]
+  },
+  "criteria": [
+    {
+      "criterion_id": "broad.claim-evidence-alignment",
+      "version": "1.0",
+      "authority_class": "broad_field_fallback",
+      "dimension": "scientific_validity",
+      "title": "Claim and evidence alignment",
+      "statement": "Each material claim should be supported at the strength and scope asserted, with uncertainty preserved.",
+      "source": {
+        "title": "ARS Review Criteria Framework",
+        "publisher": "Academic Research Skills",
+        "uri": "repository://academic-paper-reviewer/references/review_criteria_framework.md",
+        "effective_date": "2026-08-08",
+        "verified_at": "2026-08-08",
+        "freshness": "current"
+      },
+      "applicability": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "exclusions": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "blocking_policy": "blocking_allowed",
+      "conflict_group": null
+    },
+    {
+      "criterion_id": "broad.method-evidence-alignment",
+      "version": "1.0",
+      "authority_class": "broad_field_fallback",
+      "dimension": "scientific_validity",
+      "title": "Method and evidence alignment",
+      "statement": "Methods, data, and analysis should be fit for the research question and support reproducible scrutiny at the level claimed.",
+      "source": {
+        "title": "ARS Review Criteria Framework",
+        "publisher": "Academic Research Skills",
+        "uri": "repository://academic-paper-reviewer/references/review_criteria_framework.md",
+        "effective_date": "2026-08-08",
+        "verified_at": "2026-08-08",
+        "freshness": "current"
+      },
+      "applicability": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "exclusions": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "blocking_policy": "blocking_allowed",
+      "conflict_group": null
+    },
+    {
+      "criterion_id": "broad.limitation-calibration",
+      "version": "1.0",
+      "authority_class": "broad_field_fallback",
+      "dimension": "scientific_validity",
+      "title": "Limitation calibration",
+      "statement": "Limitations, uncertainty, boundary conditions, and plausible alternatives should be visible and proportionate to the evidence.",
+      "source": {
+        "title": "ARS Review Criteria Framework",
+        "publisher": "Academic Research Skills",
+        "uri": "repository://academic-paper-reviewer/references/review_criteria_framework.md",
+        "effective_date": "2026-08-08",
+        "verified_at": "2026-08-08",
+        "freshness": "current"
+      },
+      "applicability": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "exclusions": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "blocking_policy": "blocking_allowed",
+      "conflict_group": null
+    },
+    {
+      "criterion_id": "broad.submission-traceability",
+      "version": "1.0",
+      "authority_class": "broad_field_fallback",
+      "dimension": "submission_readiness",
+      "title": "Submission traceability",
+      "statement": "Required declarations, supporting artifacts, and unresolved limitations should be traceable without presenting field-general guidance as venue-specific compliance.",
+      "source": {
+        "title": "ARS Review Criteria Framework",
+        "publisher": "Academic Research Skills",
+        "uri": "repository://academic-paper-reviewer/references/review_criteria_framework.md",
+        "effective_date": "2026-08-08",
+        "verified_at": "2026-08-08",
+        "freshness": "current"
+      },
+      "applicability": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "exclusions": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "blocking_policy": "advisory_only",
+      "conflict_group": null
+    },
+    {
+      "criterion_id": "official.msr2027.technical.full.scope",
+      "version": "2027-cfp.pane-sha256-2546217a5f2b7dccb3b617b976e75cf7427c9a3881fda3092323c94a35231795",
+      "authority_class": "official_venue_type",
+      "dimension": "venue_fit",
+      "title": "MSR 2027 full-paper scope and contribution",
+      "statement": "An MSR 2027 Technical Papers Full Paper should make software data central, present a significant research contribution, and describe a new technique or novel research result with high technical rigor and scientific evaluation.",
+      "source": {
+        "title": "MSR 2027 Technical Papers — Call for Papers",
+        "publisher": "MSR 2027",
+        "uri": "https://2027.msrconf.org/track/msr-2027-technical-papers#Call-for-Papers",
+        "effective_date": "2026-08-24",
+        "verified_at": "2026-08-24",
+        "freshness": "current"
+      },
+      "applicability": {"disciplines": [], "subfields": [], "venues": ["MSR 2027"], "tracks": ["Technical Papers"], "contribution_types": ["Full Paper"], "overlays": []},
+      "exclusions": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "blocking_policy": "blocking_allowed",
+      "conflict_group": null
+    },
+    {
+      "criterion_id": "official.msr2027.technical.full.validity",
+      "version": "2027-cfp.pane-sha256-2546217a5f2b7dccb3b617b976e75cf7427c9a3881fda3092323c94a35231795",
+      "authority_class": "official_venue_type",
+      "dimension": "scientific_validity",
+      "title": "MSR 2027 soundness and replicability",
+      "statement": "Assess whether the contribution addresses its research questions through relevant procedures and whether its claims can be independently checked through a replication package or enough information about data acquisition, analysis, interpretation, or technique operation.",
+      "source": {
+        "title": "MSR 2027 Technical Papers — Evaluation Criteria",
+        "publisher": "MSR 2027",
+        "uri": "https://2027.msrconf.org/track/msr-2027-technical-papers#evaluation-criteria",
+        "effective_date": "2026-08-24",
+        "verified_at": "2026-08-24",
+        "freshness": "current"
+      },
+      "applicability": {"disciplines": [], "subfields": [], "venues": ["MSR 2027"], "tracks": ["Technical Papers"], "contribution_types": ["Full Paper"], "overlays": []},
+      "exclusions": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "blocking_policy": "blocking_allowed",
+      "conflict_group": null
+    },
+    {
+      "criterion_id": "official.msr2027.technical.full.open-science",
+      "version": "2027-cfp.pane-sha256-2546217a5f2b7dccb3b617b976e75cf7427c9a3881fda3092323c94a35231795",
+      "authority_class": "official_venue_type",
+      "dimension": "submission_readiness",
+      "title": "MSR 2027 data-availability and artifact disclosure",
+      "statement": "Include a data-availability statement; disclose relevant source code, anonymized and curated study data, and reproduction or replication instructions when possible; identify and explain any ethical, legal, technical, economic, or other barrier to disclosure.",
+      "source": {
+        "title": "MSR 2027 Technical Papers — Open Science Policy",
+        "publisher": "MSR 2027",
+        "uri": "https://2027.msrconf.org/track/msr-2027-technical-papers#open-science-policy",
+        "effective_date": "2026-08-24",
+        "verified_at": "2026-08-24",
+        "freshness": "current"
+      },
+      "applicability": {"disciplines": [], "subfields": [], "venues": ["MSR 2027"], "tracks": ["Technical Papers"], "contribution_types": ["Full Paper"], "overlays": []},
+      "exclusions": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "blocking_policy": "blocking_allowed",
+      "conflict_group": null
+    },
+    {
+      "criterion_id": "field.sigsoft.empirical.general-essential",
+      "version": "d131d7209f2fad7e8dfd30afbd2b8ea605ea3141",
+      "authority_class": "field_society_standard",
+      "dimension": "scientific_validity",
+      "title": "ACM SIGSOFT General Standard essential attributes",
+      "statement": "For a software-engineering study that collects and analyzes data, state and motivate its questions; name and justify the methodology; describe data collection and analysis; connect results and conclusions to the questions and evidence; disclose major limitations; and address applicable research risks and empirical standards.",
+      "source": {
+        "title": "ACM SIGSOFT Empirical Standards — General Standard",
+        "publisher": "ACM SIGSOFT",
+        "uri": "https://github.com/acmsigsoft/EmpiricalStandards/blob/d131d7209f2fad7e8dfd30afbd2b8ea605ea3141/docs/standards/GeneralStandard.md#L7-L75",
+        "effective_date": "2025-02-19",
+        "verified_at": "2026-08-24",
+        "freshness": "current"
+      },
+      "applicability": {"disciplines": ["Software Engineering"], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": ["ACM SIGSOFT Repository Mining Standard"]},
+      "exclusions": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "blocking_policy": "advisory_only",
+      "conflict_group": null
+    },
+    {
+      "criterion_id": "overlay.sigsoft.repository-mining.essential",
+      "version": "53c14e1a85aac1aeafb0788a622c5aaafec5c8b9",
+      "authority_class": "reporting_design_overlay",
+      "dimension": "scientific_validity",
+      "title": "ACM SIGSOFT Repository Mining Standard essential attributes",
+      "statement": "For quantitative studies that automatically extract software-repository data, justify method fit, sources, repository selection, acquisition, preprocessing, measures, and any sampling or annotation procedure; validate selection criteria and measures where applicable; and discuss external-validity threats and method-specific boundaries.",
+      "source": {
+        "title": "ACM SIGSOFT Empirical Standards — Repository Mining",
+        "publisher": "ACM SIGSOFT",
+        "uri": "https://github.com/acmsigsoft/EmpiricalStandards/blob/53c14e1a85aac1aeafb0788a622c5aaafec5c8b9/docs/standards/RepositoryMining.md#L6-L55",
+        "effective_date": "2025-05-26",
+        "verified_at": "2026-08-24",
+        "freshness": "current"
+      },
+      "applicability": {"disciplines": ["Software Engineering"], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": ["ACM SIGSOFT Repository Mining Standard"]},
+      "exclusions": {"disciplines": [], "subfields": [], "venues": [], "tracks": [], "contribution_types": [], "overlays": []},
+      "blocking_policy": "advisory_only",
+      "conflict_group": null
+    }
+  ]
+}