Documentation
Most documentation sites are organised the way the product was built. This one is organised by who is asking — because an evaluator, an administrator, a developer and a compliance officer want four different first pages.
What GimCore is, what it is not, and how the 30-day evaluation runs on your own infrastructure. The claim register, in full, with the status of every figure.
Evaluation guide → AdministeringScreens, fields and their formats, relationships, workflows and post actions. How to change what a module does without changing code.
Administrator guides → BuildingThe metadata model, the field type reference, the post-action catalogue, and what a Tier 2 source licence actually hands you.
Developer guides → AssuringDeployment topology, the three-tier audit trail, access model, and the control mapping your auditor will ask to see.
Architecture & security →App guides
A guide is generated from the app's own definitions, so it describes the screens, fields, relationships and automations that actually exist — not the ones that existed when someone last wrote a manual.
This is a direct consequence of the architecture: because behaviour is metadata, the documentation can be read out of the same place the application is.
Training
Administrator and end-user training is delivered as courses inside GimCore, so completion is a record rather than an assertion — which is the same thing your compliance officer wants for every other mandatory training.
Ask about enablement →Reference
Release
Release notes carry the same status labels the rest of this site uses, so a line that says in build in the notes says in build on the marketing pages too.
Not finding it
Documentation answers what we anticipated. An evaluation answers what you actually asked.