Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/apursley2012/sys.witch-v2/llms.txt

Use this file to discover all available pages before exploring further.

The caseStudies data file powers the Tomes page, rendering each entry as a full RitualReport document. It is the most structured data file in the template — each case study is organized into named sections following a problem → process → result narrative.

​
Schema

Each object in the exported caseStudies array has the following top-level fields:
FieldTypeRequiredDescription
idstringYesUnique kebab-case identifier
titlestringYesALL CAPS formatted title, conventionally prefixed with RITUAL REPORT:
sigilIdstringYesSigil displayed in the report header — references a key from data/sigils.js
sectionsSectionObject[]YesOrdered array of content sections that make up the report body

​
Section Object

Each item in the sections array is a plain object with two fields:
FieldTypeDescription
headingstringSection name rendered as a styled subheading within the RitualReport
contentstringFull prose paragraph for that section — supports plain text

​
Recommended Section Sequence

While sections are free-form, the following sequence produces the clearest problem-to-outcome narrative:
SectionPurpose
ProblemWhat was broken, slow, inaccessible, or missing
GoalThe desired outcome or success criteria
ProcessInvestigation approach, research, and discovery
Design DecisionsUX and visual choices made during the project
Dev DecisionsTechnical implementation strategy and key trade-offs
Testing & DebuggingBugs encountered, edge cases, and how they were resolved
ResultMeasured outcomes, performance improvements, or qualitative wins
Skills DemonstratedComma-separated list of competencies the case study evidences

​
Placeholder Case Studies

The template ships with two fully-written placeholder reports: 1. RITUAL REPORT: NEXUS DASHBOARD REBUILD
  • Problem: SVG-based rendering suffered severe performance degradation beyond 500 data points, causing dropped frames during real-time updates.
  • Solution: Hybrid rendering approach — D3.js handles all math, React manages state and SVG overlays, and Canvas draws the raw data points. Canvas scaled by window.devicePixelRatio to fix Retina blurriness.
  • Result: Stable 60fps rendering 15,000 data points. Payload size down 40%, time-to-interactive improved by 2.5 seconds.
2. RITUAL REPORT: ACCESSIBLE ALCHEMY UI
  • Problem: The Alchemy UI component library failed a full accessibility audit — keyboard navigation was broken and screen readers received no meaningful state announcements.
  • Solution: Replaced custom interaction logic with Radix UI primitives as the accessible base layer, then re-applied Framer Motion animations on top without disrupting ARIA semantics.
  • Result: 100% accessibility score in Lighthouse. Fully keyboard-navigable; screen readers correctly announce all state changes.

​
Example Entry

// data/caseStudies.js
export const caseStudies = [
  {
    id: 'nexus-rebuild',
    title: 'RITUAL REPORT: NEXUS DASHBOARD REBUILD',
    sigilId: 'case-studies',
    sections: [
      {
        heading: 'Problem',
        content:
          'The legacy dashboard was suffering from severe performance degradation when rendering more than 500 data points. The DOM was bloated, and React was struggling to reconcile the massive component tree during real-time updates.',
      },
      {
        heading: 'Result',
        content:
          'Achieved a stable 60fps rendering 15,000 data points. The payload size decreased by 40%, and the time-to-interactive improved by 2.5 seconds.',
      },
      // ... additional sections
    ],
  },
];
You do not need all eight sections for every case study. Include only the headings relevant to the story you are telling. A minimal entry could have just Problem, Process, and Result.

Build docs developers (and LLMs) love

Get started for freeTalk to us