Common questions

These are the questions that come up in every serious evaluation. The answers below are the same ones you will find in the contract.

Ownership and licensing

Who owns the code we receive?

Two clean layers. Everything in your project source tree - your business logic, your native modules, the generated bindings, compiled artifacts, tests, and documentation - is 100% yours. The embedded FalconSmith engine remains the property of its author; you receive a perpetual, royalty-free, internal-use source license for it, bound to the delivered repository.

Is any of it a black box?

No. The engine is delivered as plain-text, unencrypted Python source. No compiled engine binaries, no encrypted payloads, no telemetry, no phone-home. Inspection is inherent to delivery.

Can we modify the delivered system?

Yes, indefinitely. You can add Python and native code, extend the library, and even modify the engine itself. Modifying the engine shifts responsibility for correctness to the modifying party and lifts the associated guarantees - the standard trade, stated up front.

Can we copy the engine into other projects?

No. The license covers the delivered repository and its evolution, not cloning the engine to bootstrap new, separate projects. Each generated library is produced, verified, and delivered as its own engagement. Within your delivered repository there are no usage limits of any kind.

Who owns work done for us under consulting?

Anything written into your project source tree under consulting is work-for-hire: 100% your IP on payment. Engine improvements remain part of the engine, and every engine improvement flows to you through updates.

Vendor risk and independence

What happens if we end the support agreement?

Nothing changes technically. The license is perpetual and survives termination. The system keeps building, testing, and documenting itself offline, forever, with no vendor involvement. Support is something you keep because it is useful, not because the system stops without it.

What happens if the vendor disappears?

The same answer, by design. Everything needed to build, verify, and evolve the library is inside your repository and your internal network: plain-text engine source, pinned toolchains, offline package storage. There is no external service in the loop and nothing to expire.

Does the system ever contact external servers?

No. Builds resolve every dependency from your internal, pre-verified storage. Public package indices are never contacted at build time. The system is designed for air-gapped operation.

What about vulnerability scanning and SBOMs?

Integrity and security are different problems, and FalconSmith is honest about which one it solves directly. Hash pinning guarantees that what you build is exactly what was approved; it does not judge whether an approved package has a known vulnerability.

What the design gives your security process: every dependency, Python and native, is enumerated and hash-pinned in standard-format manifests and lockfiles - the exact inventory an SBOM requires, machine-readable, always current. Standard audit tooling runs against them as-is: pip-audit against the resolved lockfiles, cargo audit against the vendored crate set. A license inventory ships with the delivered library. And because every new dependency enters through one governed promotion step, your security review has a single, auditable checkpoint - nothing enters the approved baseline silently.

FalconSmith does not bundle a vulnerability scanner. It makes your existing one authoritative, because the inventory it scans is guaranteed complete.

Working with the system

How do developers add a new package?

Locally, with one command, on their branch. The addition is recorded as branch state, teammates who pull the branch can sync it, and the approved baseline stays untouched. When the addition earns its place, an administrator promotes it into the official runtime with one command, and every machine reconciles to the new baseline on its next activation. Freedom to experiment, one governed path to permanence.

What does drift look like in practice?

Visible and boring. Every environment activation checks the machine against the approved manifest and says exactly what differs and what to run. Deviations are recorded, reconciliation is one command, and the history of what changed is kept.

Do we need build-system specialists?

No. There is no build DSL to learn and no configuration language. Developers use standard git, standard Python imports, and a handful of commands. Native C++ and Rust code is compiled incrementally by the engine and exposed to Python automatically. The delivered library includes fully worked native examples with complete bindings and documentation, intended to be copied as blueprints.

What is verified, and when?

The full test suite ships inside the library and runs at generation, at every clone setup, and on demand. Documentation is regenerated from the actual code, so the rendered API reference matches what is built. A clone that sets up green is a proven environment, not a hopeful one.

How does this fit into CI/CD?

A CI runner is treated exactly like another developer machine, because that is what it is: clone the repository, run the setup, and the environment materializes, native modules compile, and the full suite runs - the same blocking verification a developer sees. Every engine operation is a plain command with a meaningful exit code, so it drives any pipeline - GitHub Actions, GitLab CI, Jenkins, or a bare scheduled runner - without plugins or agents.

Because builds need no public network access, self-hosted and air-gapped runners are the natural case, not a special one. There is no FalconSmith CI product and none is needed: the delivered library already contains everything a pipeline has to execute.

Engagement and support

What does a pilot look like?

A scoped, fixed-price installation on one real workflow. Dependencies are inventoried up front so everything is pre-packaged; the central library is installed on your server, tests run, code lands in your git, and the runtime storage is published on your network. One developer is guided through a clean-machine setup, and the team is walked through daily work. Acceptance is measured, not felt: clean-machine setup time, offline rebuild, drift detection, and documentation integrity are all demonstrable pass/fail gates.

What determines the cost of a full installation?

Scope, stated before signature: the number and complexity of native dependencies and custom libraries, the size of the dependency tree, and the number of teams and machines involved. What moves the price is agreed in writing up front, not discovered later.

What does ongoing support cover?

A monthly agreement covering support hours, troubleshooting, and all future toolchain maintenance: new Python versions, compiler updates, and native toolchain migrations, including binding updates. Custom feature development in your project source is scoped and billed separately, so support costs stay predictable.

Can we see it live before committing?

Yes, and you should. The standing offer is a live technical walkthrough: a clean clone set up in minutes, a native change compiled and used from Python, an intentional compiler error shown raw in the terminal, and the governance loop end to end. Bring your skeptics.