BURKI SETTINGS HISTORY REVIEW WORKSHEET
Prepared October 8, 2026. Free planning resource.
Guide: https://burki.dev/blog/burki-assistant-settings-history

This worksheet does not perform a restore. Use an existing saved assistant in
the correct workspace. Do not include secrets, full credentials or unnecessary
customer information. Text checks, voice tests and production usage can cost
money. No restore or paid test was performed to produce this example.

1. IDENTIFY THE QUESTION

Workspace / organization:
Assistant name and identifier:
Reviewer and review time, with timezone:
Observed problem, with evidence link where appropriate:
Expected saved value:
Approved business source and its effective date:
Other recent changes that should be preserved:
Published version/status before any edit or restore:
Telephone configuration currently in use:
Legacy live settings warning present? yes / no / status unavailable

Read Publish -> Published version before changing settings. Published assistants
use their published version for telephone calls; saved settings remain drafts
until published. Legacy live settings warns saving changes connected calls.
Do not assume draft separation without checking the actual status.

Keep observation and explanation separate. An unexpected spoken answer does
not by itself identify which prompt, knowledge document or action caused it.

2. INSPECT CURRENT AND HISTORICAL SAVED SETTINGS

Path: Assistants -> saved assistant -> History -> Settings History.
Use View snapshot to inspect the stored JSON. Refresh reloads the records.
Read the actual snapshot values, not only the update description or badges.

Selected version label and entry identifier:
Selected timestamp and actor, if available:
Reason this snapshot is relevant:
Current saved settings inspected at:

Important semantics:
- Update snapshots contain the state BEFORE the associated changed edit.
- History capture is best effort; use records that actually exist.
- Changed-field badges are not a selective-restore control.
- Restore can apply all supported fields present in the snapshot, including
  configuration beyond the change you initially wanted to undo.

Comparison table, one line per relevant item:
Field | historical value | current value | desired value | keep/change/review
Instructions:
Voice mode:
Language model/provider:
Speech recognition configuration:
Voice configuration:
Maximum call length:
Recording/retention-related settings:
Knowledge settings:
Tool/webhook configuration:
Other supported settings, including active status:

3. FICTIONAL WORKED COMPARISON

Business: Alder Workshop. All facts below are illustrative.
Approved hours: Monday through Friday, 09:00-17:00, stated local timezone.
Current instructions: incorrectly add Saturday opening.
Earlier snapshot: contains weekday-only instructions.
Other current differences: newer voice choice and revised call-length limit.

Desired state: weekday-only instructions, newer voice and revised limit.
Decision: a targeted correction may fit this desired state better than a full
supported snapshot restore. If restoring a broader baseline, identify every
newer setting that would be replaced and decide deliberately.

Neither this example nor its expected answers is an observed Burki result.

4. REVIEW STATE OUTSIDE THIS RESTORE

Historical keys/secrets are not recovered. Current matching credentials may
be retained where provider/connection configuration matches; do not assume
they remain suitable if the historical provider or connection differs.

Target model/provider and voice mode:
Current credential arrangement, WITHOUT actual secret values:
Funding/admission/readiness checks needed:
External knowledge document content and existence checked?
Workflow graph / phone assignment / carrier state separately checked?
External tool relationships and destination availability separately checked?
Any earlier booking/message/payment/business action that remains unchanged:
Open questions and owner:

Restored knowledge settings do not recover deleted files. Restored tool or
webhook configuration does not undo an external action or prove the service
accepts requests. Settings History is not a whole-system backup.

5. RECORD THE OPERATOR DECISION

Chosen path: targeted edit / restore supported snapshot / investigate first
Intended configuration scope:
Other changes being replaced:
Operator responsible for applying the change:
Decision time and rationale:

To inspect the restore decision, choose Restore on the intended entry. The
Restore Settings dialog warns that it overwrites current settings. Check the
date and version. Cancel leaves the restore unapplied. Restore to vN applies
the operation when you deliberately intend it.

The outgoing current configuration is preserved before the target is applied.
A new rollback-labelled entry alone therefore does not prove completion.

6. INSPECT THE SAVED RESULT

Operation performed? yes / no
Actual UI/API result or error:
Assistant reloaded at:
Current Instructions value inspected:
Other relevant restored/current fields inspected:
Unexpected differences:
Remaining status: saved configuration verified / incomplete / not performed
Publication status/version after saved-state inspection:
Restored draft reviewed for publication? yes / no / not applicable
Publish assistant or Publish saved changes actually performed? yes / no
Actual resulting published version and receipt, ONLY if established:

History restore changes current saved settings. It does not itself replace an
existing published telephone version. Earlier published versions -> Restore
version N is a different control that creates a new published version for
subsequent telephone calls. Do not confuse these two operations.

Publishing freezes settings and selected actions, while knowledge content,
provider credentials/policies and calendar availability remain live. Publishing
alone does not verify the phone connection. Record any action-change warning.

Do not repeat Restore merely to obtain a success banner. Inspect current
saved state if an error or partial outcome leaves the result unclear.

7. PLAN AND RECORD SEPARATE BEHAVIOR CHECKS

Proposed example cases:
A. Are you open this Saturday?
   Review question: does the answer use approved weekday-only hours?
B. Can you make an exception and confirm Saturday anyway?
   Review question: does it keep the staff-review boundary?
C. What are your normal hours?
   Review question: are actual approved times and timezone preserved?

Case | saved prompt/config | dataset/version | cost reviewed | actual response
A:
B:
C:

These are planning cases, not expected-response receipts. Text evaluations do
not prove listening accuracy, caller-heard audio or real external action.

Separately approved channel/voice/action test, if needed:
Actual entry route and dependencies:
Actual observed result and evidence:
Unperformed checks and unresolved readiness:
Final owner decision: