GTM Biblical Greek Grammatical Concordance — Definitive Full Patriarchal NT v113

All NT books Corpus verification pending

Grammar & View

Grammar — ሰዋስው · Morphology — ሥነ-ምዕላድ · Syntax — ሥነ-አገባብ

Lemma Entries

Dictionary headwords with frequency and NT book distribution.

0 entries

All parts of speech

Copied

Cross-Source Syntax Agreement Explorer

Conservative positional comparison. A source pair is compared only when both selected sources have exactly one loaded row at the same canonical reference + token position. This is positional evidence, not proof that the two source tokenizations are textually equivalent.

Source A Source B Show Search

Position	Status	Source A	Source B	GTM source syntax	Original labels	Actions

Interpretation rule: agreement means the two uniquely paired loaded rows expose the same GTM-normalized source-syntax role set. Disagreement does not by itself establish that either source is wrong; tokenization, annotation conventions, or GTM mapping decisions may differ.

Multi-Source Syntax Consensus Explorer

Descriptive multi-source comparison. All loaded syntax-bearing occurrence sources are compared at the same canonical reference + token position. Consensus reports agreement among source annotations; it is not a vote on grammatical truth and does not prove tokenization equivalence.

Show Search

Position	Status	Coverage	Consensus / leading role	Source evidence	Actions

Interpretation rule: unanimous or majority agreement is descriptive annotation agreement among the loaded sources at a conservatively keyed position. It does not establish which analysis is correct.

Syntax Consensus QA / Triage

Selective QA, not full manual review. The default queue surfaces cross-source disagreements, mapping gaps, coverage gaps, and positional ambiguity. Unanimous and majority agreement remain descriptive background evidence and are not treated as grammatical truth.

Triage scope NT Book Search

Book-level consensus QA

Comparable positions = unanimous + majority + no-consensus positions only. Mapping/coverage/duplicate-position problems are reported separately rather than folded into the agreement rate.

GTM roles involved in attention positions

Counts indicate how many triage positions contain each GTM role in at least one uniquely positioned source row. This does not assign the role as the correct analysis.

Position	Priority	Status	Coverage	Role evidence	Actions

Triage rule: review priority is operational, not grammatical truth. “No consensus” and “Ambiguous position” receive the highest priority because they are the strongest cross-source QA signals; Mapping incomplete and Partial coverage remain separate data-quality issues.

Source-Pair Syntax QA

Pattern-first QA. Every loaded syntax-source pair is summarized with the same conservative canonical reference + token-position rules used by the Agreement Explorer. The goal is to expose systematic disagreement, mapping, coverage, or duplicate-position patterns before any token-level inspection. No source pair is ranked as grammatically correct.

Pair scope NT Book Search

Source-pair QA profile

Agreement rate = agreements ÷ (agreements + disagreements). Mapping-incomplete, one-source-only, duplicate-position, and unkeyed evidence are excluded from that denominator.

Source A	Source B	Comparable	Agree	Disagree	Agreement	Mapping	Coverage	Structural	Action

Recurring GTM-role contrasts

Counts are pairwise disagreement observations. A contrast such as Subject ↔ Direct Object identifies a repeated cross-source analytical difference; it does not select a correct role.

Pairwise disagreements by NT book

One canonical position can contribute more than once when several source pairs disagree there. These are pairwise QA observations, not unique-token counts.

Interpretation rule: high pairwise disagreement can reflect annotation conventions, source tokenization, GTM mapping, or a genuine analytical difference. Use this dashboard to locate patterns; use the existing Agreement Explorer for the underlying positional evidence.

Source Consensus Compatibility QA

Source-centric QA, not source ranking. Each loaded syntax source is profiled against the multi-source consensus environment and against every other source at genuinely comparable positions. “Consensus compatibility” describes whether a source matches the unanimous/majority GTM-role leader where such a leader exists; it does not make that leader grammatically authoritative.

Source scope NT Book Search

Source-level consensus compatibility profile

Consensus-compatible denominator = only unanimous/majority positions where this source has exactly one row and a complete GTM-normalized role set. Pairwise agreement uses only uniquely paired, fully mapped rows. Mapping, coverage, duplicate-position, and unkeyed evidence remain outside both agreement denominators.

Source	Consensus comparable	Leader match	Leader divergence	Consensus compatibility	Pairwise comparable	Pairwise agreement	Mapping	Coverage	Structural	Action

Focus a source to inspect its recurring divergence signatures and pairwise partner profile.

Focused source · consensus-divergence signatures

These are majority-consensus positions where the focused source exposes a different complete GTM role set from the majority leader. The majority analysis remains descriptive evidence, not an adjudication.

Focused source · pairwise partner profile

Agreement is calculated independently for each partner source at shared unique, fully mapped positions. Different annotation schemes can legitimately produce systematic divergence.

Consensus divergences by NT book

Interpretation rule: this dashboard detects source-specific patterns that may deserve mapping or annotation-scheme investigation. It must not be used as a proxy for source quality, grammatical correctness, or scholarly authority.

GTM Role Consensus Stability QA

Role-centric QA, not grammatical adjudication. This dashboard asks which GTM-normalized syntactic roles remain stable across the loaded source environment and which roles participate in recurring majority-consensus divergence. A high or low compatibility rate describes annotation behavior only; it does not establish that the majority role is grammatically correct.

Role scope NT Book Search

Role-level consensus stability profile

Compatibility denominator = only source observations that explicitly contain this GTM role at a position with a unanimous or majority complete GTM-role leader. Mapping-incomplete, partial-coverage, duplicate-position, unkeyed, and no-consensus positions are excluded from the compatibility percentage.

GTM role	Leader positions	Unanimous	Majority	Source observations	Consensus comparable	Leader aligned	Source-side divergent	Dissent vs role leader	Compatibility	Sources	Action

Focus a role to inspect both directions of its recurring consensus-divergence patterns.

Focused role · source assignment → consensus leader

Shown when a source explicitly assigns the focused role but its complete GTM role set differs from the unanimous/majority leader at that position.

Focused role as majority leader · dissenting source alternatives

Shown when the majority leader includes the focused role but one or more uniquely mapped source rows use another complete role set. This remains descriptive evidence.

Focused role · source profile

Counts refer to explicit source observations containing this role. “Against leader” counts a source that differs where the majority leader contains the focused role, even if that source does not itself assign the role.

Focused role · NT book profile

Book counts separate leader footprint, explicit source observations, and source-sensitive divergence.

Interpretation rule: role stability is a cross-source annotation statistic, not a measure of grammatical truth. Recurring divergence may reflect annotation theory, mapping choices, tokenization, or genuinely disputed analysis.

Consensus Hotspot Localization QA

Localization, not adjudication. This dashboard identifies NT books and chapters where cross-source syntax evidence concentrates analytical disagreement or data-quality burden. It keeps No consensus separate from Mapping incomplete, Partial coverage, and Structural ambiguity, so a chapter is never called analytically unstable merely because its source data are incomplete.

Hotspot scope NT Book Search

Book / chapter QA localization

Agreement % uses only Unanimous + Majority + No consensus. QA burden % uses all keyed positions in the locus and answers only “what proportion needs some QA attention?”; it intentionally mixes priorities for workload localization, not for grammatical interpretation.

Locus	Positions	Attention	No consensus	Structural	Mapping	Coverage	Comparable	Agreement	QA burden	Action

Focus a book/chapter hotspot to inspect its role mix, source-specific burden, and representative positions.

Focused locus · roles in attention evidence

Roles are collected only from explicit GTM-normalized evidence at positions already classified for QA attention. They are not proposed corrections.

Focused locus · source-specific burden

Separates analytical dissent/no-consensus participation from missing coverage, unmapped role evidence, and duplicate-position structure.

Focused locus · representative attention positions

Priority samples are sorted to expose P1 cases first. Use these only when aggregate evidence suggests that inspection is worthwhile.

Interpretation rule: localization identifies concentration, not correctness. High analytical disagreement may reflect annotation theory; high data-quality burden may instead indicate mapping, source coverage, or positional-structure work.

Disagreement Signature Clustering QA

Pattern compression, not adjudication. This dashboard clusters only fully comparable analytical positions: P1 · No consensus and Monitor · Majority divergence. Mapping-incomplete, partial-coverage, duplicate-position, and unkeyed evidence is deliberately excluded, so a recurring pattern cannot be manufactured by data-quality defects.

Pattern scope NT Book Search

Recurring source-role allocation signatures

A signature preserves which source assigns which complete GTM role set. The same role family with a different source allocation is intentionally a different signature. Repetition is therefore evidence of a recurring annotation pattern, not merely repeated role vocabulary.

Class	Role family	Positions	Books	Chapters	Dominant locus	Source coalition summary	Action

Focus a disagreement signature to inspect its source-role coalition, corpus distribution, and representative positions.

Focused signature · source-role coalition

Sources are grouped by the exact GTM-normalized role set they assign at this recurring analytical pattern.

Focused signature · book/chapter concentration

Concentration helps distinguish a corpus-wide annotation habit from a pattern localized to a particular book or chapter.

Focused signature · representative positions

Open individual evidence only after the recurring pattern itself has proved worth inspecting.

Interpretation rule: recurrence increases QA relevance, not grammatical certainty. A stable source-role split may reflect different annotation models just as readily as an error.

Disagreement Persistence / Scope QA

Persistence is distribution, not truth. This dashboard starts from v83 exact analytical disagreement signatures and asks how broadly each signature recurs across the loaded corpus. Classification is computed against the full loaded corpus before any book filter is applied, so a globally multi-book pattern cannot be mislabelled as local merely because the current view is filtered to one book.

Persistence scope Analytical class NT Book Search

Exact disagreement signatures by persistence scope

Multi-book = recurring in at least two NT books. Within-book = recurring across at least two chapters of one book. Chapter-local = recurring more than once but confined to one chapter. Singleton = one observed position. No arbitrary grammatical severity score is assigned.

Persistence	Role family	Positions	Books	Chapters	Dominant book	Dominant chapter	Source coalition	Action

Focus a signature to inspect its corpus spread and choose the most efficient review route.

Focused signature · distribution

Book and chapter shares show concentration without changing the global persistence class.

Focused signature · source-role coalition

The exact source → GTM-role allocation inherited from v83 is preserved.

Focused signature · representative positions

Individual evidence remains the last step, after persistence and concentration have established whether detailed inspection is worthwhile.

Review route: focus a signature to see the recommended order of investigation.

Interpretation rule: broad recurrence can indicate a systematic annotation-model difference, but it does not prove that any source is right or wrong. Local recurrence can reflect a construction or context rather than a source-wide tendency.

Role-Contrast Family QA

Family grouping is conceptual compression, not evidence deletion. v85 groups the fully comparable analytical signatures from v83 by their unordered GTM role contrast. Reciprocal allocations such as Source A → Subject / Source B → Direct Object and Source A → Direct Object / Source B → Subject can therefore appear in one Subject ↔ Direct Object family, while every exact source → role signature remains visible underneath. Mapping gaps, partial coverage, duplicate positions, and unkeyed rows remain excluded.

Family scope NT Book Search

Source-agnostic GTM role-contrast families

The family column intentionally ignores which source took which side only for grouping. Exact source allocations, analytical class, corpus distribution, and representative positions remain inspectable in the focused evidence below.

Role-contrast family	Positions	Exact signatures	P1	Monitor	Books	Sources	Action

Focus a role-contrast family to restore its exact signatures, source orientations, distribution, and representative evidence.

Exact signature variants

These are the v83 source → role allocations that were deliberately preserved under the family abstraction.

Source orientation within family

For each source, count how often it assigns each role represented in this contrast family. This is descriptive source behavior, not a correctness score.

Book/chapter distribution

Distribution is calculated globally. The NT-book filter changes which families/evidence are displayed but does not redefine the family.

Representative positions

Use individual verses only after the family-level pattern warrants closer inspection.

Interpretation rule: a recurring role contrast indicates a recurring distinction in annotation behavior. It does not mean the roles are interchangeable, that a token is linguistically ambiguous, or that either source analysis is correct.

Representative Review Sampling Planner

Sampling is workload compression, not adjudication. v86 selects a small deterministic exemplar set from the fully comparable analytical disagreement evidence already defined in v83–v85. The default plan prioritizes recurring P1 role-contrast families, then uncovered exact source → role signatures and corpus breadth. Mapping gaps, partial coverage, duplicate-position ambiguity, and unkeyed rows are never eligible for this analytical sample; they remain in their dedicated QA queues.

Review scope Review budget NT Book Search

Build a sample to see coverage and compression.

Recommended exemplar sequence

The order is a reproducible coverage heuristic, not a ranking of grammatical importance. New role-contrast families are covered first; P1 evidence receives priority; then exact signatures and book/chapter breadth are added while the budget remains.

#	Why selected	Class / scope	Role-contrast family	Exact source → role allocation	Reference	Coverage added	Action

Coverage achieved

These metrics show what the selected exemplars cover at the pattern level; they do not claim that one exemplar proves every occurrence in its signature.

Uncovered by current budget

Anything omitted by the sample remains explicit here. Increase the budget or narrow the scope when these patterns warrant representation.

Interpretation rule: the planner optimizes representative coverage of already-established disagreement patterns. It does not decide which source is correct, does not turn majority agreement into truth, and does not replace contextual review when an exemplar is actually examined.

Representative Review Decision Ledger

Reviewed exemplars remain evidence, not automatic propagation rules. v87 records the outcome of exceptional representative reviews selected by v86. The default evidence scope is Position only. Choosing Exact signature or Role-contrast family means only that the review note may inform that broader QA pattern; it never rewrites sibling occurrences, changes source-supplied syntax, or converts majority consensus into grammatical truth. Pattern-wide mapping changes must still use Mapping Impact and the controlled approval workflow.

Review state Evidence scope NT Book Search

Queue representative exemplars from Review Sampling to begin the decision ledger.

Reference	Analytical pattern	Review outcome	Evidence scope	Reviewer note	Updated	Actions

Propagation guard: no ledger outcome modifies source syntax or other cluster members. If review reveals a reusable mapping/normalization problem, open Mapping Impact and use the existing approval pipeline rather than transferring the exemplar decision automatically.

Representative Review Evidence Synthesis QA

Synthesize reviewed exemplars without converting agreement into adjudication. v88 groups the non-propagating v87 ledger by exact source→role signature or source-agnostic role-contrast family. It distinguishes no completed review, a single reviewed exemplar, repeated reviewed exemplars with the same recorded outcome, and mixed recorded outcomes. A repeated consistent outcome means only that the reviewed exemplars currently agree with one another; it is not an automatic saturation, correctness, or corpus-wide decision.

Synthesis level Evidence state NT Book Search

Complete representative reviews in the ledger to begin cross-exemplar synthesis.

Pattern	Evidence state	Ledger breadth	Current analytical scope	Recorded outcomes	Actions

Select a synthesis group to inspect its reviewed evidence.

Outcome distribution

Counts only completed representative-review records; pending rows remain visible separately.

Evidence breadth

Reviewed books/chapters, evidence scopes, current-evidence matches, and analytical pattern size remain separate measures.

Representative review records

These records are audit evidence. Their outcome/scope values are never copied automatically to sibling positions.

Interpretation: cross-exemplar consistency can support a decision about what to inspect next, but it does not itself alter source syntax, consensus, mappings, or unreviewed positions.

Global-class rule: evidence state and outcome diversity are computed from the full ledger group first. Book/search filters decide which groups are displayed; they do not redefine a globally mixed group as locally consistent.

Representative Review Action Routing QA

Route review evidence without converting it into an automatic decision. v89 reads the v88 synthesis state, current-evidence support, and explicit v87 review outcomes and assigns a deterministic next QA route. Routes such as Mapping Impact, Source Syntax QA, contextual inspection, more representative sampling, Monitor, or No immediate action are advisory workflow destinations only. They never rewrite source syntax, mappings, consensus, or unreviewed positions.

Routing level Advisory route NT Book Search

Complete representative reviews and synthesize their evidence to generate advisory next-step routes.

Pattern	Synthesis evidence	Current support	Advisory route	Why this route	Actions

Select a routed group to inspect the evidence gate and rationale.

Evidence gate

Checks that control the advisory route. A stale or under-supported synthesis cannot unlock a broader route.

Route rationale

The route is deterministic from the current review evidence; it is not a model confidence score or grammatical verdict.

Recorded review outcomes

Outcome distribution remains visible so the routing decision can be audited against the ledger evidence.

Non-propagation rule: an Action Routing recommendation opens an existing QA workspace only. It never applies a mapping, alters source data, changes consensus status, or marks sibling occurrences as reviewed.

Action Disposition & Closure Governance QA

Track whether an advisory route has actually been addressed—without converting workflow closure into grammatical adjudication. v90 layers a small disposition ledger over v89 Action Routing. A pattern can remain Open, move In progress, be Deferred, or be Closed after its recommended QA route is handled. If the current route or its underlying evidence later changes, an old closure is surfaced for recheck instead of silently remaining closed.

Disposition level Workflow state Current advisory route NT Book Search

Action Routing evidence is required before workflow disposition can be evaluated.

Pattern	Current route	Workflow disposition	Route/evidence guard	Disposition note	Updated	Actions

Select a routed pattern to inspect its workflow disposition and drift guard.

Current route & drift guard

Closure remains valid only while the route snapshot and material evidence fingerprint still match the current routing evidence.

Disposition editor

This records workflow handling only. It never modifies source syntax, consensus, mappings, or representative-review outcomes.

Workflow dispositionDisposition note

Closing an attention route requires an explicit note. Monitor and No-action routes use their dedicated closure states.

Disposition history

When a saved disposition is changed or refreshed after route/evidence drift, the previous snapshot is retained here.

Closure semantics: “Closed” means that the recommended QA workflow was addressed and documented. It does not mean the syntactic analysis is proven correct, does not propagate a decision to sibling positions, and does not bypass Mapping Impact or Approval controls.

QA Workflow Release Gate & Governance Snapshot

Assess workflow readiness without claiming grammatical correctness. v91 summarizes the current v89 Action Routing + v90 Disposition state. Route/evidence drift blocks the gate; open or in-progress attention keeps it open; deferred attention yields conditional readiness; otherwise the selective QA workflow gate passes. Monitor and No-action routes are reported but do not become artificial blockers.

Governance level NT Book Search attention list

Not assessable

No current routing evidence loaded.The gate requires current Action Routing evidence.

Gate basis

These are objective workflow rules. They do not rank syntax sources or judge grammatical truth.

Current route mix

Advisory route distribution for the currently scoped routed groups.

Book-level workflow gate

Each book is evaluated from the current routed groups represented in that book. A cross-book pattern can therefore appear in more than one row.

Book	Routed groups	Attention	Closed/current	Open/in progress	Deferred	Drift	Gate

Gate blockers & attention workflows

Shows current route/evidence drift plus attention routes that are not validly closed. Search filters this inspection list only; it does not redefine the gate verdict.

Gate semantics: “Workflow gate passed” means that no current routed group has route/evidence drift and no current attention route is open, in progress, or deferred at the selected governance level. Search is inspection-only and does not change this verdict. It is not a certification of grammatical correctness and does not alter source syntax, mappings, consensus, or review records.

Release Manifest & Reproducibility QA

Capture the research state behind a QA gate without duplicating the corpus. v112 records deterministic, non-cryptographic integrity fingerprints plus counts/identifiers for the loaded corpus, source-syntax evidence, mapping governance, source registry, representative-review ledger, route dispositions, and the global QA release gate. Import a prior v92/v93/v94/v95/v96/v97/v98/v99/v100/v101/v102/v103/v104/v105/v106/v107/v108/v109/v110 manifest to see which components changed. Use Workspace Snapshot when an exact restorable backup is required.

Governance level Snapshot label Compare prior manifest

Current snapshot

No prior manifest loaded.Export this manifest now, or load an earlier v92/v93/v94/v95/v96/v97/v98/v99/v100/v101/v102/v103/v104/v105/v106/v107/v108/v109/v110 manifest for component-level drift comparison.

Research-state fingerprints

Order-independent deterministic fingerprints detect state drift. They are integrity identifiers, not cryptographic signatures.

Global QA gate

The manifest always captures the all-book, search-free gate at the selected governance level.

Loaded syntax sources

Syntax-bearing occurrence sources represented in the current loaded corpus.

Governance components

Counts of reusable mappings and review/governance records included in the fingerprints.

Prior-manifest comparison

Comparison is component-by-component. A changed application version is reported separately from a changed research-state fingerprint.

Component	Current	Prior	Result

Reproducibility semantics: this manifest is a lightweight integrity record, not a backup and not a scholarly certification. Fingerprints can reveal that state changed; they do not identify grammatical truth or prove data authenticity. For exact restoration/export of the research session, use Workspace Snapshot.

Research-State Drift Inspector

Explain what changed between the current research state and a prior release manifest. v95 separates evidence drift, mapping-governance drift, source/provenance metadata drift, representative-review drift, and workflow-governance drift. The comparison is descriptive only. A changed fingerprint does not imply that either state is better, worse, or grammatically correct. Because the manifest is lightweight, some fingerprint changes can be localized only to a component rather than to an exact underlying row.

Inspection domain Search detailed deltas Load prior manifest

No baseline

Load a prior release manifest.The current state is available, but drift cannot be classified without a baseline.

Drift domains

Domain classification is based on component fingerprints and is calculated before search/domain inspection filters.

Recommended refresh path

Refresh suggestions indicate which existing QA views should be rerun after a state change. They never apply corrections automatically.

Detailed manifest deltas

Numeric/status/source changes are shown where the lightweight manifests contain enough metadata. Search filters this table only and does not redefine the drift verdict.

Domain	Metric	Prior	Current	Delta / result

Drift semantics: a manifest fingerprint can prove that a component state changed relative to the selected baseline, but the lightweight manifest does not carry every underlying row. When summarized metrics remain identical despite a changed component fingerprint, v95 reports opaque content drift and directs the user to Workspace Snapshot/current workspace comparison rather than guessing which row changed.

Research-State Timeline / Drift History

Follow research-state evolution across multiple lightweight Release Manifests. v112 loads any number of v92/v93/v94/v95/v96/v97/v98/v99/v100/v101/v102/v103/v104/v105/v106/v107/v108/v109/v110 manifests, appends the live current workspace as the endpoint, deduplicates identical manifest checkpoints, and compares adjacent checkpoints chronologically. The timeline shows when component/domain fingerprints changed and how QA release-gate status evolved. Chronology is descriptive only: a later checkpoint is not assumed to be better, more correct, or more authoritative.

Inspection domain Search checkpoints / transitions Load manifests

Current only

No historical checkpoints loaded.Load two or more earlier Release Manifests to reconstruct research-state evolution. The live workspace is always included automatically as the current endpoint.

Checkpoint chronology

Sorted by manifest generatedAt. Exact duplicate manifest checkpoints are collapsed; checkpoints with distinct timestamps remain visible even when the research-state fingerprint is unchanged.

Adjacent checkpoint transitions

Each row compares one checkpoint with the next chronological checkpoint. Domain/component changes are computed from deterministic component fingerprints before inspection filters.

Transition	Research state	Changed domains	Changed components	QA gate	Application manifest

Component persistence

Shows how often each component changed between adjacent checkpoints and the first transition where change is observed.

Component	Changes	First observed change	Current fingerprint

QA gate history

Release-gate status is governance evidence only; it does not certify grammatical correctness.

Session-only history: imported manifests are kept only in this browser session and are not written to the corpus, mapping dictionary, review ledger, disposition ledger, localStorage, or Workspace Snapshot.

Timeline semantics: this history reconstructs changes only to the extent recorded by Release Manifests. Component fingerprints can prove that a component changed between checkpoints; when the lightweight manifests do not expose the changed row/field, use the v98 Drift Inspector plus Workspace Snapshot/current workspace comparison. Checkpoint order uses manifest timestamps and should be treated cautiously if files were manually edited or clocks were incorrect.

QA Gate Reopen / Regression Watch

Compare the live selective-QA gate with a historical governance checkpoint. v95 detects when the current workflow gate becomes more restrictive, when previously passed book-level gates reopen, and which research-state domains changed at the same time. “Reopened” or “more restrictive” describes QA workflow burden only; it does not mean that the newer corpus, mapping, source, or grammatical analysis is worse.

Historical baseline Search book comparisons

No baseline

Load historical Release Manifests first.State Timeline history and the v92/v93/v94/v95/v96/v97/v98/v99/v100/v101/v102/v103/v104/v105/v106/v107/v108/v109/v110 prior-manifest baseline are both eligible sources for this watch.

Global gate transition

The baseline is compared with the live global Release Gate using a fixed workflow restrictiveness order: Passed → Conditional → Attention open → Blocked.

Attention-burden deltas

Count changes are descriptive. The lightweight manifest does not contain pattern IDs for historical route groups, so count increases cannot by themselves identify which exact pattern reopened.

Concurrent research-state drift

Shows which manifest component domains changed between the selected governance baseline and the live workspace.

Interpretation

Manifest limitation: v95 can localize governance reopening globally and by book, but an exported lightweight Release Manifest does not preserve every historical route-group identifier. Use Route Disposition/current Action Routing for the exact current workflows, and Workspace Snapshot/current workspace comparison if row-level historical diagnosis is required.

Book-level gate comparison

Book classifications are computed before search. Search only narrows the displayed rows and cannot change the global verdict or total reopened-book count.

Book	Baseline gate	Current gate	Trend	Baseline attention	Current attention	Baseline drift	Current drift

Watch semantics: this module detects governance reopening relative to the selected baseline, not errors. New evidence can legitimately reopen a previously passed workflow. A more restrictive current gate means only that the documented selective-QA process currently requires more attention than it did at the baseline.

Baseline Supersession Readiness QA

Decide whether the live research/governance state is ready to replace the active governed QA baseline. v100 evaluates the current Release Gate, whether the reproducible research-state fingerprint actually changed, concurrent component drift, and book-level gate movement. It never promotes a baseline automatically. An eligible candidate is handed to Official QA Baseline Governance, where an explicit promotion/supersession reason is still required.

No active baseline

Establish a governed QA baseline first.Readiness cannot be evaluated without an active Official or Provisional comparison baseline.

Baseline → live state

Exact manifest fingerprints and gate states are compared without ranking grammatical correctness.

Readiness checklist

Each gate is explicit; no opaque readiness score is used.

Research-state domains changed

Baseline-governance designation itself is excluded from the research-state fingerprint, so changing which checkpoint is “official” does not manufacture a research-state change.

Governance interpretation

Book-level gate movement since active baseline

Book comparisons are descriptive workflow evidence. A newly represented book is reported as not comparable rather than automatically “better” or “worse.”

Book	Baseline gate	Current gate	Trend	Baseline attention	Current attention	Baseline drift	Current drift

Supersession semantics: “Official candidate” means the current workflow gate is Passed and the reproducible state differs from the active baseline. “Provisional candidate” means the current gate is Conditional. Open, Blocked, or Not-assessable states are never eligible. If the live research-state fingerprint is unchanged, v98 recommends no supersession even when the manifest was regenerated at a later time.

Baseline Lineage Integrity QA

Audit the governed QA-baseline registry as a lineage graph rather than assuming that promotion history is structurally valid. v100 verifies active-state uniqueness, record IDs, predecessor/successor links, cycles, timestamps, manifest self-consistency, gate eligibility, and the reciprocal supersession metadata introduced for new promotions. The audit is read-only: it never repairs or rewrites baseline history automatically.

No baseline history

No governed QA baseline records are currently stored.Promote an eligible Official or Provisional baseline before lineage integrity can be evaluated.

Governance lineage

Chronological record sequence. New v98 promotions preserve both predecessor and successor pointers; older records may legitimately lack the newer reciprocal predecessor field and are reported as legacy metadata rather than silently fabricated.

Integrity findings

Errors indicate structural contradictions. Warnings indicate incomplete/legacy metadata or governance conditions that deserve inspection but do not prove corruption.

Record-by-record integrity

The manifest fingerprint check recomputes the manifest’s combined research-state fingerprint from its stored component fingerprints. It does not authenticate the file cryptographically.

Record	Current state	Original promotion	Promoted	Supersedes	Superseded by	Gate	Manifest integrity	Lineage integrity

Lineage semantics: a clean audit means the stored baseline-governance history is internally coherent according to these structural rules. It does not certify grammatical correctness, source provenance, scholarly agreement, or the cryptographic authenticity of an imported registry.

Baseline Registry Reconciliation Planner

Translate v100 lineage-integrity findings into an auditable repair plan without changing the registry. Exact proposals are limited to metadata values already determined by the stored reciprocal evidence or to removal of impossible self-links. Evidence-guided proposals identify a plausible action that still requires human confirmation. Manual-only cases deliberately refuse to infer missing governance history, overwrite a mismatched manifest fingerprint, or choose among ambiguous imported branches.

No reconciliation needed

No lineage findings are currently available.Run Baseline Lineage QA after baseline history exists.

Proposal class Search plan

Safe reconciliation workflow

The planner intentionally stops before mutation.

Export the Baseline Registry firstPreserve the exact pre-reconciliation history as a rollback/audit artifact.

Resolve exact proposals firstThese are the only cases where the stored registry already determines the proposed metadata value.

Confirm evidence-guided casesInspect chronology and source manifests before adopting the suggested relationship.

Quarantine/manual-review ambiguous casesDo not manufacture IDs, timestamps, promotion classes, or manifest fingerprints merely to make the graph look clean.

Re-import explicitly corrected registry and rerun Lineage QAThe planner does not apply a patch itself.

Proposal semantics

Classification is about how much the stored evidence determines—not about severity.

Exact metadata proposalA concrete field/value is already implied by reciprocal stored evidence or by an impossible self-link. Still review before editing externally.

Evidence-guided reconciliationA plausible repair path exists, but adopting it would make a governance inference that requires human confirmation.

Manual / quarantineDo not guess. Recover source records, original manifests, or governance evidence first.

Reconciliation proposals

Search/class filters affect only this table. They never change the underlying Lineage QA verdict.

Class	Record	Integrity finding	Proposed action	Patch preview	Rationale / guard

Non-destructive guarantee: v99 does not call the Baseline Registry writer, does not set localStorage, does not delete records, and does not alter manifests. Exported JSON is a plan only. To make a real correction, edit/reconstruct the registry outside this planner, import it through QA Baseline, and rerun Baseline Lineage QA.

Baseline Registry Repair Transaction Workspace

Stage and commit only v100 reconciliation proposals classified as Exact. Selection never includes evidence-guided or manual/quarantine cases. Before commit, v100 rechecks every selected proposal against the current registry, applies the typed field/value patches to a cloned registry, reruns Baseline Lineage QA on that prospective registry, blocks stale/conflicting/ineffective patches and any newly introduced structural error, then writes only the approved exact fields. A one-step checkpoint preserves the exact pre-transaction registry for rollback.

Select exact repairs

No exact reconciliation proposal is selected.Select one or more deterministic field/value proposals, then inspect the prospective lineage audit.

Transaction note

Current → prospective lineage audit

The prospective audit runs entirely against a cloned registry before storage is touched.

Transaction safety gates

Commit stays disabled until every gate passes.

Exact repair proposals

Only Exact proposals are selectable. Their `before` values are revalidated immediately before commit; stale selections are blocked.

Select	Record	Finding	Patch	Current status	Rationale / guard

One-step rollback checkpoint

Only the most recent successful repair transaction is rollback-eligible.

No repair checkpoint
No successful v112 repair transaction has created a rollback point in this browser.

Commit controls

A transaction note is required. Guided/manual reconciliation never becomes selectable here.

Transaction boundary: the repair workspace may write only the Baseline Registry storage key and its dedicated one-step rollback-checkpoint key. It never changes occurrence corpus data, source syntax, mapping rules, representative-review records, route dispositions, or Release Manifests. If the registry has changed after the last repair, automatic rollback is refused rather than overwriting newer work.

Baseline Repair History Integrity QA

Audit the persistent v101/v102 repair-history ledger itself. v102 checks event/transaction identity, commit↔rollback reciprocity, rollback fingerprint reversal, patch consistency, chronology, deterministic event fingerprints, explicit previous-event links for new v102 events, and registry-fingerprint continuity between adjacent repair events. A continuity gap is reported as a warning—not an error—because legitimate baseline promotion/import may change the registry between repair transactions without creating a repair-history event.

No repair history

No persistent repair-history events are currently stored.The first successful repair transaction creates this ledger.

Finding level Search audit

Recorded event sequence

Continuity compares each event’s before-fingerprint with the preceding event’s after-fingerprint. A gap can represent legitimate non-repair registry work and therefore remains a warning.

Integrity findings

Errors are contradictions internal to the repair ledger. Warnings include legacy v101 records without new v102 event-chain fingerprints and continuity gaps that may reflect external registry changes.

Event-by-event integrity

Event fingerprints are deterministic integrity identifiers, not cryptographic signatures. Older v101 events legitimately lack them and are labeled Legacy.

Event	Kind	Time	Related commit	Fingerprint transition	Patch integrity	Event fingerprint	Previous-event link	Audit state

Audit semantics: a clean repair-history ledger means the stored transaction/rollback metadata is internally coherent under these checks. It does not authenticate browser storage cryptographically, prove the historical Baseline Registry contents beyond the stored fingerprints, or certify grammatical correctness.

Baseline Repair History Reconciliation Planner

Translate v110 repair-history integrity findings into explicit reconciliation proposals without rewriting history. Exact proposals are restricted to derived/reciprocal metadata that the stored event ledger already determines—for example, `patchCount` from the stored patch array or one missing half of an already-matching predecessor pointer. Event-fingerprint mismatches, rollback contradictions, duplicate identities, chronology errors, ambiguous/orphan relationships, and continuity gaps never become automatic patch proposals.

No history findings

No repair-history reconciliation can be planned yet.The repair-history ledger is empty or the integrity audit has no finding.

Proposal class Search plan

Proposal classes

Classification describes how strongly the stored history determines a corrective action.

Exact metadata proposalThe detailed stored event content uniquely determines a derived or reciprocal metadata value. Review is still required before any later repair transaction.

Evidence-guidedA plausible normalization or backfill exists, but it would add retrospective audit metadata or make an inference about historical identity.

Manual / quarantineDo not guess. Recover the original transaction export/checkpoint/registry evidence or quarantine the affected event.

InformationNo repair is implied—for example, a continuity gap can legitimately reflect non-repair baseline governance between repair events.

Recommended workflow

The planner remains read-only.

Export Repair History and History QA firstPreserve the current audit evidence before any external edit or future repair feature is used.

Apply only exact derived metadata where justifiedNever use an exact summary-field repair to conceal a deeper event contradiction.

Confirm guided retrospective metadataFor legacy events, a newly calculated event fingerprint can attest only to the event as stored now; it cannot prove the event was untampered before the backfill.

Quarantine contradictionsRollback reversals, duplicate IDs, mismatched fingerprints, or chronology conflicts require original evidence—not reconstructed guesses.

Rerun History Integrity QAA later explicit repair should be validated against the full ledger, not merely the local finding that motivated it.

History reconciliation proposals

Inspection filters affect this table only; they do not alter the underlying v103 History Integrity QA verdict.

Class	Event	Integrity finding	Proposed action	Patch preview	Rationale / guard

Non-destructive guarantee: v103 does not write the repair-history ledger, does not change Baseline Registry state, does not create event fingerprints retroactively, and does not modify transaction/rollback identities. Exported JSON is an advisory reconciliation plan only.

Repair-History Metadata Transaction Workspace

Stage and commit only v104 reconciliation proposals classified as Exact. Before commit, selected before-values are rechecked, patches are applied to a cloned Repair History ledger, existing event fingerprints are deterministically refreshed only for already-fingerprinted events whose payload changed, and the complete Repair History Integrity QA is rerun. Legacy events without event fingerprints remain legacy.

Select exact history repairs

No Exact history proposal is selected.Select deterministic metadata repairs and inspect the prospective History QA.

Transaction note

Current → prospective History QA

The cloned audit uses the unchanged live Baseline Registry fingerprint.

Transaction safety gates

Commit stays disabled until every gate passes.

Selectable Exact history repairs

Dependent event-fingerprint refreshes are shown only when an affected event already has a fingerprint.

Select	Event	Finding	Patch	Status	Rationale / guard

One-step history rollback checkpoint

The exact pre/post history bytes are retained for the latest successful metadata repair.

No history-repair checkpoint
No successful v112 repair-history metadata transaction has created a rollback point.

Commit controls

A transaction note is mandatory. Guided/manual/informational proposals are never selectable.

Write boundary: v104 may write only the persistent Repair History ledger and its dedicated one-step history-metadata checkpoint. It never changes the Baseline Registry, baseline repair checkpoint, corpus, source syntax, mapping, reviews, dispositions, or Release Manifests. Rollback is refused if Repair History changed after the transaction.

Dual-Gate Release Readiness

Combine two independent release dimensions without hiding either one. The QA Workflow Gate asks whether selective syntax-review routes are dispositioned and current. The Governance Integrity Gate asks whether the baseline/repair-history machinery that records those decisions is internally coherent. v106 derives release readiness from the explicit pair. “Dual-gate release ready” means both workflow dimensions pass; it is not a certification that every grammatical analysis is correct.

Not assessable

One or both release dimensions are unavailable.Open the underlying gates for detail.

Search book readiness

QA Workflow Gate

Selective syntax QA disposition. No grammatical correctness claim.

Governance Integrity Gate

Baseline/repair-history governance integrity. No syntax correctness claim.

Combination matrix

The derived verdict uses explicit precedence: Blocked → Attention → Not assessable → Conditional → Ready.

Book-level release readiness

Each book’s existing syntax workflow gate is combined with the same global Governance Integrity state. Search filters this table only; it cannot alter global readiness.

Book	Syntax workflow gate	Governance integrity	Combined readiness	Syntax attention	Syntax drift

Required handoffs

Only non-passed dimensions are listed. These links open the underlying gate rather than attempting to fix anything here.

Release semantics: v106 is a workflow/governance readiness layer. It does not convert consensus into truth, does not rank sources, does not claim exhaustive human review, and does not certify grammatical correctness. A Ready result means only that the project’s selective QA workflow gate and governance-integrity gate are both in their documented Passed states.

Release Decision Record / Handoff Package

Freeze the exact release-review state into one lightweight handoff record. v108 records the reproducible research-state fingerprint, component fingerprints, QA Workflow Gate, Governance Integrity Gate, Dual-Gate Readiness, active governed baseline, Baseline Registry fingerprint, Repair History endpoint, book-level readiness, and required gate handoffs. The stable candidate fingerprint deliberately excludes the export timestamp, release label, and decision note, so regenerating the same state produces the same candidate identity.

Release label Decision / handoff note

Not assessable

Current release readiness is not assessable.The record can still be exported as a handoff snapshot.

Candidate identity

Stable identifiers are derived from state/gate inputs only; human label/note and export time are metadata outside the fingerprint.

Gate state

The two gates remain visible independently even though the decision record also carries their combined readiness.

Governed baseline & registry

Captures the comparison anchor and the current baseline-registry endpoint used by governance QA.

Package inventory

The record points to/repeats lightweight summaries; it is not a replacement for Workspace Snapshot.

Required handoffs

Non-ready gate dimensions are preserved as explicit handoffs rather than being hidden by the candidate record.

Book-level readiness snapshot

This is copied from the Dual-Gate Readiness model at record-generation time.

Book	Syntax gate	Combined readiness

Decision-record semantics: this is a reproducibility and release-handoff artifact, not a certificate. A Ready candidate means the documented QA Workflow Gate and Governance Integrity Gate both pass. It does not certify that every grammatical interpretation is correct, that every token was manually reviewed, that source consensus proves truth, or that source provenance has been cryptographically authenticated.

Release Candidate Delta / Handoff Comparison

Compare a prior exported Release Decision Record with the live frozen candidate. v108 first recomputes the prior record’s stable candidate fingerprint. A mismatch blocks trusted comparison rather than silently accepting edited/tampered candidate state. When valid, the comparison localizes candidate-identity change, research/component drift, gate/readiness changes, governed-baseline and registry-endpoint changes, book-level readiness differences, and handoffs added/removed. “Changed” is descriptive; v108 does not label the newer candidate better or worse.

Load prior Decision Record JSONNo prior record loaded

No prior candidate

Load a v107/v108 Release Decision Record.The live candidate is frozen when this dialog opens.

Candidate / gate state

Prior → live values. Human label/note differences are excluded because they are not part of technical candidate identity.

Research component fingerprints

Component-level fingerprint changes localize the reproducible research/governance input areas that differ.

Book-level readiness delta

Book union is computed before display. A book missing from one record is reported as Added/Removed rather than assigned an invented prior/current status.

Book	Prior syntax gate	Live syntax gate	Prior combined	Live combined	Delta

Handoff delta

Required gate handoffs are compared by module/title/kind. Added or removed handoffs describe workflow state changes, not quality judgments.

Comparison limits: Decision Records are lightweight. If the research-state or component fingerprints changed, use the matching prior Release Manifest with Drift Inspector / State Timeline for detailed component metrics and opaque-content diagnosis. v108 does not reconstruct row-level corpus changes from a Decision Record alone.

Release Candidate Decision Timeline

Follow technical release candidates across multiple Decision Records rather than comparing only one pair. v109 validates every imported record’s stable candidate fingerprint, sorts valid observations by generation time, appends the frozen live candidate, and collapses only consecutive observations with the same candidate fingerprint. This preserves a genuine return to an earlier technical state (A → B → A) while avoiding duplicate checkpoints caused only by repeated labels/notes/exports of A.

Load Decision Records

Live candidate only

Load prior Decision Records to build release-candidate history.The current workspace candidate is included as the live endpoint.

Candidate chronology

Consecutive duplicate technical candidates collapse into one checkpoint with all human decision-record observations retained underneath.

Import integrity

Invalid JSON, unsupported records, and candidate-fingerprint mismatches are rejected from chronology but remain visible here.

Technical candidate transitions

Transitions are descriptive. Component, book, gate, baseline, registry, and handoff changes are counted without improvement/regression labels.

Transition	Candidate	Research	Components	QA gate	Governance gate	Readiness	Baseline/registry	Books	Handoffs

Timeline semantics: multiple Decision Records with the same stable candidate fingerprint are observations of the same technical candidate. Human labels, notes, and export timestamps remain visible metadata but do not create technical transitions. A repeated fingerprint after an intervening different candidate is preserved as a return to a prior state. The timeline does not rank candidates or certify grammatical correctness.