Operating Tavrik day to day
For the team that will own this after it goes in. The honest summary: it is a small operational footprint, and most weeks there is nothing to do.
What an operator looks at
Section titled “What an operator looks at”The console is organised around the questions an operator actually arrives with, not around the tables underneath:
- Overview: is anything wrong right now.
- Traffic: every governed request: what was replaced, which model handled it, and the decision trail behind each row.
- Policy: the rules in force, in plain English, with what each one has blocked recently.
- Routing: where traffic is actually going.
- Audit: the evidentiary record, written as sentences rather than event codes, verifiable on demand.
- Costs: spend over time and where it goes.
Recurring work
Section titled “Recurring work”| Task | How often |
|---|---|
| Review denied requests and tune policy | Weekly at first, then monthly |
| Enrol and revoke clinician devices | As staff change |
| Rotate connector client certificates | Yearly, or per your policy |
| Verify an audit range | Quarterly, or whenever asked |
| Review operator accounts and roles | Quarterly |
Certificate expiry is not left to memory: the connectors emit a warning event as a client certificate approaches expiry, and it escalates as the date closes.
What tells you something is wrong
Section titled “What tells you something is wrong”Tavrik writes structured logs and audit events to the systems you already watch, rather than asking your team to sit in another console. The signals worth an alert are the connector failures, an integration engine that stops accepting messages, a FHIR endpoint that becomes unreachable, a dead-letter queue that starts growing, and an audit verification that returns anything other than verified.
Delivery is at-least-once with retry and backoff. A target that stays down parks its events rather than dropping them, and an operator replays them from the console when it returns.
Backups
Section titled “Backups”A daily timer dumps the database and the audit log, and fails loudly if the database is unreachable, a backup that silently does nothing is the failure mode worth designing against. Copying that directory off the host is your own schedule and your own retention policy.
Upgrades
Section titled “Upgrades”Binaries and console are replaced from one build, with the previous copies kept in place, so a rollback is a restart rather than a rebuild. Database migrations are an explicit separate step and the services refuse to start against a schema they do not recognise.
What you do not have to do
Section titled “What you do not have to do”There is no tuning of the redaction engine, no model to retrain, and no rule language to learn before the first day: the healthcare pack ships with the clinical recognisers already configured, and policy is authored as readable rules with the underlying form available if you want it.