Version: 2.0
Classification: Strategic Implementation
Date: May 2026
Most organizations now generate AI-assisted workplace documentation routinely. Very few have deployed review systems capable of reliably evaluating reconstruction reliability, chronology continuity, evidentiary grounding, or escalation consistency before records enter official systems.
JRS exists to solve that operational gap.
The commercial opportunity is not selling AI governance philosophy. It is selling operational review infrastructure to organizations already experiencing documentation review failures — organizations that have not yet named the problem, but whose compliance, HR, and legal teams already recognize the symptoms.
The positioning directive: JRS is the operational review layer for AI-assisted workplace and compliance documentation.
Eyebrow:
Documentation Review Controls
H1:
Operational Review Tools for AI-Assisted Workplace and Compliance Documentation
Subtitle:
Practical review systems designed to improve reconstruction reliability, chronology continuity, evidentiary grounding, and downstream review defensibility.
Supporting block:
Used within HR, compliance, investigations, and administrative review environments where documentation must withstand later scrutiny.
CTA row:
- Primary:
Download Free Review Resources→ section-tools - Secondary:
View Deployment Kit→ section-kit - Tertiary:
See Documentation Failures →→ section-scenarios
No inline failure example in hero. The hero positions the problem category. The failure section immediately below demonstrates it. Showing a failure example in the hero and again directly below creates redundancy.
1. Hero (as above)
2. Documentation Failure Examples (3 enhanced failure blocks + consequences)
3. Common Failure Modes grid (6-panel operational failure catalog)
4. Product Hierarchy (5-tier: Free → Reviewer Toolkit → Deployment Kit → Simulation Training → Enterprise)
5. Review Controls (Four Conditions — compressed to 4 bullets)
6. Operational Questions (5 Questions as a question list, not grid)
7. How Review Works (workflow steps — compressed)
8. Founder Provenance strip
9. Mid-Page CTA block
10. Record Types Covered
11. Incremental Adoption
12. Practitioner References
Remove from homepage scroll:
- Onboarding strip (already removed)
- "Before Finalization, Ask" (already removed — duplicate of Five Questions)
- "Review Lifecycle" numbered table (redundant with How Review Works flow)
- First "Where JRS Fits" 3-column layer diagram (redundant with workflow steps)
- "Typical Reviewer Routing" table (move to Implementation section)
Every section above the fold must answer one of:
- What operational failure does this prevent?
- What does the reviewer do at this step?
- What does the buyer receive?
- Why does AI-assisted documentation change this risk?
Home | Review Examples | Free Downloads | Deployment Kit ↗ | Reviewer Training ↗ | Implementation | About
Overview | Documentation Failures | Free Resources | Reviewer Toolkit | Deployment Kit ↗ | Simulation Training ↗ | About
Rationale by item:
| Current | Recommended | Reason |
|---|---|---|
| Home | Overview | More institutional; no consumer "home" resonance |
| Review Examples | Documentation Failures | Buyers search for problem recognition, not "examples" |
| Free Downloads | Free Resources | "Resources" carries more operational weight than "Downloads" |
| Deployment Kit ↗ | Deployment Kit ↗ | Keep — already commercially legible |
| Reviewer Training ↗ | Simulation Training ↗ | "Simulation" differentiates from generic training |
| Implementation | Implementation | Keep — operationally legible |
| About | About | Keep |
Drop "Reviewer Training" naming from nav — it undersells the simulation/calibration value proposition. "Simulation Training" implies procedural rigor.
Mobile nav: On small screens, show only:
Documentation Failures | Free Resources | Deployment Kit | About
TIER 0 — Free Resources
Purpose: Problem recognition + trust formation
Barrier: None
Items:
- JRS Documentation Review Standard (PDF)
- JRS Investigator Field Guide (PDF)
- JRS Rapid Review Card (PDF)
- Pre-Finalization Reconstruction Checklist
Copy: Start here. Apply to one record type. Gaps appear quickly.
TIER 1 — Reviewer Toolkit
$77 — Individual reviewer operational use
For: HR generalists, investigators, compliance officers
Items:
- Expanded reviewer reference
- Full failure-mode catalog
- All review worksheets and forms
- Reconstruction review prompts
- Escalation review templates
Copy: Individual reviewer operational layer. Chronology review, escalation templates, reconstruction controls.
TIER 2 — Deployment Kit
$77 — Team implementation + reviewer alignment
For: HR teams, compliance programs, department-level rollout
Items:
- Reviewer onboarding + training materials
- Escalation review forms
- Redlined documentation examples
- Reviewer signoff templates
- AI-assisted documentation checklist
- Workflow integration playbook
Copy: Team implementation layer. Onboarding, reviewer calibration, escalation structures, signoff systems.
TIER 3 — Simulation Training
web-based — Reviewer calibration + institutional conditioning
For: Teams conducting recurring reviewer calibration exercises
Items:
- Reconstruction simulations
- Chronology reinterpretation exercises
- Escalation review scenarios
- AI-assisted documentation review simulations
- Comparator analysis exercises
Copy: Reviewer calibration exercises. Operational scenarios. Not theory — procedural drill.
CTA: Launch Training → (links to training.html)
TIER 4 — Enterprise Implementation
By inquiry — Organizational deployment
For: Enterprise HR, compliance, legal operations, governance/risk teams
Includes:
- Workflow assessment
- Reviewer alignment system
- Department-level deployment guidance
- Governance integration support
- Operational review advisory
Copy: Organization-level deployment. Workflow assessment, reviewer alignment, governance integration.
CTA: Contact for Implementation → (mailto)
Display all 5 tiers in a horizontal progression grid with clear headers (Free / $77 / $77 / Web / Contact). The current 3-column grid stops at "Team" and leaves the buyer without a path to enterprise. Adding columns 4 and 5 creates the full platform impression.
Intro (compressed):
These failures appear routinely in HR, investigation, compliance, and administrative records. The file looks complete at drafting because the author's context fills the gaps. Two years later, that context is unavailable.
Each panel: [Failure type] / [What it looks like] / [Downstream consequence]
1. Unsupported Generalization
What it looks like:
"Employee has performance issues."
Downstream consequence:
No verifiable basis. A later reviewer cannot establish whether the characterization was supported by documented conduct, assessments, or policy reference. The record asserts the conclusion without establishing it.
2. Chronology Gap
What it looks like:
"Following multiple prior discussions, employee was formally warned."
Downstream consequence:
"Prior discussions" is not reconstructible without specific dates. At escalation or audit, the sequence of prior conduct cannot be independently verified. The escalation claim is unsupported.
3. Inherited AI-Assisted Language
What it looks like:
AI-drafted summary absorbed verbatim from prior unverified record.
Downstream consequence:
Characterizations introduced by AI tool propagate without human review. At later scrutiny, the source of the language cannot be traced to original conduct documentation. Source integrity fails.
4. Incomplete Evidentiary Linkage
What it looks like:
"Per the supporting documentation on file..."
Downstream consequence:
Referenced documents are not attached or are no longer accessible. The record claims a basis that cannot be located or confirmed. The conclusion stands unsupported.
5. Escalation Inconsistency
What it looks like:
Final warning references counseling that does not appear in the file.
Downstream consequence:
Escalation pattern cannot be reconstructed. Each step must be independently confirmable. A final warning citing nonexistent prior counseling becomes structurally unsupported during later review.
6. Context Loss Across Records
What it looks like:
Termination record written by reviewer who was not present at original events.
Downstream consequence:
The later-authored record may describe events differently than contemporaneous documents. Inconsistency across records creates reconstruction instability when reviewed against the full file.
Each of the three current failure blocks should be expanded with:
[Downstream risk]line: what happens when this record reaches escalation, litigation, or audit[AI-assisted variant]note: whether this failure mode is amplified by AI-assisted drafting
Simulation exercises are not ancillary training content. They are the platform's calibration infrastructure. Framing them as training understates the value proposition. Framing them as reviewer conditioning exercises positions them correctly.
Category identity: Reviewer Calibration Exercises
Positioned as: Operational conditioning for pre-finalization review
Homepage: Simulation Training appears as Tier 3 in the product hierarchy. Short description: Web-based reviewer calibration exercises. Reconstruction simulations, escalation scenarios, AI-assisted review exercises.
Navigation: "Simulation Training ↗" replaces "Reviewer Training ↗"
Simulation page (training.html): Reposition hero as calibration infrastructure, not a training course:
- H1:
Reviewer Calibration Exercises - Subtitle:
Operational simulation scenarios for pre-finalization documentation review. Reconstruction simulations, chronology reinterpretation, escalation exercises, AI-assisted documentation review. - Frame each exercise as a calibration scenario, not a quiz
New simulation types to add:
- Chronology reinterpretation — same events, two different write-ups, identify the reconstruction gap
- AI drift detection — identify inherited AI language not grounded in source material
- Escalation audit — reconstruct escalation sequence from file fragments only
- Comparator analysis — two records from the same event; identify inconsistencies
The simulation section should be cited in the homepage product hierarchy as proof that JRS operates as a calibration system, not a framework document. Buyers experiencing review failures will respond more strongly to "apply these to your own records" than to framework exposition.
Priority 1 (Acquisition): Download Free Review Resources
Used in: hero, mid-page CTA, Practitioner References section
Target: first-contact buyers, reviewers doing initial research
Priority 2 (Individual Purchase): Get Reviewer Reference — $77
Used in: product hierarchy, mid-page CTA, Implementation section
Target: individual HR, compliance, investigation practitioners
Priority 3 (Team Purchase): View Deployment Kit — $77
Used in: nav (branded), product hierarchy, mid-page CTA, Deployment Kit section
Target: HR teams, compliance programs, department-level decision-makers
Priority 4 (Simulation): Launch Simulation Training →
Used in: product hierarchy, mid-page CTA
Target: buyers with teams doing recurring calibration
Priority 5 (Enterprise Inquiry): Contact for Implementation
Used in: mid-page CTA, footer, Enterprise tier in product hierarchy
Target: enterprise procurement, governance/risk committees, operational enablement
[Ready to Deploy Review Controls?]
Download the free resources and apply to one record type.
Most reviewers identify gaps in the first record they check.
[ Download Free Resources ] [ Reviewer Reference — $77 ] [ Deployment Kit — $77 ]
Simulation Training: Calibration exercises for reviewer teams. Launch →
Enterprise Implementation: Organizational deployment. Contact →
- Every CTA must state what the buyer receives, not what they do
- Every paid CTA must show price on first sight
- Enterprise CTA must never say "Book a Demo" or "Schedule a Call" — say "Contact for Implementation"
- Free CTA must never say "Sign Up" — say "Download" or "Access"
The Reviewer Reference is not a "book" or "guide." It is the individual practitioner's operational toolkit. The positioning should communicate that every reviewer in a documentation-sensitive environment needs this on their desk.
Who it's for: HR generalists, workplace investigators, compliance officers, employee relations practitioners, administrative review staff.
What it replaces: Ad hoc review approaches, memory-dependent checklists, improvised verification habits.
What it delivers:
- Operational review prompts for each record type
- Escalation review templates
- Reconstruction verification checklists
- Failure-mode catalog with reviewer annotations
- AI-assisted documentation review protocol
Operational promise: Any reviewer applying this toolkit to an elevated-risk record before submission will identify gaps they would otherwise not catch.
Do not position the Reviewer Reference as:
- A "comprehensive guide" (academic)
- A "framework" (abstract)
- A "training manual" (passive)
- A "resource library" (generic)
Position it as: An operational reviewer's working toolkit for pre-finalization documentation control.
The Deployment Kit is organizational review infrastructure, not a set of templates. The positioning should communicate that a team deploying this kit is building a formal pre-finalization review function — not downloading a checklist.
Who it's for: HR teams, compliance programs, employee relations departments, organizations rolling out a formal documentation review step.
What it replaces: Informal pre-submission review, unstructured secondary review, reviewer discretion without shared criteria.
What it delivers:
- Reviewer onboarding system (org-level)
- Escalation structures and secondary review triggers
- Redlined documentation examples for reviewer training
- Reviewer signoff and attestation templates
- AI-assisted documentation protocol
- Implementation playbook
Operational promise: A team working through this kit will have a deployable review function — onboarded reviewers, shared criteria, escalation routing, and documented signoff — within a normal implementation cycle.
Do not position the Deployment Kit as:
- A "premium bundle" (retail language)
- A "complete package" (infoproduct language)
- A "team subscription" (SaaS language)
Position it as: An operational implementation package for organizations deploying formal pre-finalization documentation review.
Enterprise Implementation is the advisory layer for organizations deploying JRS across multiple departments, functions, or jurisdictions. It is positioned as operational review consulting, not software implementation.
Enterprise buyers do not convert from a "Buy Now" button. They convert from:
- Recognizing their documentation review exposure in the failure examples
- Downloading free resources and verifying the problem against their own records
- Deploying the Deployment Kit at department level
- Encountering a scale or customization requirement the Kit doesn't cover
The enterprise path is: Free → Deployment Kit → Enterprise Implementation inquiry
The homepage should signal enterprise plausibility without overpromising. Signals:
- "Available for organizational deployment" language in the product hierarchy
- Contact path visible in mid-page CTA and footer
- Founder provenance block (establishes institutional credibility)
- Governance compatibility note (NIST AI RMF, ISO 42001 — listed as supporting context, not primary authority)
Current problem: Governance framework references (NIST AI RMF, EU AI Act, ISO 42001) are overpositioned as validation authority. This reads as quasi-regulatory posturing to enterprise buyers who know the actual standards.
Correction: Use governance compatibility as a supporting signal — "JRS review controls operate consistently with NIST AI RMF Govern/Map/Measure functions and ISO/IEC 42001 documentation requirements." Place this in a small callout within the Implementation section, not in the homepage hero or product positioning.
1. Homepage scroll length
Current: ~15 distinct sections on the homepage scroll
Target: 10 sections maximum above the fold + navigation
Remove: Review Lifecycle table, first "Where JRS Fits" 3-column diagram, Typical Reviewer Routing table
Move to: Implementation section (section-guidance)
2. Body text density
Current: Many 3-4 sentence paragraphs explaining framework concepts
Target: 1-2 sentence paragraphs + operational bullets
Rule: If a paragraph explains what JRS is, compress or remove. If it explains what the reviewer does, keep.
3. Section heads
Current: Mix of operational and conceptual heads ("Four Review Conditions," "Review Lifecycle," "Operational Components")
Target: All section heads should be operational questions or action frames
Examples:
- "Four Review Conditions" → "What Review Checks Before Submission"
- "Operational Components" → "What's in Each Tier"
- "Incremental Adoption" → "How Organizations Deploy This"
4. Reviewer notes vs. body text
Reviewer notes (the bordered annotation blocks) are the most operationally legible elements on the page. They convert better than body text paragraphs. Increase reviewer note density; reduce paragraph density in proportion.
5. Failure blocks
Failure blocks are the highest-conversion content. They should appear earlier, have more variants, and be the primary homepage anchor. The current implementation shows 3 on the homepage. The scenarios section shows many more. Cross-link between them aggressively.
- Consolidate the two "Where JRS Fits" sections into one
- Combine "Four Review Conditions" + "Five Questions" into a single section (they address the same concept from slightly different angles)
- The "Reviewer Judgment" callout is good; it should appear after the questions section, not before the conditions section
Converts: Specific, recognizable documentation failures with annotated review outcomes
Doesn't convert: Abstract framework descriptions, conceptual review stages, governance theory
Architectural principle: Every abstract governance claim should have an adjacent procedural example. If it can't be illustrated with a specific record fragment, remove or compress the claim.
Homepage failure section:
3 failure blocks (current) + inline consequence note per block
→ Link to "View All Review Examples →" (scenarios section)
Scenarios section (section-scenarios):
Current structure is strong. Add:
- Each scenario should end with: "What review caught. What submission without review would have produced."
- Add a "Reviewer note as filed" block — what the reviewer actually wrote in the margin
Implementation section (section-guidance):
Add 1-2 operational examples illustrating what secondary review catches that self-review misses. Currently too abstract.
Deployment Kit section (section-kit):
Redlined documentation examples should be featured prominently on the kit landing page — not just listed as a kit item. Show one actual redlined example inline as proof of what's inside.
Redlined examples exist in JRS Kit D1 Redlined Examples.pdf and are surfaced in the Deployment Kit description. They are not integrated into the homepage conversion flow.
Phase 1 (Homepage):
Add one compressed redlined example as a feature element in the Deployment Kit product tier on the homepage grid. Label it: [Sample — Redlined Record Fragment] with a teaser of the annotation.
Phase 2 (Scenarios section):
Each scenario in section-scenarios should have a "Redlined" view — the original document fragment with visible reviewer markup. This is the highest-conversion page on the site once buyers encounter it; make it findable faster.
Phase 3 (Kit landing page):
The kit page (section-kit) should open with a visible redlined example — the first thing the buyer sees proves what they're getting. Not a list of contents. A sample page.
- Show the "as written" document fragment in a light, document-like style
- Show reviewer annotations as margin notes using the existing reviewer-note component
- Show the "after review" fragment in the corrected state
- Add: "A later reviewer can now reconstruct the basis independently."
Name: JRS Reviewer Calibration Exercises
Purpose: Operational reviewer conditioning for pre-finalization documentation review
Access: Web-based, no download required
Location: training.html
Eyebrow: Reviewer Calibration
H1: Operational Simulation Exercises for Documentation Reviewers
Subtitle: Applied reviewer conditioning. Reconstruction simulations, escalation scenarios, chronology reinterpretation, and AI-assisted documentation review exercises. Not theory. Procedural drill against recognizable failure patterns.
Module 1: Reconstruction Check
Given: A submitted record
Task: Identify whether a later reviewer could reconstruct the basis independently
Outcome: Reviewers learn to apply the reconstruction standard before submission
Module 2: Chronology Reinterpretation
Given: An undated narrative + a later summary
Task: Identify where chronology gaps emerge when the author is unavailable
Outcome: Reviewers learn to require dates before the record is filed
Module 3: AI Drift Detection
Given: An AI-drafted record + source notes
Task: Identify characterizations in the AI draft not present in the source notes
Outcome: Reviewers learn the specific AI documentation failure pattern
Module 4: Escalation Audit
Given: A final warning record referencing prior steps
Task: Confirm or flag each prior step using only the materials in the file
Outcome: Reviewers learn escalation verification before it becomes a litigation issue
Module 5: Comparator Analysis
Given: Two records from the same event authored at different times
Task: Identify inconsistencies that would complicate later review
Outcome: Reviewers learn to check cross-record consistency
Current training.html: Interactive exercises with multiple-choice format and score tracking
Target: Keep the quiz infrastructure; rebrand as "Calibration Exercises"; add the new module types; frame as recurring reviewer conditioning, not one-time training
Enterprise buyers evaluating an operational tool need to immediately answer:
- What operational problem does this solve?
- What evidence exists that it works?
- Who has used it?
- How does deployment work?
- What does it cost?
- What do I do first?
Problem 1: No visible proof of deployment
The site has extensive framework exposition but no institutional deployment signals. Even a "Used by HR and compliance practitioners in employment, civil rights, and administrative review environments" line builds deployment plausibility.
Problem 2: Cost buried in product grid
Prices are visible in the product grid but not in the hero or primary CTA. Enterprise buyers evaluate cost early; don't make them search.
Problem 3: Implementation path unclear
The Implementation section (section-guidance) explains JRS but doesn't show the buyer how to deploy it operationally. Add a "How Deployment Works" sequence: Start with one record type → Reviewer applies five questions → Gaps identified → Secondary review triggered → Record returned or approved → Reviewer team aligned on criteria → Organization expands to additional record types.
Problem 4: No enterprise contact path in nav
Enterprise buyers look for contact links in the nav. Currently no nav-level contact signal.
- Add deployment plausibility line to hero supporting block
- Show prices in hero CTA ("Free" + "$77" labels on buttons)
- Add "How Deployment Works" 6-step sequence to Implementation section
- Add "Contact" or "Enterprise" nav item, or at minimum a visible contact link in the utility bar
Institutional trust in this product category comes from:
- Operational specificity (knowing exactly what the reviewer does at each step)
- Procedural granularity (the materials are detailed enough to work)
- Founder provenance (this was built from real operational experience, not theory)
- Language discipline (not overstating authority, not making unsupported regulatory claims)
- Product maturity signals (versioning, publication date, document numbering)
- Reviewer notes ("Reviewer flag:" labels, "From practice:" annotations) — these are the strongest trust signals on the site
- Document numbering (Document 001-INV, etc.) — institutional maturity signal
- "v1.0 Published May 2026" in footer — versioning discipline
- Founder provenance strip — 27 years operational, MD Civil Rights Commission
- "Applied in:" line — e.g., "Applied within HR operations, workplace investigations, compliance review, and administrative oversight environments." This is deployment context, not a client testimonial. It signals where the tool operates.
- Governance compatibility callout (compressed) — signals enterprise compatibility without overclaiming regulatory authority
- Document version numbers visible on free PDFs — signals that documents are actively maintained
- Any language suggesting formal regulatory endorsement not evidentially supported
- "Defensibility" as primary product promise — replace with "downstream review reliability" (more operationally specific, less legally presumptuous)
- "Survivability" in any form — replace with "reconstruction reliability" or "independent reviewability"
Current homepage scroll: Hero → Failures → Products → Five Questions → How Review Works → Four Conditions → Review Lifecycle → Where JRS Fits → Routing Table → Founder → CTA → Record Types → Adoption → References
This sequence was designed for someone already committed to JRS who wants a comprehensive reference. It does not convert an undecided enterprise buyer.
1. Hero — What is the operational problem?
2. Failure Examples — What does it look like? (3 blocks + 6-panel catalog)
3. Product Hierarchy — What can I start with?
4. Five Questions — How does review actually work?
5. Founder Provenance — Why should I trust this?
6. Mid-Page CTA — What do I do now?
7. Record Types — Where does this apply?
8. How Organizations Deploy — 6-step implementation sequence
9. Practitioner References — What materials are available?
Everything below "Mid-Page CTA" is discovery content — for buyers who have already decided to explore and want depth. Everything above it is conversion content — for buyers deciding whether this is relevant.
The homepage should close the "recognition loop" in the first three sections:
- I see the problem (hero)
- I recognize my organization's failures (failure examples)
- I see a clear product that addresses it (product hierarchy)
The buyer who has completed that loop is converted. Everything else is implementation support.
JRS review controls operate within existing workflows. No system replacement. No dedicated software. No process redesign.
The specific integration claim: "The reviewer applies five questions before the record enters the official system. That is the only structural change."
HR Operations:
Review applied by HR coordinator or generalist before elevated-risk records (performance, discipline, termination, accommodation) enter HRIS. Self-review for standard-risk records. Secondary review routed for elevated risk.
Workplace Investigations:
Investigator applies reconstruction check before conclusions are filed. Source materials identified, conflicting accounts noted, AI-assisted summaries reviewed against source notes before submission.
Compliance Review:
Compliance reviewer applies the failure-mode catalog to periodic record sampling. Systemic gaps identified across departments and record types without requiring individual record rework.
Administrative Review:
Review applied before formal administrative action documentation is processed. Reconstruction check confirms basis is recoverable without original author.
Enterprise buyers hear "no software required" as: implementation risk is low, integration is low, time-to-value is fast. Position this prominently — not as a limitation ("no app") but as an advantage ("applies within existing systems").
| Remove (governance abstraction) | Replace with (operational question) |
|---|---|
| "documentation survivability" | "Can another reviewer reconstruct how the decision was reached?" |
| "review defensibility" | "Can the supporting basis for the conclusion be identified later?" |
| "reconstruction continuity" | "Would this record remain understandable at escalation or litigation review?" |
| "evidentiary traceability" | "Can each conclusion be traced to specific documents, dates, or interactions on file?" |
| "downstream defensibility" | "What does a later reviewer find when the original author is unavailable?" |
| "documentation integrity framework" | "Pre-finalization review controls" |
| "governance compatibility" | "Compatible with existing compliance and workflow requirements" |
| "operationalized review structure" | "Review procedure applied before records enter the system" |
| "institutional credibility formation" | "Review discipline visible in the record" |
| "scalable review ecosystem" | "Review applied across record types and departments" |
Any time the site needs to convey a governance concept, convert it to an operational question first:
Test: "Would a reviewer applying this five seconds before submission know what to do?"
If yes: include the language.
If no: convert to an operational question or remove.
- Reconstruction reliability
- Chronology continuity
- Evidentiary grounding
- Downstream review
- Pre-finalization review
- Review controls
- Reviewer verification
- Source integrity
- Escalation consistency
- Observable support
- AI governance (too broad)
- Responsible AI (activist framing)
- Documentation survivability (abstract)
- Defensibility as primary promise (legally presumptuous)
- Framework (implies theory, not practice)
- Standard (overstates formal regulatory status)
Stage 1 — Recognition
Trigger: HR director, compliance manager, or legal counsel experiencing a documentation review failure in an active matter
Entry point: Google search for "documentation review failure," "HR record reconstruction," "AI-assisted documentation review controls"
Landing: Homepage failure examples section
Action: Downloads free PDF
Stage 2 — Verification
Trigger: Downloaded PDF, applies rapid review card to one internal record
Experience: Identifies gaps they didn't expect to find
Action: Returns to site, downloads second resource, shares with team
Stage 3 — Individual Adoption
Trigger: Reviewer applies free resources consistently over 30 days
Experience: Identifies recurring failure patterns in their record environment
Action: Purchases Reviewer Reference ($77) for expanded toolkit and forms
Stage 4 — Team Deployment
Trigger: Individual reviewer proposes review structure to HR director or compliance lead
Experience: Team pilot of pre-finalization review on elevated-risk record type
Action: Purchases Deployment Kit ($77) for onboarding, templates, and implementation guidance
Stage 5 — Organizational Scale
Trigger: Deployment Kit used across departments; governance committee or legal team requests formal review program
Experience: Need for customization, multi-department calibration, or enterprise advisory
Action: Enterprise Implementation inquiry (contact email)
- Every page should make Stage 1 → Stage 2 conversion available (free PDF download)
- Every page should make Stage 2 → Stage 3 visible ($77 individual product)
- Enterprise pathway must never require a sales meeting to enter — email inquiry is sufficient first contact
- Simulation Training can intercept at Stage 3-4 as reviewer calibration infrastructure
JRS is the operational review layer for AI-assisted workplace and compliance documentation.
This is not a broad claim. It is a specific operational function: pre-finalization review controls applied to documentation environments where downstream scrutiny matters.
AI governance frameworks (NIST AI RMF, ISO 42001, etc.) address policy and risk management at the system level. They do not produce reviewer-level operational tools.
Generic HR documentation guides address drafting quality at the content level. They do not produce reconstruction verification systems.
Compliance audit tools address after-the-fact review at the system level. They do not produce pre-finalization reviewer controls.
JRS occupies the specific operational layer between drafting and system entry — a layer that was functionally unoccupied before AI-assisted drafting created reconstruction reliability gaps that didn't exist at scale before.
Not competing with:
- HRIS platforms (JRS works inside any existing system)
- AI writing tools (JRS reviews regardless of how the record was drafted)
- Compliance audit software (JRS is pre-submission, not post-submission)
- Legal review services (JRS is operational, not legal advice)
- Generic HR training (JRS is reviewer conditioning, not compliance education)
Directly competing with:
- Nothing (the category is new)
- Adjacently: informal secondary review practices, ad-hoc reviewer checklists, undocumented supervisor sign-off
JRS is the operational documentation review infrastructure for organizations where AI-assisted drafting creates reconstruction reliability gaps that existing review practices don't catch.
The operational dynamic that creates the market:
- AI tools now produce documentation drafts faster than human reviewers can verify them
- The drafts read confidently — they don't signal gaps the way manually written records did
- Documentation environments (HR, investigations, compliance) face the same downstream scrutiny they always did
- The gap between "the record reads well" and "the record is independently reconstructible" is widening
- JRS exists to close that gap at the only point where it can be closed without consequence: before the record enters the system
- Homepage hero rewrite (new headline, subtitle, supporting block, remove inline failure example)
- Navigation rename (Review Examples → Documentation Failures; Free Downloads → Free Resources; Reviewer Training → Simulation Training)
- Enhanced failure blocks (add downstream consequence note to each)
- Product hierarchy — add Simulation Training and Enterprise tiers
- Failure section intro compression
- Remove redundant sections (Review Lifecycle table, first Where JRS Fits diagram, Routing table)
- Add 6-panel failure catalog (below the 3 failure blocks)
- Add "How Deployment Works" sequence to Implementation section
- Training.html hero rewrite
- Governance compatibility callout in Implementation section (compressed)
- Redlined example integration in Deployment Kit landing
- Add new simulation exercise types (Module 2-5)
- Enterprise implementation section build
- Scenarios section — add consequence notes to each scenario
- Operational terminology pass (systematic replacement across full site)
Strategy document prepared for JRS platform transformation — May 2026.
Implement against this spec in priority order. Do not implement Phase 2 items before Phase 1 is stable.