Client
Owns purpose, lawful basis, data classification, access decisions, professional reliance, budget, final acceptance and the hardware or hosting contract.
Delivery lifecycle
Every irreversible decision has a gate.
A private AI programme should be easy to stop while uncertainty is high and hard to change silently once people rely on it. Our lifecycle names the evidence, owner and decision at every stage.
10explicit gates
1named decision owner per gate
0hardware purchases before sizing evidence
1exit plan from the start
The ten-gate delivery path
Durations overlap only when the client accepts the dependency. Passing a gate authorises the next bounded activity; it does not erase an earlier constraint.
- 01
Confidential discovery
Input: business question, data classes, users and current controls. Output: scope boundary and information-request list.
Gate: Is there a valuable problem that can be discussed without transferring sensitive material?
- 02
Architecture review
Input: system context, sample metadata and risk obligations. Output: custody options, threat model, indicative class, cost range and no-go findings.
Gate: Stop, revise, or authorise a proof node.
- 03
Data and evaluation design
Input: approved representative material and permission model. Output: ingestion rules, held-out questions, refusal cases, leakage tests and acceptance thresholds.
Gate: Can success and unsafe failure be measured before model selection?
- 04
Proof node
Input: sanitised or tightly controlled corpus slice. Output: cited answers, model comparison, latency, throughput, memory, power and failure evidence.
Gate: Stop, repeat with changed assumptions, or authorise production design.
- 05
Production design and procurement
Input: measured proof workload and growth envelope. Output: bill of materials, warranty path, network and identity design, facility needs and implementation plan.
Gate: Named client authority approves spend and residual risk.
- 06
Build and hardening
Input: approved design and client-owned credentials. Output: configured system, access boundaries, signed baseline, backup path, monitoring and administrator runbooks.
Gate: Security configuration and physical custody match the approved design.
- 07
Acceptance and reliance
Input: production stack and held-out evaluation pack. Output: test report, known limitations, user training, incident route and signed acceptance record.
Gate: Client decides which workflows may rely on the system and which remain prohibited.
- 08
Managed operation
Input: accepted baseline and support agreement. Output: health evidence, backup checks, patch decisions, capacity records, incidents and service reports.
Gate: Operation stays inside support, security and performance thresholds.
- 09
Controlled change
Input: proposed model, index, policy, hardware or engine change. Output: comparison evidence, rollback point, updated records and authorised change.
Gate: No material change enters production without re-evaluation proportional to its risk.
- 10
Exit, transfer or renewal
Input: contract end, technology change or client decision. Output: configuration and data exports, deletion evidence where applicable, asset disposition and knowledge transfer.
Gate: The client can continue, migrate or retire without dependency on an undisclosed ANULUM system.
Responsibility is designed, not assumed
ANULUM
Designs and implements the agreed system, states evidence boundaries, records changes, trains named operators and supports the accepted baseline.
Hardware and facility partners
Provide warrantied equipment, electrical or HVAC work and specialist certifications under their own documented responsibilities.
Legal, compliance and clinical advisers
Interpret applicable obligations and professional rules. ANULUM supplies architecture facts and controls; it does not replace independent advice.
Change rule
A new model is a system change.
Changing model weights can alter quality, refusal, tool use, licence terms, memory demand and data paths. The same applies to a new parser, embedding model or retrieval policy. Version capture, held-out tests, rollback and client authorisation make the change visible.
Review the dated model catalogue → · See governance controls →
The exit package is specified at entry
- Client data and index-export formats, including documented limitations.
- Configuration, model identifiers, hashes, licences and dependency inventory.
- Administrator runbooks, backup/restore procedure and current risk register.
- Deletion or media-disposition evidence for systems leaving service.
- Named handover session and a list of open operational decisions.
No public page can replace a contract. Exact deliverables, acceptance thresholds, support hours and exit duties are written into the engagement.