# bkn-foundry: no interface, no command line, and three licence files > A Go back end for an ontology-driven business knowledge network, installed onto Kubernetes by a root-run script that creates a business user called test, grants it every role and switches the CLI to it. The docs toolchain pins five transitive packages by hand, and the licence detector could not classify three files. **openbkn-ai/bkn-foundry** — BKN Foundry is the Ontology back-end foundation of OpenBKN. It transforms ontology-driven business semantics into runtime services: data, logic, actions, security governance, and observability. - Repository: https://github.com/openbkn-ai/bkn-foundry - Stars: 605 · Forks: 55 - Language: Go - License: NOASSERTION - Published: 2026-09-20 · Updated: 2026-09-20 · Language: en - Canonical page: https://hysenlabs.com/projects/openbkn-ai-bkn-foundry ## No web interface, no command line, and the tools you need are elsewhere The first note on the page is a scope statement that changes what this repository is. BKN Foundry is backend only, it does not include a web interface, and every interaction goes through a command line, an SDK or an API. Then the next step tells you the command line does not live here either: it comes from a separate SDK repository, which holds the end-user and agent command line, a TypeScript SDK, and an agent skill, installable globally or run without installing. Runnable end-to-end walkthroughs are in a third repository. What this repository does contain is the services, the deployment directory, database migrations, the product documentation in two languages, and the API reference. So the practical shape of evaluating this is that you install a Kubernetes cluster to try a system whose interface is a binary you have to fetch separately. ## The preflight check has three exit codes and fixes only what you allow Before the install script runs, a separate preflight script checks the target host and is the most carefully designed piece of the deployment tooling. It verifies the kernel, sysctl settings, containerd, kubectl, helm, Node and the project's own command line binaries, and it distinguishes three outcomes through exit codes: zero for fine, one if anything failed outright, and two if there were only warnings. The fix behaviour is opt-in per item, which is the right default for a script you run as root. Four invocations are documented: check-only, check with interactive fixes, check with every fix auto-approved, and a listing mode that previews which fixes would run while changing nothing. There is also a report flag to keep a full log, and role and skip flags to narrow the run. ```bash sudo bash ./preflight.sh --fix -y # auto-approve every fix sudo bash ./preflight.sh --list-fixes # preview which fixes would run, no changes ``` ## The bootstrap script creates a user called test and gives it every role The post-install step is recommended rather than optional, and it is where the sharpest edge in this repository lives. The script is re-runnable, and it registers a language model and an embedding, patching the project's configuration maps only when the default embedding genuinely changes, which is a careful touch. On a full install it also creates a business user named test, assigns it every role the system knows about, and switches the command line to that user. The next step then documents the login for that user and states the default password as a six-digit string unless you overrode it. Two facts together: a named account created automatically, given every role, with a published default password. If the cluster is reachable from anywhere before you change that password, the provisioning script has handed over the whole installation. ## Running the bootstrap without sudo changes which endpoint it talks to The documentation explains at length why the post-install script wants root, and the explanation is the interesting part. The script reads a configuration file from the home directory of whoever runs it, and that file was written into the root account's home by the install script. It also writes the authentication token to the user's own home. Run it without root and it falls back to the configuration template in the repository, which may resolve a different access address. So the privilege is not cosmetic: it selects which configuration file is authoritative, and getting it wrong does not error, it quietly points the command line somewhere else. The macOS development path is the exception, and the documentation says so. Two configuration files, two homes, and a silent fallback between them is a design worth questioning even when it is documented. ## Three licence files and a detector that could not choose The repository root contains a licence file, two licence files with explicit names naming Apache and the project itself, and a notice file. The repository's recorded licence field, meanwhile, is the value GitHub uses when its detector cannot classify a project at all. Nothing on the visible page explains which terms apply to which component, and this is a repository whose whole purpose is to be embedded in someone else's business system. The two named files suggest a deliberate split between the foundation and something else, which is common and legitimate, and the right response is to ask rather than to guess. This article does not pick one. If the distinction matters to you, and in an enterprise platform it usually does, get an answer in writing before you vendor it. ## The published module list is hand-written so a module can be withdrawn The API documentation build has a rule worth stealing, and the comment explaining it is better than the rule. The list of published service modules is written out by hand in the build file rather than globbed from directories, because globbing sorts by directory name and produces accidents in the site order, and because a glob cannot temporarily take a module off the published surface. The hand-written list also fixes the display order, so changing it changes the site. Two modules are deliberately unpublished: one holds self-service reads and internal authorisation contracts that are not meant to be general integration APIs, and one has only a configuration file with no publishable specification, so rendering it would produce an empty group. Both are still linted, on the stated grounds that service-to-service request and error schemas must not drift silently. ## An unregistered module directory fails the build The same build file carries a reconciliation check that turns a documentation omission into a hard error. Every module directory under the API directory must appear either in the published list or in the unpublished list, and the build stops with an error naming any directory that does not. The comment states the intent plainly: it prevents a module from being added to the repository and quietly never appearing on the site. The generated output is excluded from version control as well, with the YAML specification named as the single source of truth, the interactive HTML rendered by one tool and the Markdown rendered on demand by another. So the documentation pipeline is generated, ordered, gated and clean in the repository, which is more discipline than most service repositories manage for their API reference. ## A developer's virtual machine address is committed as a build default The tail of the build file configures a contract inspection that compares what a service actually returns against what the documentation claims. Its defaults are overridable, which is good practice, but the values committed are a private network address belonging to a named developer running a virtual machine, a namespace, a pod path, and a fixed identifier that looks like an account or tenant ID, with a comment noting that the default opens the development machine's internal interface without needing a token. None of those values is a credential. All of them are environment details that should not have to be edited before the check is useful, and the account identifier in particular is the kind of value that ends up in a bug report. Everything before this is careful engineering, and then the last twenty lines are one developer's laptop. ## Conclusion This is an infrastructure repository rather than a product you evaluate by running it, and the install path is the part to read closely. Three things to know before you deploy it. The bootstrap script is the sharp edge, since it provisions a named user with every role and a documented default password, so change both before the cluster is reachable. There is no interface and no command line here at all, so a first evaluation means installing the separate SDK repository. And with three licence files and no clear statement of which covers which component, ask before you vendor it into a product. ## FAQ ### What is BKN Foundry? The backend foundation of OpenBKN, an ontology-driven business knowledge network platform, written in Go and licensed under Apache. It turns data and logic scattered across documents, systems and rules into a knowledge network that agents can read and execute, providing data access, execution safety, governance and tracing. ### Does BKN Foundry come with a web interface or a command line? Neither. It is backend only, with no web console, and the command line, TypeScript SDK and agent skill come from a separate SDK repository, installable globally or run without installing. Runnable walkthroughs live in a third repository. ### What does the preflight script check before installing? The kernel, sysctl settings, containerd, kubectl, helm, Node and the project's own binaries, exiting 0 when fine, 1 if anything failed and 2 if there were only warnings. Fixes are opt-in per item, and there is a listing mode that previews them and a report flag for a full log. ### What does the post-install bootstrap do? It is re-runnable and registers a language model and an embedding, patching configuration maps only when the default embedding actually changes. On a full install it also creates a business user named test, assigns it every role the system knows, and switches the command line to that user, whose default password is documented unless you override it. ### Why does the bootstrap script need root privileges? Because it reads a configuration file written into the root home by the install script and writes the authentication token into the invoking user's home. Without root it falls back to the repository's configuration template, which may resolve a different access address, so the privilege selects which configuration is authoritative. ### What licence applies to BKN Foundry? The repository root carries a licence file, a second file named for Apache, a third named for the project, and a notice file, while the repository's recorded licence field is the unclassified value. Nothing visible states which terms cover which component, so ask before vendoring it into a product. ## Sources - [Issues](https://github.com/openbkn-ai/bkn-foundry/issues) - [openbkn-ai/bkn-foundry on GitHub](https://github.com/openbkn-ai/bkn-foundry) - [README](https://github.com/openbkn-ai/bkn-foundry/blob/main/README.md) - [Releases](https://github.com/openbkn-ai/bkn-foundry/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openbkn-ai-bkn-foundry