metadata: separate non-case legal effect from precedential weight

[zackees]

Context

TAXONOMY.md reserves case-style precedential_weight values for judicial authority and requires not-applicable for statutes, licenses, guidance, and other non-case sources. Eight non-case cards currently violate that rule:

• AUTH-0070, AUTH-0071, AUTH-0090
• AUTH-0093
• AUTH-0110, AUTH-0111, AUTH-0112, AUTH-0113

They encode binding or nonprecedential in the same field used to rank cases. This can make a retriever collapse operative statutes/rules, binding case precedent, and nonbinding technical guidance into one hierarchy. The correction must not imply that statutes or federal rules lack legal force.

Proposal

Set case-style precedential weight to not-applicable for the affected non-case cards. Preserve the source's legal or practical force in a separate controlled field, such as legal_effect or authority_role, and enforce a type/weight invariant. Keep settlement treatment as an explicitly documented exception if none-settlement remains useful.

Acceptance criteria

• Every statute, license, administrative material, and official-guidance card uses precedential_weight: not-applicable unless the taxonomy documents a narrow exception.
• The eight identified cards are corrected without weakening prose about operative federal statutes or rules.
• A separate controlled field distinguishes operative law, court rule, official guidance, license text, and technical standard where needed.
• A validator rejects non-case cards carrying binding, persuasive-*, nonprecedential, default-only, or none-allegation.
• Settlement cards either retain none-settlement under an express exception or migrate to the new authority-role field consistently.
• Retrieval tests rank statutes/rules, case precedent, license text, and guidance without treating them as the same concept.

Decisions

• Confirmed taxonomy contradiction, P1 metadata integrity. This is a classification correction, not a legal-force conclusion.
• Separate force from precedent. precedential_weight alone cannot describe every authority type safely.
• No LICENSE edit or merits change. Existing substantive analysis remains pending attorney review.

Open questions

• What controlled values should legal_effect or authority_role permit?
• Is none-settlement best retained as a documented exception or moved out of precedential weight entirely?

Related issues

• Parent: audit: adversarially review the paralegal research corpus #19
• Corpus creation: docs: build a license-agnostic copyleft enforcement research corpus #17

[zackees]

Sol adversarial review - 2026-08-25

Verdict: confirmed, with an exact-count correction and narrower invariants; leave open. The repository has a real internal contradiction. TAXONOMY.md assigns not-applicable to statutes, licenses, guidance, and other non-case authorities, and the authority template says every non-case authority must use it for both posture and weight. The eight listed cards violate that rule. The metadata defect is demonstrated; the claimed retrieval harm remains prospective because this repository has no checked-in corpus retriever or validator.

Reproducible census

At current main commit 40ee7108f4b46b6b8fb1976f5c8b3cd996bdfb42, scanning the YAML frontmatter of every file matching ^id: AUTH- gives 102 cards: 60 case and 42 non-case. Non-case types are 30 license, 1 license-condition, 1 license-draft, 5 statute, 3 administrative-material, 1 official-guidance, and 1 settlement.

$files = rg -l '^id: AUTH-' paralegal-research/authorities -g '*.md'
$rows = foreach ($file in $files) {
  $h = (Get-Content -LiteralPath $file -TotalCount 25) -join `n
  [pscustomobject]@{
    id      = [regex]::Match($h, '(?m)^id:\s*(.+)$').Groups[1].Value
    type    = [regex]::Match($h, '(?m)^authority_type:\s*(.+)$').Groups[1].Value
    posture = [regex]::Match($h, '(?m)^procedural_posture:\s*(.+)$').Groups[1].Value
    weight  = [regex]::Match($h, '(?m)^precedential_weight:\s*(.+)$').Groups[1].Value
  }
}
$rows.Count                                      # 102
($rows | Where-Object type -eq 'case').Count     # 60
($rows | Where-Object type -ne 'case').Count     # 42
$rows | Where-Object { $_.type -ne 'case' -and $_.weight -ne 'not-applicable' } |
  Sort-Object id | Format-Table id,type,posture,weight

That final command returns nine, not eight:

• AUTH-0070, AUTH-0071, AUTH-0090, AUTH-0110: statute / binding.
• AUTH-0093, AUTH-0111, AUTH-0112: administrative-material / binding.
• AUTH-0113: official-guidance / nonprecedential.
• AUTH-0008: settlement / none-settlement, and it also uses case posture settled.

Thus eight is exact only for the issue's proposed rejected-value set after treating settlement as an exception. Under the taxonomy and template as currently written, AUTH-0008 is a ninth type/weight violation and the sole non-case posture violation. The other 33 non-case cards already use not-applicable. No case card uses not-applicable for posture or weight.

The eight named cards are genuinely non-case source cards. AUTH-0093, AUTH-0111, and AUTH-0112 are judicially promulgated federal rules, but they are not adjudicative opinions, holdings, or case precedent. Calling them administrative-material exposes a missing court-rule type; it does not make precedential_weight: binding coherent. Federal rules have the force and effect of law under the Rules Enabling Act process (U.S. Courts; 28 U.S.C. § 2072). AUTH-0113 is an official NIST technical report aimed at evidence-management professionals, not an adjudication or evidence rule (NIST publication record). Setting case precedent to not-applicable must therefore be paired with positive effect/role metadata so retrieval does not demote statutes or court rules below merely persuasive cases.

Corrections and taxonomy loopholes

1. Do not implement only a blacklist. The proposed validator rejects several named values but would still permit statute + none-settlement, an unknown value, or a future non-case type omitted from the checklist. Use closed enums plus an allowed type/posture/weight matrix. The first acceptance criterion also omits current taxonomy types regulation, license-condition, license-draft, settlement, and secondary-source.
2. Use exact equality for non-adjudicative sources. With the current type set, the safe invariant is authority_type != case => procedural_posture == not-applicable && precedential_weight == not-applicable. If the corpus later admits agency adjudications, add a distinct administrative-decision type and consciously decide whether this field covers administrative precedent; do not silently exempt all administrative-material.
3. Separate court rules from agency/administrative material. Add court-rule (and likely technical-standard) rather than relying on prose to say an administrative-material is legally operative. regulation, agency guidance, agency adjudication, and an agency technical report have materially different roles.
4. Do not make one new field carry both source identity and legal force. Prefer a source/artifact role plus scoped effect. Candidate roles include judicial-decision, party-filing, docket-record, statute, regulation, court-rule, license-instrument, settlement-instrument, settlement-report, official-guidance, technical-standard, and secondary-analysis. Candidate effects include generally-operative, case-specific-order, party-agreement, conditional-private-instrument, nonbinding-guidance, and informational-only, always qualified by jurisdiction/parties/effective date. These are design candidates for counsel, not legal conclusions.
5. Treat settlements by artifact, not a blanket exception. An authenticated settlement instrument may bind parties without being precedent. A public settlement announcement reports terms but is not itself the operative agreement. AUTH-0008 relies on a secondary announcement, so settlement-report plus informational/reported effect is safer than implying authenticated party-binding terms. By contrast, a case card whose litigation ended in settlement can coherently retain procedural_posture: settled and precedential_weight: none-settlement; the current case examples are AUTH-0039, AUTH-0043, AUTH-0044, and AUTH-0046.
6. Handle dockets and consent orders explicitly. A clerical docket entry is neither party allegation nor precedent. A complaint is a party filing. A consent judgment is a judicial order binding specified persons but ordinarily not a contested merits holding. The current case bucket and weight enum cannot express all three safely. Coordinate the source-artifact model with retrieval: make authority proposition treatment machine-checkable #24 rather than creating divergent parsers.
7. Do not turn legal_effect into a universal ranking score. Operative text, forum-specific case precedent, private license terms, reported settlements, and technical practice answer different questions. Retrieval should filter by actor, proposition, forum, artifact role, effect scope, status/date, posture, and source quality before applying any ranking.
8. Preserve the attorney gate. A validator can enforce enum compatibility; it cannot decide whether an agency decision is precedential, a consent decree is operative against a person, a settlement report accurately states the agreement, or a license formed an enforceable relationship.

Stronger acceptance criteria

• Document a closed, versioned matrix for every authority type: allowed procedural_posture, allowed precedential_weight, source/artifact role, legal-effect category, and required scope/status fields.
• Migrate the eight named cards to precedential_weight: not-applicable; classify AUTH-0093, AUTH-0111, and AUTH-0112 as court rules rather than generic administrative material; preserve prose and structured metadata stating their operative federal procedural/evidentiary effect.
• Resolve AUTH-0008 explicitly. Recommended default: not-applicable posture/weight plus settlement-report role. Keep none-settlement only for case records whose disposition is settlement, unless counsel approves a documented alternative.
• Enforce non-adjudicative => posture/weight exactly not-applicable; enforce the converse for adjudicative records; reject unknown values, omitted current/future types, and exception values on the wrong type.
• Add adversarial fixtures for statute, regulation, court rule, agency adjudication, agency guidance, technical standard, license text, complaint, docket entry, contested decision, default, settlement agreement/report, and consent decree.
• Generate a committed baseline report proving 102/102 cards parse, all IDs are unique/indexed, zero type/posture/weight violations remain, and every new source/effect field is populated or placed on a finite explicit migration allowlist.
• Add the corpus validator and real-card retrieval tests to normal cross-platform CI. Existing tools/license_headers.py, tests/test_license_headers.py, and header-policy.schema.json validate source-license headers only; no current code consumes authority frontmatter.
• Test that operative statutes/rules outrank contrary nonbinding material for the question they govern without being mislabeled case precedent; test that NIST guidance, license text, settlement reports, and docket records cannot satisfy a judicial-holding query.
• Coordinate the shared parser/schema/diagnostics and source-artifact representation with governance: make stale-source handling operational #22, retrieval: align matter schema with doctrine, remedy, and time taxonomy #23, retrieval: make authority proposition treatment machine-checkable #24, and governance: repair matter-link and integration-state contradictions #26.

Questions for attorney review

• Is precedential_weight limited to judicial decisions, or should a separately typed agency adjudication use it within the agency/target forum?
• Should federal rules be classified as court-rule with generally-operative effect, and what jurisdiction/effective-date fields are mandatory?
• Which distinctions must exist among an authenticated settlement, a party announcement, a consent decree, and a case merely dismissed after settlement?
• How should a private license text's potential legal effect be labeled without implying formation, assent, enforceability, standing, or applicability to a particular actor?
• Are generally-operative, case-specific-order, party-agreement, conditional-private-instrument, nonbinding-guidance, and informational-only acceptable effect categories, or should force and role remain separate axes?
• Which metadata changes require attorney approval, and may an automated migration alter only classification while all substantive legal-effect judgments remain pending?

History, duplicate, and resolution check

The taxonomy, template invariant, and eight named violations were introduced together in PR #18 / commit 40ee710; AUTH-0008 originated in PR #16 and received its conflicting structured values in the same PR #18 commit. Current local HEAD, origin/main, remote HEAD, and main all resolve to 40ee710. GitHub has no later open or merged PR implementing this issue and no duplicate issue. #19 is the parent; #24 is complementary proposition/artifact work, not a duplicate. Before this review, #27 had no comments or resolving timeline event. Closure would therefore be unsupported.

This is a corpus-integrity assessment for attorney review, not legal advice, a license decision, or a change to LICENSE.