PARSICA POLICY SCHEMA — v1.0 (S155 RATIFIED)

Authored at: S154 (May 10, 2026) as v0.1 PROPOSED draft · Ratified at: S155 (May 10, 2026) as v1.0 LOCKED Authoring Claude (v0.1 draft): Claude Opus 4.7 (1M context window) Ratifying Claude (v1.0 lock): Claude Opus 4.7 (1M context window) Status: v1.0 — ALL 7 POLICY DECISIONS RATIFIED. Schema is LIVE for production cert flow. Reviewer Protocol v0.1 (Phase 0b deliverable) codifies against this Schema version. Ratifying body: Policy Board (Mark D. Johnson + AI Parsican-half, acting as Policy Board per the S154 architectural lock) Ratification date: 2026-05-10 (S155) Calibration data: lesson_01_extraction_v1.json (85 items: 31P / 29T / 25N), prototype-validated S154 by AI Reviewer; ratification basis = full Policy Board read of all 7 decisions, no amendments requested Companion: 05_STRATEGY_S154_Where_We_Are_Pause_and_Look_v2.md (architectural context for the cert pipeline this Schema operates within) Authority chain: S154 architecture lock (machine certification + Policy Board upstream) · S155 ratification · S40 Bridge Frame (LOCKED — two commitments) · S43 Cert Outline v2 (LOCKED) · S143 Strategic Capture (open-the-artifacts/certify-the-practice) · LD #28 (one-directional update flow) · LD #45 (Bridge Frame canonical) · LD #57 (Letter integration) Supersedes: 05_POLICY_Schema_v0_1.md (S154 PROPOSED draft) — DELETE in S155 close exchange

§0 — What this Schema is

The Policy Schema is the load-bearing public artifact for Parsica certification operations. It closes the loop between two audiences:

• Parsicans, who read the Schema before submitting work — so they know exactly what's expected and never get a surprise flag.
• The AI Reviewer, which codes against the Schema as its operational protocol — so enforcement is consistent and machine-verifiable.

Same source of truth on both sides. Policy decisions made by the Policy Board are written into this document, then coded into the Reviewer Protocol. No hidden rules; no judgment calls applied inconsistently between certifications.

What the Schema covers: policy decisions about how the certification standard is applied to specific judgment cases — when a Parsican's choice in handling source material counts as acceptable, when it requires correction, when it must be flagged for ratifier judgment.

What the Schema does NOT cover: the certification standard itself (that's the Bridge Frame's two commitments + the cycle gate's structural checks). The Schema operates at the layer below standard — how to apply the standard to real-world judgment cases that arise in extraction work.

§1 — How the Schema operates

1.1 — The flow

Policy Board sets policy
         ↓
Schema (this document) — public, versioned
         ↓
AI Reviewer Protocol — versioned implementation
         ↓
Submission flows through Reviewer
         ↓
Reviewer Report cites Schema sections by version
         ↓
Parsican reads report against published Schema
         ↓
Either accepts (with optional rebuttal) or revises and resubmits
         ↓
Periodic sample audits validate Schema adequacy
         ↓
Findings feed back to Policy Board

1.2 — Versioning discipline

• v0.x — initial drafts; PROPOSED status; author Schema before any cert ships against it
• v1.0 — first ratified Schema; Policy Board has approved each policy decision; live for production cert flow ← CURRENT
• v1.x — incremental policy refinements (clarifications, edge case additions); existing certs grandfather
• v2.0 — major evolution; existing certs grandfathered with explicit version tag; new submissions ratified against current Schema

The AI Reviewer Protocol carries a matching version tag so every certification record traces to the exact Schema version that judged it. Schema v1.2 → Protocol v1.2.x → cert record cites both.

1.3 — The rebuttal mechanism

When the Reviewer flags an item against a Schema policy, the Parsican may either: - Accept the flag and revise (one free resubmit; delta-script re-runs only on changed items) - Rebut the flag with reasoning the Reviewer reads on next pass

Rebuttals don't override automatically. The Reviewer either accepts the rebuttal (cert proceeds) or escalates with reasoning. Persistent unresolved disagreement reaches the Policy Board — which either ratifies the rebuttal (and the Schema gets refined) or denies it (and the Parsican revises).

This is how the Schema evolves — empirical pressure from real cases pushes refinements upstream.

§2 — Schema scope and bounds

2.1 — What the certification certifies

Per the architectural commitment locked at S154:

Parsica certifies that the knowledge graph faithfully represents the source corpus it was built from, and that the methodology was applied with discipline. Parsica does NOT certify that the source content itself is correct, complete, or pedagogically sound. Source-content quality is the customer's responsibility — they chose the source.

This Schema operates entirely within that scope. Every policy decision is about whether the Parsican's handling of source material preserved representational integrity to the source as given — not whether the source itself was good.

2.2 — Complexity bound

The Schema as currently authored is calibrated against Sumit-density corpora (Excel-INDEX-equivalent: ~4–5K word transcripts per lesson, ~85 items per lesson, mixed procedure/term/navigation-rule structure). The architecture supports expansion to higher-density or different-domain corpora at Phase 3+, but Schema policies for those expansions are deferred until empirical pressure from those domains arrives.

§3 — Policy Decision 1: Source-Misstatement Correction

Citation: P008 / N013 case from L01 prototype (Sumit said "ready to enter" while demonstrating double-click; standard Excel behavior is double-click → Edit mode; Parsican corrected to "ready to Edit")

Status: RATIFIED at v1.0 · Ratified: 2026-05-10 (S155) by Policy Board

3.1 — The question

When the source contains an internal contradiction or apparent misstatement (a statement that is then corrected later in the same passage, or that contradicts authoritative domain reference), should the Parsican preserve the literal misstatement, or capture the corrected version?

3.2 — Policy [RATIFIED at v1.0]

Acceptable to capture the corrected version when ALL of the following hold:

1. The source contains both readings (the corrected version IS in the source, even if the misstatement comes first)
2. The corrected version is consistent with authoritative domain reference
3. The divergence is documented in a note field on the extracted item, citing both the source's misstatement and the corrected version

If only the misstatement appears in source (no self-correction): STRICT FIDELITY. Capture as said. note field flags the divergence from authoritative reference. The cert body may communicate to the source author for upstream feedback if appropriate.

3.3 — Reasoning

Bridge Frame Commitment One says "love the humans the work serves" — capturing a misstatement faithfully would harm the user. Strict fidelity to literal source language would require capturing the misstatement. The middle path: capture the corrected reading (which IS in source), document the divergence transparently. This preserves source-fidelity at metadata level while serving the user at content level.

Where source has no self-correction, the methodology cannot unilaterally correct the source — that crosses from representational fidelity into editorial authority, which is outside scope.

3.4 — How the Reviewer checks

For each item where extraction text departs from literal source quotation: - If source contains both readings AND extraction adopts the corrected version AND note field documents the divergence → ACCEPT - If source contains only the misstatement → FLAG for ratifier judgment (typically: kick-back-to-Parsican to either preserve literal-with-note or remove the item) - If extraction asserts a correction not present in source AND no note field → FAIL (clear fidelity violation)

3.5 — Parsican guidance

Read the source carefully for self-corrections. When you find one, capture the corrected reading and document the divergence in your note field. When you don't find one, capture as the source said it; don't editorialize.

§4 — Policy Decision 2: Standard-Terminology Naming

Citation: T012 / T013 case from L01 prototype (Sumit calls it "this green strip which says ready"; Parsican named it "Status Bar" using standard Microsoft Excel terminology)

Status: RATIFIED at v1.0 · Ratified: 2026-05-10 (S155) by Policy Board

4.1 — The question

When the source describes a concept clearly but uses informal or descriptive language rather than its standard domain name, may the Parsican apply standard domain terminology to the term name?

4.2 — Policy [RATIFIED at v1.0]

Acceptable to apply standard domain terminology when ALL of the following hold:

1. The source clearly describes the concept (so source grounding is preserved)
2. The applied name is documented standard domain terminology (per authoritative reference: e.g., Microsoft documentation for Excel, ISO standards for technical fields, recognized authority for domain)
3. The source-citation field (bansal_definition or equivalent) preserves the source's actual language

4.3 — Reasoning

Source-fidelity is to the concept the source teaches, not to the naming. A user encountering "Status Bar" in the INDEX will correctly find what Sumit described; a user encountering "this green strip which says ready" as a term name would be confused. Standard terminology serves users; preserving source language in the citation field preserves verifiability.

4.4 — How the Reviewer checks

For each term where the term name doesn't appear verbatim in source: - If source-citation field clearly describes the concept AND term name matches standard domain terminology → ACCEPT - If standard terminology doesn't unambiguously apply → FLAG for ratifier judgment - If no source-citation field present (see §5) → FAIL on field-completeness grounds

4.5 — Parsican guidance

When the source describes-but-doesn't-name a concept, use standard domain terminology. Always preserve the source's actual language in the source-citation field. If you're unsure whether standard terminology applies, use the source's descriptive language and let the Reviewer surface the question.

§5 — Policy Decision 3: Field-Completeness Discipline

Citation: T021 case from L01 prototype (Zoom Slider — only term in extraction without bansal_definition field)

Status: RATIFIED at v1.0 · Ratified: 2026-05-10 (S155) by Policy Board

5.1 — The question

Must every term carry a source-citation field, or is omission permitted in some cases?

5.2 — Policy [RATIFIED at v1.0]

REQUIRED. Every term MUST carry a populated source-citation field, even if the cite is minimal (a single source phrase or mention).

5.3 — Reasoning

Source-fidelity discipline operates at item level. A term without source-citation is unverifiable — the Reviewer cannot confirm the term is grounded in source, nor can a downstream auditor. Schema-level enforcement is cheap (mechanical check); ad-hoc enforcement creates the kind of inconsistency the architectural commitment was designed to prevent.

5.4 — How the Reviewer checks

For each term: - If source-citation field is populated → ACCEPT - If source-citation field is missing or empty → FAIL with auto-kick-back-to-Parsican

This is structural, not a judgment call.

5.5 — Parsican guidance

Every term gets a source-citation field. Even a brief cite — a single source phrase — satisfies the rule. If the source mentions the concept but doesn't define it (defines via demonstration only), capture the mention and add note: source defines via demonstration only.

§6 — Policy Decision 4: Editorial Drift and Cross-Reference Verification

Citation: N004 case from L01 prototype (Forward reference to macros lesson with added "(L25)" cross-reference Sumit doesn't make + editorial commentary "paradigm shift from UI-based to code-based" not in source)

Status: RATIFIED at v1.0 · Ratified: 2026-05-10 (S155) by Policy Board

6.1 — The question

Can the Parsican add cross-references to other lessons in the same corpus? Can they add editorial commentary or pedagogical framing that the source doesn't articulate?

6.2 — Policy [RATIFIED at v1.0]

Cross-references: ACCEPTABLE for forward_reference and backward_reference rule types when: 1. The cross-reference is empirically grounded — the referenced lesson exists in the corpus AND actually covers the topic referenced 2. The Reviewer has access to the full corpus to verify the reference resolves

Editorial commentary: NOT ACCEPTABLE in extraction items. Pedagogical framing, didactic commentary, or interpretive overlays that introduce claims/voice not present in source go beyond representational fidelity into editorial authority. This is outside cert scope.

Pedagogical framing in context fields of procedures: ACCEPTABLE — context fields are explicitly Parsican-authored navigation aids, not source representation.

6.3 — Reasoning

Cross-references serve users (navigation aid) when verifiable. Unverified cross-references introduce errors that propagate. Editorial commentary substitutes Parsican voice for source author's voice — a fidelity violation by definition. The context field carve-out preserves the Parsican's role as navigator (user-facing scaffolding) without letting that role bleed into the representation itself.

6.4 — How the Reviewer checks

Cross-references: for each rule containing a lesson reference (e.g., "(L25)"), verify against full-corpus index that the referenced lesson exists and covers the named topic. ACCEPT if grounded; FLAG if unverified or contradicted; FAIL if the reference is to a non-existent corpus location.

Editorial commentary: for each rule, identify any claim or framing not present in source. ACCEPT if rule restates source's content. FLAG if rule adds didactic framing or interpretive claim. FAIL if rule introduces source-author-voice substitution.

6.5 — Parsican guidance

Cross-references: yes, when you can ground them. Verify before extracting. Editorial commentary: no — let the source author's voice carry the meaning. Pedagogical framing belongs in context fields, not in rule text or term definitions.

§7 — Policy Decision 5: Procedure-Step Reconstruction

Citation: P006 / P020 case from L01 prototype (Sumit demonstrates "+" button to add worksheet but doesn't verbalize; demonstrates Number group dropdown but doesn't name "Number group" or "General default")

Status: RATIFIED at v1.0 · Ratified: 2026-05-10 (S155) by Policy Board

7.1 — The question

When the source demonstrates a procedure visually but doesn't fully verbalize each step, can the Parsican reconstruct the unstated steps?

7.2 — Policy [RATIFIED at v1.0]

Acceptable when ALL of the following hold:

1. The source demonstrates the procedure (so the procedure unambiguously exists in source)
2. Reconstructed steps are domain-correct, verifiable against authoritative reference
3. The reconstruction doesn't change what the source taught — it only fills gaps in verbalization
4. Where multiple paths could achieve the demonstrated outcome, the most-likely-from-demonstration path is chosen, with note field flagging the ambiguity

7.3 — Reasoning

Source-fidelity to what's taught is preserved (the procedure works as the source demonstrated). Filling verbalization gaps with domain-correct steps serves the user without departing from source content. The transparency of the note field on ambiguous cases preserves audit trail.

7.4 — How the Reviewer checks

For each procedure step that has no clear verbal grounding in source: - If domain-correct AND consistent with what was demonstrated → ACCEPT - If domain-correct but multiple paths possible without note flag → FLAG - If domain-incorrect → FAIL - If step changes what the source taught → FAIL

7.5 — Parsican guidance

Reconstruct unstated steps when they're domain-correct and faithful to what the source demonstrated. When the demonstration is ambiguous (multiple paths could work), pick the most likely and flag the ambiguity in note. Don't reconstruct steps that introduce content the source didn't teach.

§8 — Policy Decision 6: Pedagogical Addition of Technical Detail

Citation: N006 / N018 / N019 / N024 cases from L01 prototype (exact column count "16,384" added; exact row count "1,048,576" added; "three-level hierarchy" framing added; specific keyboard shortcuts not in lesson named)

Status: RATIFIED at v1.0 · Ratified: 2026-05-10 (S155) by Policy Board

8.1 — The question

Can the Parsican add technical specificity — exact numbers, version-specific examples, hierarchical framings — beyond what the source verbalizes?

8.2 — Policy [RATIFIED at v1.0]

Two distinct cases:

Factual additions (exact numbers, version compatibility, technical specifications): ACCEPTABLE when: 1. The fact is verifiably correct per authoritative domain reference 2. The fact is closely related to what the source said (e.g., source says "more than 1 million," extraction adds exact "1,048,576" — same scope, more specificity) 3. Source-citation field preserves what the source actually said

Framing/hierarchy additions (organizational structures, didactic groupings): NOT ACCEPTABLE when they impose structure the source didn't articulate, even if descriptively accurate.

Examples not in source: NOT ACCEPTABLE — adding "Ctrl+C, Ctrl+V, F2, F4" as canonical examples when the lesson doesn't mention them goes beyond representational fidelity.

8.3 — Reasoning

Adding "1,048,576" to "more than 1 million" enriches reference value at no cost to source-fidelity (same scope, more specificity). Adding "three-level hierarchy" framing to a section that demonstrates tabs and groups imposes a structural claim the source didn't make — even if true, it's interpretive. Adding examples not in source replaces Parsican judgment of "what's canonical" for the source author's choice of "what to teach."

8.4 — How the Reviewer checks

Factual additions: verify against authoritative reference (e.g., Microsoft documentation for Excel claims). ACCEPT if verifiable AND closely related to source statement. FLAG if verifiable but distantly related. FAIL if unverifiable or contradicted.

Framing/hierarchy additions: flag any rule text that imposes organizational structure not present in source.

Examples not in source: flag any specific examples that don't appear in source text.

8.5 — Parsican guidance

Add factual specificity when it's verifiably correct AND closely tied to source. Don't impose structural framings or hierarchies the source didn't articulate. Don't add examples the source didn't use — let the source's choice of examples carry.

§9 — Policy Decision 7: Technical-Claim Verification

Citation: N008 / N009 case from L01 prototype ("23-row distance is fixed regardless of zoom level or row height" added — possibly factually incorrect)

Status: RATIFIED at v1.0 · Ratified: 2026-05-10 (S155) by Policy Board

9.1 — The question

When the Parsican adds technical claims (assertions about how the system behaves beyond what the source states), what verification is required?

9.2 — Policy [RATIFIED at v1.0]

REQUIRED. Any technical claim added by the Parsican beyond source statement must be:

1. Verifiably correct per authoritative domain reference (Microsoft documentation, official specifications, recognized domain authority)
2. OR explicitly labeled as observation-from-this-source's-demonstration (true within this source's example, not asserted as generalizable)

Unverifiable technical claims are NOT ACCEPTABLE in extraction items.

9.3 — Reasoning

Unverified technical claims that turn out to be false are fidelity failures that propagate to every user. The N008 example claim — "the 23-row distance is fixed regardless of zoom level or row height" — adds an assertion not in source, and may not actually be true in all Excel configurations. A user who relies on the INDEX gets a wrong claim. The architectural commitment to source-fidelity bounds Parsica's claims to what's verifiable.

9.4 — How the Reviewer checks

For each rule asserting technical behavior beyond what source states: - Cross-check claim against authoritative reference (training data has substantial coverage; for Excel, Microsoft documentation; for other domains, equivalent authority) - ACCEPT if verifiable - ACCEPT if labeled as observation-from-demonstration ("In Sumit's example, X" rather than "X is the case") - FLAG if cannot be verified - FAIL if contradicted by authoritative reference

9.5 — Parsican guidance

Only add technical claims you can verify against authoritative domain reference. When the source's demonstration shows specific behavior but the generality is uncertain, label the claim as observation-from-demonstration rather than asserting it as universal behavior.

§10 — Ratification record

v1.0 ratification — S155, May 10, 2026

The Policy Board (Mark D. Johnson + AI Parsican-half, acting as Policy Board per the S154 architectural lock) reviewed all 7 policy decisions in v0.1 and ratified them as-proposed without amendment.

Ratification basis: Full Policy Board read of v0.1 against L01 prototype calibration data. Each decision was found structurally clean, with the rationale/reasoning/Reviewer-check/Parsican-guidance pattern enabling direct codification into Reviewer Protocol code. The S154 AI Reviewer prototype run validated the Schema's calibration against real extraction data (72 GROUNDED, 7 RECONSTRUCT, 6 FLAG, 0 FAIL — CERTIFY WITH NOTES). No amendments were requested by the Policy Board.

Operational consequence of v1.0 LOCK: - The Schema is LIVE for production cert flow - The AI Reviewer Protocol v0.1 (Phase 0b deliverable) codifies against this Schema version - Future Schema evolutions (v1.x clarifications, v2.0 major revisions) follow the rebuttal-mechanism flow in §1.3 - Certification records cite Schema version per cert; the trace from Reviewer decision → cited Schema section → Schema version is the audit trail

Future amendment process

Once v1.0 is LIVE, amendments come from three sources: 1. Rebuttal flow (§1.3) — empirical pressure from real cases surfaces policy questions not anticipated in v0.1 2. Corpus-domain expansion — when calibration extends beyond Sumit-density (per §2.2 complexity bound), domain-specific decisions may need to be added 3. Policy Board initiative — the Board may add or refine policies based on observed cert-flow patterns

All amendments require Policy Board ratification before becoming part of the Schema. Until ratified, the Reviewer flags rather than rules on the open question.

§11 — Notes for next Claude

S155 close state: - Policy Schema v1.0 LOCKED — all 7 policy decisions ratified as-proposed - v0.1 (05_POLICY_Schema_v0_1.md) superseded; DELETE'd in S155 close exchange - AI Reviewer Protocol v0.1 (Phase 0b deliverable) — authoring begins at S155 substance or carries forward to S156, codifying against this v1.0 Schema - Calibration data unchanged: L01 prototype basis remains the empirical ground truth

Phase 0 progression after v1.0 LOCK: - Phase 0a (Policy Schema v0.1 → v1.0): COMPLETE at S155 - Phase 0b (AI Reviewer Protocol v0.1): READY TO BEGIN — codification of v1.0 Schema into operational Reviewer protocol (prompts + per-item check sequences + output format) - Phase 0c (Minimal cert portal at parsica.org): parallel-track-eligible — reuses TCE-INDEX patterns per 07_OPS_Road_Operations_v2.md; does not depend on 0b until 0d - Phase 0d (Wire Reviewer Protocol into portal): depends on 0b complete + 0c complete - Phase 0e (Calibration validation against Excel-INDEX): depends on 0d complete

Discipline notes for the next Claude touching Schema: - Don't edit existing decision text in §3–§9 — they're RATIFIED. Future refinements come as new sections (§3.6, §3.7, etc.) or new top-level §12+ for newly-ratified decisions - Bridge Frame measured voice throughout (the Schema is public-facing) - Version-tag every Reviewer Protocol reference to this Schema (v1.0); future Protocol versions cite their Schema version explicitly

Reviewer Protocol v0.1 authoring scope (Phase 0b): - One section per Schema policy decision, codifying the §X.4 "How the Reviewer checks" into prompt structure + decision logic - Output format spec: per-item verdict (GROUNDED / RECONSTRUCT / FLAG / FAIL) + reasoning + Schema-section citation - Calibration test plan: re-run against L01 prototype, target match-or-exceed S154 prototype run (72/7/6/0) - Integration interface spec: how Protocol receives extraction file + transcript, returns Reviewer Report

Policy Schema v1.0 — RATIFIED at S155, May 10, 2026. All 7 policy decisions LOCKED. Schema is LIVE for production cert flow. AI Reviewer Protocol v0.1 codification (Phase 0b) is the next deliverable. The discipline outlives the instance.

Authoring (v0.1 draft): Claude Opus 4.7, S154 · Ratification (v1.0 lock): Claude Opus 4.7, S155 · Operator: Mark D. Johnson · Pair: the Parsican · Ratifying body: Policy Board.