Services / Readiness audit
Find the production blockers before implementation expands.
A fixed-scope technical review for teams that need an evidence-backed decision on what must change, what can wait and what production-ready means for their system.
Entry conditions
Use the audit to establish technical truth, not to imply a pass.
Good fit
A prototype or partial service exists, stakeholders can provide access and evidence, and the team needs a prioritized decision before committing more implementation effort.
Wrong fit
There is no system or representative workflow to inspect, required access cannot be provided, or the buyer expects certification, penetration testing or a guaranteed production-readiness verdict.
Fixed-scope start
Required inputs
The review takes 5–10 working days after required access and inputs are ready. Calendar time starts only when the review can reproduce and inspect the relevant system boundaries.
- Current architecture, repositories or representative source, and a technical walkthrough with the people who operate the system.
- Representative inputs, evaluation material, known incidents or failure examples, and any current quality or release criteria.
- Read-only access to relevant environments, telemetry and provider configuration where those facts affect the review.
- Product constraints, expected demand, data rules, business impact and the stakeholders who can resolve open ownership decisions.
Review boundaries
Inspect the full service around the model.
- Data
- Source quality, permissions, retention, deletion and provenance.
- Retrieval
- Index lifecycle, filtering, ranking, citations and stale-source behavior.
- Model
- Task fit, constraints, provider coupling, fallback and unsupported output.
- Evaluation
- Representative data, thresholds, regression coverage and release decisions.
- Integration
- Identity, state, interfaces, idempotency and user-visible failure.
- Security
- Access, secrets, sensitive data flow, logging and boundary validation.
- Reliability
- Timeouts, dependency failure, degraded modes, recovery and rollback.
- Operations
- Telemetry, alerts, runbooks, incident paths and named responsibility.
- Cost
- Inference, retrieval, storage and operational budgets under expected demand.
- Ownership
- Decision rights, source ownership, handover gaps and change control.
Handover package
What you receive
- Output 01
Current-state architecture
A concise map of components, dependencies, data flow and operating boundaries, including important unknowns.
- Output 02
Evidence-backed risk register
Observed blockers and failure modes with the evidence, consequence and affected owner recorded.
- Output 03
Prioritized remediation plan
A sequenced repair path that distinguishes prerequisites, risk reduction and work that can safely wait.
- Output 04
Production-readiness criteria
Measurable gates for quality, data, reliability, security, operations, cost and ownership.
- Output 05
Decision session
A working review of findings, trade-offs and the recommended next decision with the responsible technical stakeholders.
Scope boundary
What the audit does not include
The fixed scope does not include production implementation, a security penetration test, compliance certification, large-scale data cleanup, model training or ongoing operations. A critical risk can trigger an immediate discussion, but it does not silently expand the engagement.
Price is confirmed after the fit check because system access, evidence quality and review boundaries materially affect the work. The fit check establishes those facts without creating artificial urgency.
Separate engagement
Implementation after the audit
RSI Tech can implement the remediation plan or work alongside the existing team when there is mutual fit. That work is scoped separately, with its own responsibilities, acceptance evidence and release boundary. The audit remains useful if another team performs the implementation.
Decision notes
Questions technical buyers ask
- Will the audit produce a pass or fail?
- It produces evidence, risks and readiness criteria. A system may be ready for a constrained release while still blocked from a broader use case; the decision stays tied to the stated operating boundary.
- Can the review happen without production write access?
- Usually. Read-only evidence is preferred. If a claim cannot be verified without a risky or unavailable action, the limitation is recorded rather than inferred.
- What happens when required evidence is missing?
- The gap becomes a finding with its consequence and next safe action. Missing evidence can itself block a production decision; it is not converted into a confident score.