Luminara on burov.de
Luminara is Juri Burov's public assistant on this website. It answers questions about his work from published content, remains read-only, and points to relevant pages.
AI Assistants
AI assistants for websites and applications
A good assistant does more than answer questions. It explains approved content, helps people find their way, and leads directly to the relevant page, function, or next decision.
Luminara and comparable solutions are designed for their operating context: with traceable sources, bounded context, suitable permissions, and an integration into established systems.
The chat is visible. The real work is in knowledge, context, architecture, and clear rules.
Three examples in practice
Public orientation and context-sensitive work assistance
Kontextklar
On the Kontextklar website, Erklärbert Funkelblatt explains services and technical concepts around AI. The knowledge pages and AI helper use the same reviewed knowledge base; answers point to relevant sources.
LigaWerk
LigaWerk is Symfony-built software for managing inline-hockey federation league operations. Its AI assistant is an additional capability: public chat and context-sensitive help in the protected workspace.
Three realistic scenarios
Where an assistant provides concrete help
The right starting point follows the existing content and system, not a predetermined AI toolkit.
Landing page or microsite
An independently deployable PHP module complements an existing website. Approved public pages become a verifiable knowledge base; the assistant answers recurring questions and links directly to the relevant content.
Suitable for orientation, services, FAQs, product entry points, or service entry points.
Symfony application
Markdown can form the knowledge source. Public pages receive a context-sensitive assistant; in a protected area, help additionally follows the current view, role, and permission.
Suitable for domain applications, onboarding, support, and guided workflows.
TYPO3 with Solr or ke_search
TYPO3 remains the editorial source. An OKF export and existing search indexing can be connected so the assistant works traceably with updated content.
Planned integration path: architecture and operating model are validated before any product promise.
From source to advice
Answers remain tied to content and useful next steps
An assistant does not receive a generic knowledge database or full access to a system. It receives only the content selected for a question and the permitted context.
LLM Wiki as an approved knowledge source
Markdown or a verified CMS export remains traceable. Andrej Karpathy’s LLM Wiki idea and a derived OKF bundle make content origin and updates visible.
Targeted prompt from selected sources
A JSONL search corpus selects suitable excerpts. For small, curated knowledge collections, no separately operated database, vector database, or embedding pipeline is required.
JSONL instead of a vector database
The application passes selected evidence to the model, bounds its answer, and shows directly linked relevant content. Sources remain additionally available for verification.
Technology and runtime: PHP/Symfony behind Luminara on burov.de
Eleventy generates the static pages. At runtime, static HTML, CSS, and JavaScript plus PHP/Symfony are sufficient; Eleventy is involved only while building the website. A downstream build automatically derives a verified OKF v0.2 bundle and a file-based JSONL search corpus.
Luminara first classifies each question, selects relevant source excerpts, and searches only approved, published website content. The structure follows Andrej Karpathy’s LLM Wiki idea: a readable, maintained knowledge source rather than an opaque data store. The server-side PHP/Symfony application selects relevant sources, builds a bounded prompt from them, and shows the material it used in the chat.
Luminara was created, conceived, and technically implemented by Juri Burov. He is responsible for the architecture, knowledge base, and user interface of this source-grounded assistant solution.
Why the context remains bounded
Private files, the browser DOM, and arbitrary system data do not belong in a prompt. In protected applications, roles, current views, and the permitted knowledge space are determined server-side.
From idea to first value
A clearly bounded pilot instead of an undefined AI project
1. Clarify needs and sources
Which questions do visitors or users ask? Which content is approved, current, and owned by a responsible subject expert?
2. Select one visible area
For example, one product group, service area, knowledge page, or a bounded administrative workflow.
3. Review the answer boundaries
Source coverage, direct links, safe non-answers, permissions, updates, and an appropriate operating model are evaluated before expansion.
For agencies
Let your customers’ websites speak.
Strategy, editorial work, design, and the customer relationship stay with the agency. The technical answer layer complements them where knowledge preparation, retrieval, Symfony/API integration, and controlled operation are needed.
The assistant is neither a foreign body nor a promise of omniscient answers. It makes approved content more useful for visitors and users.
Next step
What should your website explain or make easier in the future?
The starting point is a concrete visitor need, the available content, and the technical landscape. From there, the suitable scenario and a sensible first pilot can be clarified.
For agencies and technical teams, the follow-up question is: What is your scenario?