This guide is organized into several sections, each approachable independently: a brief introduction to the core ideas (Brief Introduction), the project's own path and motivations (Path to Kastalia), how the system is built on the server side (Backend) and in the browser (Frontend), a catalogue of available Templates, the vocabulary of Predicates that knots use to relate to one another, and the free-form Attributes a knot can carry.

Start wherever your curiosity points you -- the graph, true to its own philosophy, has no single correct entry point.

This file was created for the benefit of all AIEDucators, teachers, students, developers and parents wanting to use Kastalia Knowledge Management System (KMS) creation of their own knowledge graphs, archives of more complex curricular and/or meta-curricular structures.

Kastalia Knowledge Management System, or simply ``Kastalia KMS'', is a system for collaborative web-publishing, data-management and archivation of structured information in a form of a so-called ``knowledge graph''.

Kastalia's knowledge graph (KG) is composed of things - also called ``knowledge units'' or ``knots`` - and relations between things - also called ``bounds''.

Diverse combinations of ``knots'' and ``bounds'' can be obtained by executing different kinds of ``templates'', ultimately providing ``views'' which end up in the browser of a human user.

To the one who understands it and masters it, Kastalia KMS is a strongly generative system providing theoretically infinite flexibility in both content structuration as well as interface design.

Kastalia did not appear out of nowhere. This section gathers the three threads that, braided together, led to the system as it exists today: the philosophical commitments that shaped its design (Philosophy), the fictional and speculative works that fed its imagination (Fiction), and the plain factual record of how the project actually unfolded over time (History).

Kastalia's backend is a Perl application built on the Dancer2 web framework, storing its graph in PostgreSQL. This section describes the two layers that matter most: the SQL core (the actual table/enum design behind knots and bounds) and the PERL Core (the routes and helper functions that read and write it).

What a visitor actually sees is produced entirely by server-rendered Template::Toolkit templates -- there is no separate client-side application framework. This section covers Template Toolkit's role in Kastalia specifically; the companion Templates section of this guide catalogues the individual .tt files and what each one is for.

A non-exhaustive sample of the templates this system actually uses, to give a sense of the range:

knot is the plain default view, rendering a knot's content and its children as an ordinary document.
mainframe turns a knot and its children into a live, broadcastable slide deck, with optional audio narration, a classroom-cast mode, and cross-referenced-knot preview-on-hover.
reveal2 is an older slide-deck template built directly on reveal.js.
semester renders a whole course's session list, including a 'live' badge for whatever is currently being cast.
play and read are built around spoken-word recordings linked via is_uttered_as and illustrates.
arbre renders a knot's neighbourhood as a graph diagram.

Separately, several domains each define their own fixed canonical template (console, treehouse, arena, atlas, and so on) that every .knot-suffixed URL on that domain uses regardless of the knot's own template attribute -- see domain_template in config.yml.

Attributes are the free-form, per-knot metadata stored in the attributes hstore column. A handful of names recur often enough across templates to be worth knowing: template (which .tt file should render this knot), public (whether anonymous visitors may see it), creator and epoch (who made it and when), img_url (an illustration), ogg_url and presentation_timeline (audio narration and its synced slide-navigation events, used by mainframe), and voice/age/gender/motherlang/consent (speaker metadata for recordings).

Because attributes is schemaless, nothing stops a template from inventing its own attribute name for its own purposes -- these are simply the ones already in wide use across the existing templates.