Documentation

Start here

What Organon is#

Organon is a native GPU application. You divide the window into regions, declare what each holds, and save the arrangement under a name. Every arrangement includes an agent that can operate the whole application through the same commands you use.

A region holds an agent conversation, a column of instrument panels, or a 3D viewport. A saved arrangement is an app: the console and the model inspector are two arrangements of the same program. The agent runs the same commands you type, starts in a working directory chosen by documented rules so the project's skills and instructions load, and passes every tool it calls through a permission prompt you answer. The engine beneath is a set of Rust crates licensed MIT or Apache-2.0, and a project outside the repository can depend on them directly.

The one exception is the VST3/CLAP plugin, and it always will be. A DAW creates and destroys its window, its audio thread has hard real-time deadlines, and its identity is stored in saved sessions — so it ships as a separate build.

Canonical wording: doc/organon_prd.md §1.1, in three lengths. This page quotes it rather than re-authoring it; that section says why.

Start here

How it ships today#

Three arrangements, and today they are still three binaries — chosen by a compile-time Edition rather than by a saved layout. That is the mechanism that currently makes them work, and the difference matters enough to say before anything else on this page.

Both edition features default off, so a plain cargo build and a plain cargo test produce and check the visualizer alone. Collapsing the three into one binary that opens into a named arrangement is issue #111, and it has not started.

Owned by ARCHITECTURE.md §4.1 and organon-core/src/edition.rs.

Start here

Where the documentation lives#

One subject, one document, and a hook that notices when a document falls behind the code it describes. The map is worth having before you go looking, because the answer to "where is that written down" is never "in more than one place".

Nothing on this page is the source of truth for anything. If a sentence here disagrees with the file named beneath it, the file is right and this page is a bug — report it like any other statement of fact that has gone stale.

Getting it

Build from source#

There are no releases yet. When there are, they will be on the repository's releases page and this section will say so; until then a clone and a build is the way in, and that is the honest description rather than a placeholder.

Rust via rustup is the only prerequisite on macOS and Windows. On Linux the engine pulls in ALSA/JACK and X11/GL, so the dev headers have to go on first — and this is worth doing before your first build rather than after it, because without them the build dies inside a build script, which reads like a code error and is not. The real message is buried in the script's stderr, far below a wall of rerun-if-env-changed lines.

# Linux only
sudo apt-get update && sudo apt-get install -y \
  libasound2-dev libjack-jackd2-dev \
  libx11-dev libx11-xcb-dev libxcb1-dev libxcursor-dev \
  libxrandr-dev libxi-dev libxext-dev libgl1-mesa-dev \
  libxkbcommon-dev libwayland-dev

nih-plug is a git dependency rather than a crates.io one, so the first build fetches it.

Testing it#

cargo test --workspace runs the unit tests and validates every WGSL shader on the CPU with naga — so shader errors are caught on any machine, with no GPU, in CI.

cd native
cargo test --workspace

--workspace is doing real work there, and leaving it off is a quiet loss rather than a loud one. native/ is a workspace whose root package is the plugin, and a bare cargo test runs that package only. Extracting a crate once silently stopped running the tests it took with it — the suite shrank, and stayed green while it did.

The edition features are off by default, which means the same thing one layer up: a green default suite says nothing about whether the console or Mind still compiles. If your change touches shared ground, build them too.

Both edition features are default-off and mutually exclusive; asking for both at once is a compile error rather than a surprise.

Owned by the README and doc/guide/getting-started.md.

Getting it

Run it#

The quickest way to see something is the standalone plus its visual, with no DAW involved. Then Open Visual Window in the editor.

cargo run --release --bin organon-standalone
cargo run --release --features console-edition --bin organon-console
cargo run --release --features mind-edition --bin organon-mind

The console takes --help like anything else, and Mind wants a .gguf to point at.

Driving it from a terminal is faster than hunting through controls, and it is the way to script it or hand it to an agent — see the command surface below.

Owned by the README.

Getting it

Install into a DAW#

The visualizer also runs as a VST3 and a CLAP. bundle.sh writes target/bundled/Organon.vst3 and Organon.clap with the visual embedded inside each; deploy.sh builds, bundles, signs and installs in one step. On Windows those are bundle.ps1 and deploy.ps1.

The plugin is an audio effect with MIDI input — stereo passthrough — so it has to sit on a track that receives MIDI for clips to reach it. After installing, rescan; if the host cached a failed scan, quit it and clear its plugin-scan cache before reopening.

Four things that will catch you#

• macOS Gatekeeper blocks self-built plugins, and "Allow Anyway" does not work for them. You need sudo spctl --global-disable, and --global-enable afterwards.
• A loaded DLL cannot be replaced on Windows — the OS holds an exclusive lock and reports it as a permissions error. deploy.ps1 detects it and refuses, naming the host it thinks is holding it.
• The CLAP on Windows carries no visual. nih-plug emits it as a bare DLL, so there is no bundle directory to embed one into; point ORGANIC_MATH_VISUAL at the full path of organic-math-visual.exe. The VST3 is unaffected on either platform, as is the CLAP on macOS.
• After a shared-layout version bump, close and reopen the visual too — the editor and the picture agree on a byte layout, and a stale one is a mismatch rather than a crash.

Owned by the getting-started guide and the scripts' own headers.

The console

Regions#

One window, one pane, divided into up to six regions on a grid of three columns by two rows. A region never splits again: to get cells, you name the cells.

A region is a set of cells, and two regions may coexist exactly when their cell sets are disjoint — which is why there is no layout arithmetic to get wrong. Assigning a region that contains one already held, or is contained by one, displaces it and says so; that is how /viewport left agent works from a console holding full. An assignment that only partly overlaps — top while left is held — is refused by name, quoting both, because neither contains the other and there is nothing unambiguous to take away.

left and right are the outer columns, not halves. They are a fixed 320 points wide and the centre takes whatever is left — the same shape Organon's own editor has, where the side docks are fixed and the instrument absorbs the rest. Below 688 points of pane there is no room for two sides and a centre, so the column words refuse and only full, top and bottom still divide.

The model is flat, never nested, and the reason is the vocabulary rather than the geometry: a tree has no names. /viewport left agent is a sentence a person says and an agent writes; the same intent in a tree is a path through splits that must already exist. What that costs is stated rather than hidden — no uneven splits, and no dragging a divider.

Owned by native/organon-console/src/region.rs and CONSOLE_ARCHITECTURE.md.

The console

The region words#

Twelve, and each also answers to its initials. The long words are what --help, the tab completions and every refusal list; the short ones are accepted everywhere the long ones are, including /viewport in a conversation composer.

The short forms are not a thirteenth through twenty-fourth region and are never listed as though they were. They are accepted at every door and shown beside their word — twelve extra entries in the display table would present a grid with twelve shapes in it as a list of twenty-four. The pairs are written down rather than computed from the initials, so a collision or an exception is a diff rather than an algorithm nobody can contradict.

Both tables are REGION_WORDS and REGION_ALIASES in native/organon-console/src/region.rs, read by the CLI, by the console's command schema and by every refusal. A second hand-maintained copy is how a CLI comes to accept a word nothing can act on — which is why this page has a table and not a list of its own invention.

The console

What a region holds#

The whole content vocabulary is four words, and one of them is not a kind of thing.

The refusals worth knowing#

• off is refused on the last region holding an agent. A console with nothing to talk to has no obvious way back, since the verb that would fix it is typed at an agent.
• off is refused on a region that already holds nothing — a command that appears to work and changes no pixel is worse than one that says no.
• Only one region may hold an Organon-drawn 3d. That is the visualizer's constraint, not the region model's: its producer draws at most one frame per console frame. A second is refused by name, an open portal takes that frame and the region says so — and a hosted producer is not bound by any of it, so two regions may hold the same one.

Two commands fill a panel column, not one. console viewport left panel says a region is for panels; console stack add surface says which panel. That split is why neither sentence ever needs a third word. There is a column per region, so two panel regions can list different panels — but they share one parameter mirror, so two copies of a panel drive the same instrument.

/add surface typed inside a region names that region by being typed there; from a terminal the same command spells it console stack add surface --region left.

Owned by region.rs and panel_stack.rs in native/organon-console/src/.

The console

Layouts#

An arrangement of the whole pane — every region and what each one holds — written down under a name and brought back by it. viewport and stack build one; layout records it.

load is a transaction. A saved layout arrives all at once, from a file this build may not have written, so it is checked whole before a single assignment lands: every region word, every content word, that no two regions overlap, that only one holds 3d, that something holds an agent, and that today's window is big enough to draw it. If any part is refused, the refusal names what is wrong and the arrangement you are looking at does not move. It never half-applies — a layout that had evicted the last agent region would be a console with nothing to type into.

Names are exact: Desk and desk are two layouts, and a name cannot contain whitespace, because a command crosses the console's channel as one whitespace-delimited line. save replaces whatever was stored under that name and says so.

The library is layouts.json at the console's store root, beside harnesses.json. It is plain, legible JSON you may edit by hand, and fields this build does not know are kept rather than dropped. It ships empty — no arrangement is named for you yet.

There is no list on this verb, and the absence is structural. A listing is a read, and the lane a terminal writes on is fire-and-forget with no return path — so it lives where a read can be answered: /layout.list in a conversation composer, or the tool console.layout.list. Meanwhile the file above is legible.

Owned by native/organon-console/src/layout.rs.

The console

Agents and harnesses#

Every arrangement contains a working agent, and the agent operates the application — not a chat window bolted to one. It runs the same commands you type.

Which agent program a tab runs is configuration, not code. Identity, launch command, how to detect it on this machine, where to obtain it, which directory to start it in and whether it runs inside WSL are fields of a registry entry. Built-ins are seeded in code and a user's file is merged over them by id. The plain login shell is the entry every registry carries.

Somewhere to stand#

Which directory a conversation tab starts in decides which project instructions and which skills it can see. It is resolved by four rules, each with a unit test, and then reported unconditionally — along with which rule chose it, and a warning when the directory satisfies no project marker at all:

1. An explicit per-tab answer
2. A per-launch environment answer
3. The nearest project root at or above the launch directory
4. The launch directory itself

That report exists because the paradigm was failing silently at its first step. An agent asked to use a skill answered "Unknown skill", because it had been started in the application's own directory and could see no project instructions — and nothing anywhere said so. The only symptom of that is an agent that seems oddly ignorant.

Owned by CONSOLE_ARCHITECTURE.md.

The console

Skills#

A skill is instructions: text that teaches the resident agent a part of the application, loaded from the project the agent is standing in. Adding one changes what the agent can do without a rebuild.

What a good one encodes is a loop rather than an API listing — see → act → see. Read the live state, change one thing, then look again, with a rendered frame as the agent's eyes and never an assumption that a change did what was intended. The live catalog is authoritative over the skill's own prose, so a skill teaches the grammar and points at the tool for the vocabulary.

Two ship in this repository: organon-cli, which covers driving Organon from its command surface and changing the console the agent is running inside; and coordinate-sessions, for one session driving several workers.

⚠️ They are real directories, not symlinks. A git symlink under .claude/skills/ materialises as a 24-byte text file on any Windows checkout, and the skill then silently does not load — no error, no warning, just an agent that has never heard of it.

Owned by .claude/skills/ and doc/organon_prd.md §5.3.

The console

Approvals, and who outranks whom#

An agent's power is bounded by approval, not by good behaviour. Every tool it calls, shell commands included, passes one permission card — answered in-process, so the hook is a direct call into the state the interface is already drawing. A skill can teach an agent what to want; it cannot get it past the card.

Where a person and an agent can both act on the same thing, the person's action wins by construction rather than by convention, and the agent is told what happened. Dragging the viewport outranks a camera command; touching a control releases the agent's hold on that parameter.

Nothing on screen may be silent about being empty or refused. A region that draws nothing is indistinguishable from one that is broken, so vacancy is a sentence carrying the word a person would type to fill it, and a refusal names the obstacle and the command that clears it.

The work does not fail while a card is open — it waits.

Owned by CONSOLE_ARCHITECTURE.md and SECURITY.md.

The console

Hosted modules#

A 3d region takes --producer <name>, saying which producer draws it. Omitted, it is Organon — so every viewport … 3d line means exactly what it always meant.

organon console module approve fetches a repository at a commit, reads its organon-module.toml, and — if you say which grants — records an approval in modules.json. Three things about that verb are worth reading before you use it:

• With no --grant, nothing is recorded. An approve without it is a dry run: it reports what the repository asks for and stops. --grant none approves with nothing granted; a grant the manifest never requested is refused.
• Approving grants build-time trust. build compiles the repository, which runs its build scripts and every procedural macro in its dependency graph with your privileges, before any of it is composited. The separate process a module runs in bounds what it can reach through the protocol; it bounds nothing about what the compiler does. Approve repositories you would run a script from.
• The unit is a commit. --at takes a branch, a tag or a commit; what is recorded is always the forty-character hash it resolved to, with the reference beside it as provenance. Tags move and branches move; a hash does not. diff shows what has changed since the commit you last trusted, and changes nothing — trust is renewed at every update, and the update is the moment that matters.

How a module's picture arrives#

A named producer is launched and its frames are painted into the region. That is a seam rather than a call: nothing is loaded into Organon's own process — there is still no dlopen and no wasm anywhere in the tree — the module is a separate binary, and the console knows a producer name, a rectangle, a size, a texture and a channel, which is all it has ever known.

Two details are worth having before you write one. The binary is derived, never named by the module: <checkout>/target/release/<producer>, so a module's package must produce a binary named after its producer — a binary = key in the manifest would be somebody else's string arriving at a process spawn. And the handoff is an environment variable rather than an argument, so a module's own argument parser never has to know it exists, and its presence is what distinguishes being hosted from being run by a person.

A producer that stops is not confused with one that is merely slow. The process handle is asked first and the channel second — a producer that dies quietly leaves counters that stop, and the channel would call that live, then stalled, then lost: right, but late and vague, where the handle knows this frame and knows the exit code. The last good frame is never re-shown as though it were current.

⚠️ The one-region rule for 3d is Organon's, not the region model's — so two regions may hold the same hosted producer, while a second Organon-drawn viewport is still refused by name. That distinction is exactly what the content vocabulary means by attributing a limit to the thing that has it.

Owned by module_work.rs and module_host.rs in native/organon-console/src/, the organon-module crate, and CONSOLE_ARCHITECTURE.md §4.6.

The visualizer

Generator, surface, material#

Almost everything you see is the product of three independent choices. They compose freely, which is the whole design: you are not picking from a list of finished looks, you are picking coordinates.

A fourth choice, palette, retints the whole thing and is orthogonal again. Two consequences follow from the independence:

• Any surface works with any node-field generator. DNA in swept tubes and glass is the obvious one; DNA as a cloud of Gaussian splats is also available and looks nothing like it.
• Some generators emit no nodes at all. Several are raymarched per pixel, so surface modes have nothing to act on — materials still apply. A couple are dual-path: their implicit families raymarch while their parametric ones emit a node grid a surface can skin. The editor tells you which kind you are on by hiding the Surface card when it does not apply, which is the fastest check available.

The exhaustive lists — every generator, every surface, every material, with a paragraph each — are in the generated reference, and are deliberately not reproduced on this page. The live catalog is authoritative over both: organon catalog --manual, which works with nothing running.

Owned by doc/guide/concepts.md.

The visualizer

Two windows, two processes#

The plugin window is the editor. The picture is a separate process with its own window. That is not an accident of implementation, and it buys three things you will actually use.

• The visual can own a display. Put it fullscreen on a projector while your DAW stays on your laptop screen. Nothing about your session layout constrains the picture.
• The render cannot stall the audio thread. The heavy GPU work is in another process entirely.
• The visual survives. Closing the plugin editor does not disturb the picture.

The two talk through a shared-memory snapshot, once per audio block: the plugin writes, the visual reads. The visual owns the clock, the camera and any simulation state; the plugin owns the parameters. That division is why some command-surface verbs need the editor running and some need only the visual — see what needs what.

Owned by ARCHITECTURE.md and doc/guide/concepts.md.

The visualizer

Playing it#

Five things can move a control, and when several of them want the same one there is a stated priority rather than a race.

• Host automation — the DAW's own lanes.
• MIDI clips through the CC map, which is how a piece of music drives the picture.
• The Key Map — notes recall presets.
• The pad controller and the knob bank, for hands on a surface.
• The command surface, on an override lane that sits on top of the controls rather than replacing them.

The human always wins. Move the physical control for a parameter an agent or a script is holding and the hold on that parameter is released. That is intended, and fighting it is the wrong instinct. organon release hands everything back.

Owned by doc/guide/performance.md, whose last section is the full priority order.

The visualizer

Presets and recipes#

Two different things with a similar shape, and knowing which you want saves an argument with the instrument.

A preset is yours: a captured look, saved as a scene or as a component, recalled on a beat boundary and applied atomically so a recall never lands half-done. Presets live in the application's own store directory, alongside the network gallery.

A recipe is built in: a named starting-point compiled into the binary, which selects a generator, surface and material and sets the parameters that make the look, through the override lane. You need no saved presets to make something — organon recipes lists them and organon recipe <name> --dry-run shows exactly what one would change before it changes it.

Owned by doc/guide/presets.md; the recipe list itself is generated.

Organon Mind

Watching a model think#

Point Organon Mind at a .gguf and it draws the model's true architecture — read from the file, not invented and not inferred from the file's name or its size — then lights it up while it runs.

It is a reverse-engineering workbench whose interface happens to be a rendering instrument. Layers, heads, key-value heads, experts and vocabulary are all read out of the header. Two extra binaries sit behind default-off features and opt-in flags: a writer that produces synthetic activation frames with zero inference — the model-free proof that the display is driven by data rather than by decoration — and the embedded inference runtime that produces the real thing.

It is standalone-only, deliberately, and will stay that way: no plugin build, no second plugin class identity, and none of a host's audio-thread constraints.

Owned by MIND_ARCHITECTURE.md — what exists right now, plus its honesty ledger — and by organonmind.org for the research.

Organon Mind

Provenance#

Every displayed quantity carries a marker saying where it came from, where a person is looking — not only in a document.

A marker travels with the number. Add a readout and it carries one, and goes in the honesty ledger.

The ledger names the current largest gap rather than hiding it — the per-layer generation glow is a labelled proxy, entropy and confidence, not real activations. The rule that makes the instrument trustworthy is the same one that lets a newcomer be genuinely rather than misleadingly impressed.

Owned by MIND_ARCHITECTURE.md §3.

The command surface

See, act, see#

organon talks to a running Organon. It is the fastest way to explore the instrument, and it is the way to script it or hand it to an agent. The loop that matters is: read the state, change one thing, look at the result. Do not assume a change did what you meant.

organon status                       # what is loaded right now
organon set metallic 0.9             # change one thing
organon snap -o /tmp/look.png        # look at it

The tool documents itself, and the live catalog is authoritative — if it ever disagrees with a page, believe the tool. catalog, describe, recipes and docs all work with Organon not running, because the descriptions are compiled into the binary.

Selectors take a name, an unambiguous substring, or an ordinal — organon generator 2, organon generator dna and organon generator "DNA double helix" are one command. Parameters are set in raw units, not normalized, and negative values work as you would expect.

Owned by doc/guide/cli.md.

The command surface

The verbs#

Every one of these takes --help, and most take --json for machine consumption. organon completions <shell> prints a completion script for bash, zsh, fish and the rest.

A verb exists for everyone or for no one. The command line, a slash command in a composer, an agent's tool call and a control inside a region converge on one dispatch, and two tests hold them there: that every console verb is typeable as a slash command, and that all surfaces of a verb produce the same operation value. That is not tidiness. A command expressed to an agent as prose was measured at thirteen seconds and a chunk of context — inference, a tool search, and an approval card asking a person to approve their own command. The slash lane removes the inference and the card. It does not remove the discipline.

Owned by native/src/bin/ctl.rs, which is where --help comes from.

The command surface

What needs what#

This trips people up, and the two failure modes look similar and are not.

So organon status failing with only a visual running is structural, not a timing problem — waiting will never fix it, and the answer is to start the editor. Whereas organon snap timing out usually is timing: the visual is still coming up, or its window is covered or unfocused. Retry that one.

Commands written while the visual is down are deliberately not replayed at its next start. A queue that fires on connect is a queue that surprises you.

Owned by doc/guide/cli.md.

The command surface

organon console#

A namespace of its own rather than more top-level verbs, and the split is not cosmetic. Every other verb addresses the world — what Organon renders, answered by the visual or by the shared snapshot. These address the console: a different process's own state, on a different channel, meaningful only when a console is running.

What sticks and what does not#

theme is the one that persists. The change is live — the window repaints on its next frame — and it is written to preferences, so the next console opens on it. That is the point of a verb rather than a launch variable: four palettes compared by relaunching four times is not a comparison. ORGANON_SHELL_THEME overrides a stored choice for one launch, says so on the console's stderr when it does, and never writes.

Everything else opens fresh. Posture, full screen, the division of the pane and the contents of a panel column are all how you left them only until you close the window. A posture is a view you take to look at something, not what the console is made of — and a saved layout is the way to keep an arrangement.

📌 F11 flips full screen from inside the window, at any time, in any tab. That is a real way out: no title bar means no close button, and the function keys are the one band a terminal has never sent to a child — so unlike Escape, claiming it takes nothing away from vim.

Owned by native/src/bin/ctl.rs and the console crate's own modules; organon console <verb> --help carries considerably more than this table.

The command surface

Running two at once#

Organon, Organon Mind and Organon Console each use their own IPC namespace, which is what lets them run side by side without trampling each other. ORGANON_IPC_NS selects it — and the command surface reads it from its own environment.

export ORGANON_IPC_NS=organon-mind   # now the CLI addresses Mind

Export the same value the application was launched with, or you will read one product's state while trying to steer another's. The default is organic-math — one of several internal identifiers that deliberately keep the old name, because something else reads them and renaming would orphan it.

The same variable runs two plain Organons at once: give each a distinct namespace at launch.

Owned by ipc.rs's namespace resolution and ARCHITECTURE.md.

Reference

The generated reference#

Every generator, surface, material, parameter and recipe, with a description each and, for a parameter, its kind and its range. It is generated from the Rust source by organon docs, and a test fails the build the moment a checked-in page drifts from the code.

🚨 That is why it is not on this page. A copy of those tables here would be a second copy that nothing pins — it would be correct on the day it was written and wrong the first time a description changed, with no test anywhere to notice. The link is the honest form. Fix a description by editing the Rust and re-running organon docs, never by editing the Markdown.

• GeneratorsThe geometry engines — what each one makes
• SurfacesHow a generator's nodes become geometry
• MaterialsHow that geometry is shaded
• ParametersEvery settable control, with its kind and range
• RecipesThe built-in starting-points, and exactly what each changes

The command surface serves the same material from the same source, so the two cannot disagree — and it is closer to hand when you are already at a terminal:

organon catalog --manual     # all of it, in the terminal
organon describe dna         # one entry, in depth

Reference

State of play#

This page describes what Organon is and how to work it. What it currently does — which principles are enforced by mechanism, which are designed and unbuilt, and which claims are direction — is one table, kept in one place.

It is on the landing page, kept current there, and it says where it stands against doc/organon_prd.md §12 rather than quietly disagreeing with it. It is not repeated here, and not even quoted in part, for the same reason the reference is not. Read it before you rely on anything above.

⚠️ Quoting two of its lines is what an earlier draft of this section did, and it was wrong within a day. It said hosted modules had nowhere to draw — true of §12, which is dated a day earlier, and false of the tree, where a producer is now launched and painted into a named region. That is the argument in miniature and worse than the plain version of it: a partial copy of a state-of-play table goes stale, reads as authoritative, and cannot be corrected by the change that invalidated it, because nothing links the two. This section now points and says nothing of its own.

Reference

Working on it#

Read CONTRIBUTING.md first, then ARCHITECTURE.md. Between them they carry the scoping pattern, the review cycle and the verification bar, which is a real bar and not a slogan.

Three habits the repository holds you to, worth knowing before your first branch:

• A document is updated in the same change as the code it describes, and hooks say so when it is not. Docs are not a follow-up ticket here.
• A change is recorded as one file in changelog.d/, not as an edit to CHANGELOG.md. Two branches writing two files do not conflict; one shared insertion point conflicts by construction.
• Branch off main, and do not stack pull requests. A PR stacked on another PR's branch can land on a dead branch and never reach main even though the interface says "merged".

New capability defaults to inert — off, or set to a value that reproduces today's behaviour. That is what lets a large feature land one tier at a time over weeks without any of those weeks being a broken build.

Reference

Licence#

The split is deliberate, and flattening it would be the expensive mistake it looks like a tidy-up.

Making the licences consistent would relicense a reusable engine onto the terms of a plugin binding.

A project outside this repository can depend on the engine crates directly, and that path is proven rather than asserted: a separate repository consumes several of them pinned by commit, with a licence-graph gate in CI as the enforcement.

Owned by LICENSING.md, which carries the reasoning and what it constrains.