The difficult questions belong before procurement.

No. Air-gapped and on-premises architectures can keep documents, indexes, prompts and responses inside the client-controlled boundary. Dedicated Swiss hosting is a different custody choice, and a policy-gated hybrid explicitly defines which non-sensitive requests may leave. The selected architecture and its exceptions are documented before implementation.

Not by default. The client archive belongs on the client-owned or expressly contracted environment. Support access, diagnostic exports and temporary transfer paths are separately scoped, time-bound and logged. A contract must state retention and deletion duties for any exceptional copy.

Not unless the client explicitly commissions and authorises that separate activity. Retrieval over an archive does not require training the base model on the archive. Indexing, adapter training and full model training are different processes and must not be blurred.

The architecture names every administrator class, authentication method and approval path. It can be designed with no standing ANULUM access: the client opens a maintenance window, authorises a named engineer, records the session and closes access afterwards. Break-glass access, if any, is separately controlled and tested.

A credible answer names time to first token, generation rate, end-to-end answer latency, input length, output length and concurrency. Public values are planning evidence only. The proof node measures representative client questions on the candidate production stack and reports the distribution, not only the fastest run.

That depends on model, quantisation, context, output length, batching, retrieval and the service-level target. We load-test scenarios rather than multiply a single-user tokens-per-second number. Capacity planning also reserves memory and thermal headroom for degraded conditions.

Sometimes. We check GPU support, memory, PCIe topology, power, cooling, storage endurance, warranty and serving-engine compatibility. The internal HP ML350 laboratory platform is useful for reproducible engineering, but it is not represented as current production hardware or as a customer reference.

The design assigns a recovery path: degraded service or spare capacity, encrypted backups, configuration capture, index reconstruction and tested restore. Recovery time and recovery point targets are agreed according to business impact. A backup is not accepted merely because a job reported success; restore evidence matters.

Potentially for dense, steady deployments. Useful heat depends on temperature level, load profile, distance, building demand and local engineering. ANULUM develops the IT-side heat and telemetry assumptions; licensed HVAC and electrical partners validate and execute building works after a site survey.

A fixed-scope decision pack: current-state and custody map, use-case boundary, threat and dependency observations, candidate deployment class, indicative bill of materials and operating cost, proof-node proposal, principal risks and an explicit stop/revise/proceed recommendation.

No. They are dated, non-binding planning ranges with stated inclusions and exclusions. A quotation follows discovery of workload, location, warranty, integration, support and tax conditions. Hardware prices and availability can move quickly, so validity periods are explicit. See the current ranges.

The intended default is client ownership of client data and client-procured hardware. Software licences, third-party components, ANULUM pre-existing tools and project-specific deliverables have different rights, which the contract itemises. Custody should never depend on an ambiguous ownership assumption.

Support can cover health review, backup checks, security and dependency updates, capacity monitoring, incident response, controlled model changes and periodic evaluation. Exact hours, response targets, access model, exclusions and client responsibilities are defined for the accepted baseline.

That is a design requirement. The exit package can include data and index exports, model identifiers and licences, configuration, dependency inventory, runbooks, backup/restore procedure, risk register and knowledge transfer. Any component that cannot be transferred is identified before commitment.