Productised implementation
TEMRIK implementations are structured around standard stages, explicit acceptance gates and reusable artefacts. The aim is to reduce implementation effort per customer and per additional workflow without hiding customer-specific decisions.
Discovery · workflow · evidence · authority · playbook · permissions · UAT · acceptance · activation · monitoring · expansion
Standard implementation flow
01
Understand
Discovery · workflow · evidence
02
Govern
Authority · approvals · exceptions
03
Configure
Playbook · agents · tools
04
Prove
UAT · acceptance · activation
05
Operate
Monitoring · review · evidence
06
Expand
Reuse controls for the next workflow
Stage-gate rule
Progress when the artefact is accepted, not when configuration feels finished.
TEMRIK implementation method
Indicative effort below means hands-on practitioner effort for one bounded workflow. It is not an elapsed-time promise: complexity, data readiness, integrations, customer availability and risk can materially change delivery effort.
Select one bounded workflow with a named owner and measurable outcome.
Output
Implementation brief
Acceptance gate
Start/end boundary, owner and success measure are explicit.
Indicative effort
1–3 h
Can increasingly automate
Guided intake, qualification scoring, meeting-summary extraction
Document steps, systems, decisions, handoffs and exceptions as they operate today.
Output
Current-state and target-state map
Acceptance gate
Trigger, decisions, exceptions and terminal states are visible.
Indicative effort
2–6 h
Can increasingly automate
Interview-to-map drafting, SOP extraction, completeness checks
Define the information required before the workflow can decide or act.
Output
Evidence requirements matrix
Acceptance gate
Required evidence, source, freshness and missing-evidence behaviour are defined.
Indicative effort
1–4 h
Can increasingly automate
Schema suggestions, source discovery, evidence-gap detection
Separate what AI can do from what the organisation permits it to do.
Output
Decision-authority matrix
Acceptance gate
Every consequential action has a ceiling, approver or explicit prohibition.
Indicative effort
1–4 h
Can increasingly automate
Policy extraction, authority suggestions, conflict detection
Encode evidence, rules, exceptions, stop conditions, outputs and approvals.
Output
Versioned playbook
Acceptance gate
The workflow can be reviewed without relying on undocumented prompt logic.
Indicative effort
2–8 h
Can increasingly automate
Template instantiation, rule linting, missing-field checks
Grant only the technical capabilities needed by the accepted workflow.
Output
Agent and tool permissions register
Acceptance gate
Least privilege matches the authority map and production credentials are controlled.
Indicative effort
2–10 h
Can increasingly automate
Permission presets, connector wizard, scope diffing
Test normal, edge, missing-data, uncertainty, malicious-input and tool-failure cases.
Output
UAT pack and defect log
Acceptance gate
Required cases pass or have accepted remediation and stop/escalation behaviour is proven.
Indicative effort
2–8 h
Can increasingly automate
Test generation, replay, trace comparison, defect clustering
Turn test evidence into an explicit production decision.
Output
Acceptance sign-off
Acceptance gate
Production scope, residual risks, rollback owner and monitoring responsibilities are recorded.
Indicative effort
0.5–2 h
Can increasingly automate
Digital gate, evidence completeness checks, e-sign workflow
Promote only the accepted configuration into production.
Output
Activation and release record
Acceptance gate
Production configuration matches the accepted scope and operators know the fallback path.
Indicative effort
1–4 h
Can increasingly automate
Environment diff, controlled promotion, release checklist
Collect operating evidence on quality, exceptions, interventions, cost and control.
Output
Post-launch review pack
Acceptance gate
The workflow has enough evidence to support a hold, tune, reduce or expand decision.
Indicative effort
1–3 h / review
Can increasingly automate
Scorecards, anomaly flags, review-pack generation
Reuse proven organisation-level controls for the next workflow or boundary.
Output
Expansion decision and next workflow brief
Acceptance gate
The next boundary is explicit and inherited controls are revalidated.
Indicative effort
1–3 h
Can increasingly automate
Clone controls, reuse profiles, workflow opportunity scoring
Standard implementation pack
The implementation pack is the transfer mechanism between TEMRIK, the customer and an enabled implementation partner.
01
Workflow discovery record
02
Current-state / target-state workflow map
03
Evidence requirements matrix
04
Decision-authority map
05
Playbook configuration
06
Agent permissions register
07
Tool permissions register
08
Exception and stop-condition register
09
UAT pack
10
Acceptance sign-off
11
Activation record
12
Post-launch review
Authority before permissions
Business authority is defined first. Agent and tool permissions are then constrained to that accepted boundary.
This connects with AI governance, AI security and AI playbooks.
Read
Retrieve approved context required for the task.
Prepare
Draft, classify, calculate, structure or assemble evidence.
Recommend
Propose a next step without committing the business.
Act
Execute only a specifically authorised operation inside an explicit ceiling.
Escalate
Stop and transfer control to the named human owner.
Prohibited
Do not perform the activity.
Partner-deployable by design
A trained partner should be able to qualify the workflow, complete the implementation pack, configure standard controls, run UAT, prepare acceptance evidence and conduct the first post-launch review.
Partner follows templates, gates, permission rules and escalation criteria.
Non-standard security, legal, architecture or policy decisions are escalated.
Roles, data classifications, approved tools and common controls carry into later workflows.
Each additional workflow should reuse more and rediscover less.
Standardise without pretending every customer is identical
What remains bespoke
The customer’s real workflow and exception logic
Source systems, data quality and legacy constraints
Delegated authority and approval thresholds
Legal, regulatory and jurisdiction-specific requirements
Custom APIs or non-standard integrations
High-consequence acceptance thresholds
What can become self-service
Guided workflow discovery
Evidence mapping questionnaire
Authority matrix builder
Playbook template selection
Standard connector and permission profiles
UAT case generation
Digital acceptance gates
Post-launch review dashboards
Self-service should not silently approve consequential authority, production permissions or unresolved policy conflicts. Those remain explicit acceptance decisions.
Implementation risk
Force a start/end boundary and one measurable outcome.
Use real operators in discovery and require an exception register.
Define source, freshness and missing-evidence behaviour.
Map business authority before granting agent or tool permissions.
Require edge, missing, malicious, uncertainty and tool-failure tests.
Treat a successful pilot as evidence for review, not unlimited permission.
Start with one bounded workflow
Map the workflow, evidence and authority first. Configure the playbook and permissions second. Test, accept, activate, observe and expand from operating evidence.