About — Centralux

§ 01

What the company is

Centralux is a small, deliberately-small engineering firm. Founder-led means one accountable engineer designs the system, writes the specification and stands behind the result — not a partner who sells and a bench you never meet. Work is taken on in fixed-scope phases so that capacity is honest: we can only run a small number of builds at a time, and we would rather say so than queue you behind a pipeline.

Our clients are typically operators between roughly ten and a hundred and fifty people, in trades and field service — the businesses where a job moves physically through the world and the paperwork has to keep up with it. Adjacent operations with the same shape, where an order moves through stages and money follows it, fit for the same reasons.

We use language models heavily, and carefully. They are genuinely good at reading messy human text, classifying, drafting and summarizing. They are the wrong tool for arithmetic, pricing rules, scheduling logic, and anything you would ever want to audit — that work belongs in deterministic code where it can be tested and re-run to the same answer. Most of what people call “AI failure” is a language model placed where a database belonged.

Company record

Legal entity: Centralux AI LLC
Entity type: Limited liability company
Jurisdiction: North Carolina, United States
NC SOSID: 3313485
D-U-N-S: 14-705-9627
Office: 109 Hay St Suite 202Fayetteville, NC 28301
Contact: contact@centralux.ai

§ 02

Where it operates

The office is at The Hub, 109 Hay Street, in downtown Fayetteville — the same address that appears on our invoices and on every business record we hold. Being physically near the operations we build for is not incidental to the work. The flow-mapping session that opens every engagement goes better in a truck, a yard or a job trailer than it does on a video call.

Delivery is remote after that, and we work with clients across the United States. Build, review and handover all happen well over video and shared systems. Where an on-site day is genuinely worth it — cutover, training a crew, watching the real process — we schedule it explicitly and price it in the phase rather than discovering it later.

Operating parameters

Base: Fayetteville, North Carolina
Delivery: Remote, with scheduled on-site days for mapping, cutover and training
Served: United States
Sectors: Trades and field service first; adjacent stage-and-settle operations by fit
Concurrency: A small number of active builds by design, so each has a named engineer on it

§ 03

How an engagement works

Three phases and a defined exit. Each phase is quoted flat, up front, with an explicit list of what is not included. You decide at the end of each one whether there is a next.

Fig. 03 — Engagement sequence Exit available at every node

Phase 00 Calibration We map the flow you actually run and write the specification for what gets built, at what price, with what excluded. Fixed fee. Yours to keep and build elsewhere if you would rather.
Phase 01 Build The specification gets built and put in front of real users on real work. Flat fee per phase. Source, schema and runbook transfer at the end regardless of what happens next.
Phase 02 Operate or extend Optional. A defined monthly scope for changes, monitoring and the next channel. Month to month. No auto-renewing term and no notice penalty.
Exit Handover Everything is already yours; this is the walkthrough. We transfer ownership to your team or your IT provider and answer questions during a defined window.

Schematic. Phases are sequential; the exit node is reachable from any phase and is priced at zero because the artefacts have already been handed over.

How we price

Flat fee per phase, quoted before the phase starts, from a written scope. Not hourly, not per seat, not per user.
Scope changes are re-quoted, not absorbed silently and not billed as a surprise. A change order is a short document you approve.
No revenue share and no equity in place of fees. Our pay should not depend on your execution risk, and yours should not depend on ours.
No software licence to us. You pay the underlying vendors directly — cloud, model providers, whatever the system uses — at their price, on your accounts.
Month-to-month if you take an operate phase. Cancel with notice, keep everything.

What we need from you

One decision-maker who can settle questions about how the business actually works, and is available during the phase.
Access to the current tools, in read-only form to begin with.
A handful of real, complete jobs to test against. Not sample data — the messy ones teach us the most.
Someone from the team who will use the thing, in the room early, telling us when it is wrong.
Honesty about the parts of the process that are informal. Undocumented workarounds are the single biggest source of surprise late in a build.

§ 04

The data-integrity stance

This is the part of the practice that is a genuine position rather than a preference, so it is worth stating precisely. A system that automates a business decision inherits that decision’s consequences. The engineering question is not whether it works on a good day — it is what it does on a bad one, and whether you can tell the difference from the outside.

Every guarantee below is enforced in the build, appears in the written scope, and survives handover because it lives in the code and schema rather than in a habit of ours.

Isolation One client, one system, one datastore. Your records live in infrastructure you own, under credentials you hold. There is no shared multi-tenant database in which a query bug can cross a client boundary, because there is no boundary to cross. It also means your data is never a training input for anyone, including us.
Provenance Every automated write says where it came from. Source, actor, timestamp, and the input that produced the value. This is what makes an audit trail an audit trail rather than a log file: you can start from a number on a customer document and walk backwards to the event that created it, without asking a person to remember.
Gating Outward actions require a human release. Anything that leaves your business — a customer email, an invoice, a payment request, a document sent for signature — is drafted by the system and released by a person, by default. You can loosen a specific gate once you have watched it behave, deliberately and in writing. We will not quietly widen it for you.
Refusal Missing is not zero. When a value cannot be resolved, the system stops and says so. It does not substitute a zero, a blank, a stale figure or a plausible default, because those are indistinguishable from real values downstream and they corrupt every decision built on them. Loud failure is cheap; a confidently wrong number is not.
Recoverability A restore nobody has run is not a restore. Backups are configured and then rehearsed against a copy, end to end, with the actual procedure written down afterwards. Anything that deletes or overwrites at scale is preceded by a snapshot and a tested way back.
Reversibility of us You can fire us without losing the system. Source, schema, infrastructure config and runbook transfer at the end of every phase, not at the end of the relationship. The commercial consequence is intentional: the only reason to keep working with us is that the next phase is worth buying.

§ 05

The name and the mark

Central + lux. Latin lux, light — light at the centre. The name describes what the work does to an operation: it takes information that is spread across a dozen places and puts it in one place where it can be seen. That is the whole thesis, and it is why the mark is a C holding a single form at its centre rather than a picture of a machine.

The mark itself is specified, not sketched. Every dimension derives from one construction unit — the half-diagonal of the central diamond — and the proportions are fixed, including the one that is not obvious: the ratio of the arc’s stroke width to the diamond’s width is 1 : φ². We hold ourselves to the same standard on the logo as on a schema. It seemed dishonest not to.

Fig. 04 — Mark construction 1024-unit grid

#E3B23EGold

#0B0D0FInk

Construction unit d: 128 — the diamond’s half-diagonal
Inner radius: 256 = 2d
Outer radius: 353.78
Stroke width: 97.78 — stroke : diamond width = 1 : φ²
Inner aperture: 60° — terminations at ±30° from the axis
Terminals: Vertical, cut on one line at x = 799.74
Centres: Arc and diamond share a centre at (578, 512)

Construction drawing. Dashed geometry is the derivation, not part of the mark; the solid gold figure is the mark exactly as it ships.

§ 06

Fit

This works well when

The operation has outgrown its tools and everyone knows it, but nobody has had time to redesign the flow.
There is a decision-maker who can answer “how does this actually work” without convening a committee.
You want to own the result — source, data, credentials — rather than rent access to it.
You would rather hear “that part is not worth automating” than be sold the largest scope that fits your budget.

This works badly when

The goal is a demonstration for a board or an investor rather than a system people use.
Nobody internally can commit time during the build. A system built without its users is a system nobody adopts.
The real problem is a process disagreement between two people. Software will encode the disagreement, not settle it.
The operation is small enough that an off-the-shelf product covers it. We will say so, on the first call, for free.

Next step

Start with the call, not the contract.

Nothing about an engagement begins before a written specification you have read and agreed to. The first conversation costs you a scheduled hour and produces an honest read on whether there is a project here at all.

Book a discovery call → Services specification

An engineering firm, not an advisory one.