Frequently asked questions

Every engagement starts with discovery: we review what runs today, surface constraints and risks, and agree success criteria in writing before any architecture work begins. The output is a written scope.

From there the work runs in four stages — discovery, architecture, build, operate — each with a defined output. See our approach in full.

Working software in your environment, a test suite you can run, environment and deployment configuration, and handover documentation. Where we also operate the system, you get dashboards, alert rules with routing, runbooks, and defined escalation paths.

Each service line names its deliverables explicitly. See what each covers.

You do. Work delivered under an engagement belongs to you, including the code, configuration, and documentation. Where we apply one of our reusable systems, we will say so in the scope and agree the licensing terms up front rather than leaving it ambiguous.

Both. A large share of the work is on systems already in production — hardening them, making them observable, or untangling integrations that have grown past their original design.

If you are running something that works but nobody wants to touch, that is a normal starting point.

Either. Some clients want a clean handover with runbooks and documentation; others want us to carry operational ownership. We do both, but we decide which at scoping time, because the two produce different architectures.

We operate our own platform, CaQeh, so the operations practice is one we depend on rather than one we only recommend.

It means models doing a named job inside a system that has tests, monitoring, and failure paths — classification, extraction, forecasting, detection, scoring. Not a chatbot bolted onto a product.

Our systems library lists each module and the concrete jobs it does. If a problem does not need a model, we will say so.

No, and we will not imply otherwise. We do not hold compliance certifications on your behalf, and our controls do not satisfy an audit you have not run.

What we do is implement controls matched to the risk of the system in scope: access and secrets, abuse resistance, observability, and change control. If your obligations require formal certification, we will say so and scope the engineering work that supports it. See what we put in place.

We treat the model surface as an attack surface. That means input validation at the boundary, rate limiting, defense against injection and prompt manipulation, audit trails for privileged actions, and monitoring for drift and data-quality regressions on serving paths.

Sentinel, one of our systems, exists specifically for this. See the systems library.

It varies by scope, and we would rather size it against your problem than quote a bracket that turns out to be wrong. Discovery is deliberately small — enough to establish whether there is a fit and what the work actually is — before either side commits to a build.

Tell us what you are running and we will come back with a scope.

The engineers doing the work. There is no account layer between you and the people writing the code.

Taxel Technologies Ltd is a registered company; our registration details are published in full on the about page so you can verify who you are contracting with.

For systems we operate, alerting routes to a named owner with defined escalation, and incidents are detected before customers report them — that is what the observability work is for.

For systems we handed over, you get runbooks for known conditions and rollback paths that have been tested rather than assumed.

Email hello@taxeltech.com or use the contact form. Tell us what you are running, what is failing, or what you need to ship. A short technical conversation costs you nothing and tells both of us quickly whether there is a fit.