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.

A graph, in the mathematical sense, is simply a set of nodes together with a set of edges connecting pairs of nodes. Kastalia treats its entire universe of discourse as one big graph: every stored unit of meaning is a node (Kastalia calls it a knot), and every stated relation between two units is a directed, labelled edge (a bound).

Unlike a tree, a graph permits any node to be reached from many different directions -- the same knot can simultaneously be the child of one category, a member of a group, the illustration of another knot, and the translation of yet another. This is precisely what lets Kastalia model real knowledge, which is rarely a strict hierarchy.

A knowledge graph is a graph whose nodes and edges are meant to be interpreted, not just traversed: nodes stand for entities or ideas, and edges carry a specific predicate (a verb, in effect) that says exactly how the two nodes relate -- is_parent, translates, illustrates, and so on.

Kastalia KMS is, at its core, a general-purpose engine for building, editing and rendering exactly this kind of graph. It does not presuppose any particular domain: the same knots/bounds substrate underlies a university course, a glossary of linguistic terms, an archive of spoken recordings, or a tree of philosophical arguments. What differs between these uses is only which predicates get used, and which template is chosen to turn the raw graph into something readable.

The two fundamental tables of Kastalia's database are knots and bounds.

A knot is a single addressable unit of content: it has a unique knot_id, a knot_name (its path-like, human-readable label), a knot_content (free text, typically light HTML, such as the page you are reading right now), and a set of free-form attributes (an open-ended key-value store -- see the Attributes section of this guide).

A bound connects two knots -- a sub(ject) and an obj(ect) -- through a predicate that names the relation between them (see the Predicates section). Bounds also carry an ord (ordering, used whenever children/items need a stable sequence) and a bound_creator (who asserted the relation).

Everything visible anywhere in Kastalia -- a course, a presentation, a glossary entry, a recording -- is ultimately just some knots and the bounds between them, read out through a template.

A template is the piece of code that decides how a given knot (and, typically, its neighbours in the graph) gets turned into an actual page a human can read. Kastalia uses Template::Toolkit (Perl's TT) for this: each template is a .tt file living under views/, free to query the graph however it needs and to render the result however it likes.

The same knot can, in principle, be rendered by several different templates -- a lecture knot might look like a slide deck under mainframe, a flat document under knot (the default), or a node in a force-directed diagram under arbre. Which template applies is usually decided by the knot's own template attribute, though some domains additionally define a fixed canonical template that every .knot-style URL on that domain gets routed through regardless (see domain_template in config.yml).

The resulting rendered page is called a view.

Every bound needs a predicate: a short, fixed vocabulary word that says exactly how its subject knot relates to its object knot. Kastalia constrains this vocabulary deliberately -- predicates live in a proper Postgres ENUM type, not a free-text column -- so that a graph query can rely on a closed, known set of relation kinds rather than accidentally-inconsistent free text.

This short mention is just a pointer: the full catalogue of predicates, with one knot describing each, lives in its own section of this guide (see Predicates, further down).