outturn 0.1.0__tar.gz

outturn-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Wisdom Omons
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

outturn-0.1.0/PKG-INFO

@@ -0,0 +1,240 @@
+Metadata-Version: 2.4
+Name: outturn
+Version: 0.1.0
+Summary: Did the agent produce the right outcome? As a number.
+Author: Wisdom Omons
+License-Expression: MIT
+Project-URL: Homepage, https://github.com/OsasDTEch/outturn
+Project-URL: Source, https://github.com/OsasDTEch/outturn
+Keywords: voice-agents,llm,evaluation,testing,livekit,agents
+Classifier: Development Status :: 3 - Alpha
+Classifier: Intended Audience :: Developers
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: Software Development :: Testing
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: PyYAML>=6.0
+Provides-Extra: dev
+Requires-Dist: pytest>=7.4; extra == "dev"
+Provides-Extra: livekit
+Requires-Dist: livekit-agents==1.8.2; extra == "livekit"
+Dynamic: license-file
+
+# outturn
+
+**Did the agent produce the right outcome? As a number.**
+
+A conversation does not end in words. It ends in an order, a booking, a routed ticket, a qualified lead. That is structured data, and structured data can be compared exactly. So whether your agent got it right does not have to be something you learn from a refund. It can be a percentage that runs on every commit.
+
+```
+  100%  simple_booking                     8/8
+   50%  service_switch_duration            4/8  FLAKY
+        4x wrong_field: duration_minutes (expected 90, got 60)
+  100%  never_confirmed                    8/8
+
+outcome accuracy: 83.3%  (20/24 runs)
+flaky scenarios (1): service_switch_duration
+a scenario that passes sometimes is a bug that ships sometimes.
+```
+
+---
+
+## Why this exists
+
+Most voice agent testing is a person calling the number and listening. That finds the bug in front of you and none of the others, it cannot run in CI, and it produces an opinion instead of a number.
+
+The alternatives are not much better. Asserting on the transcript is asserting on phrasing, which changes every time you touch the prompt. Using a model to grade the conversation means one nondeterministic system judging another.
+
+The outcome is the way out. It is the thing the customer actually receives, it is already structured, and it can be compared exactly.
+
+## Three design decisions
+
+**Numbers are exact, words are fuzzy.** A quantity of 3 is not close to 2, and a 90 minute appointment is not close to a 60 minute one. But "deep tissue massage" and "Deep Tissue Massage (60min)" are the same service. So every number is compared exactly and every word by normalized similarity.
+
+**Every scenario runs N times and reports a pass rate.** Agents are nondeterministic. One green run is not evidence. A bug that appears one run in five is invisible to a boolean test and obvious in a percentage, so outturn reports rates and flags anything that passed sometimes and failed sometimes as FLAKY. Intermittent is worse than broken, because intermittent hides.
+
+**An outcome is repeated things plus scalars.** That is all. An order is entries plus a total. A booking is no entries at all, just fields. A triage is fields. One model, no special cases per domain, which is why the same engine handles an ordering agent and a scheduling agent without a line of new code.
+
+## Install
+
+```bash
+pip install outturn
+```
+
+Or from source, if you want the demo scenarios to play with:
+
+```bash
+git clone https://github.com/OsasDTEch/outturn
+cd outturn
+pip install -e ".[dev]"
+```
+
+## Run it right now
+
+Two deliberately imperfect demo agents ship with the repo, so you can see real output before writing any integration.
+
+```bash
+outturn scenarios/order   --adapter demo-order   --runs 8 --seed 42
+outturn scenarios/booking --adapter demo-booking --runs 8 --seed 42
+```
+
+Each fails on purpose, because an eval you cannot fail is not an eval.
+
+The ordering agent drops a modifier at random under load, which is what FLAKY looks like, and its scope guard is tuned too tight so "do you sell garlic bread" is treated as an off topic question rather than a customer trying to order. That second one is not a strawman, it is behaviour observed on a shipped restaurant agent.
+
+The booking agent forgets to carry the duration across when the customer switches service mid call. A 90 minute massage in a 60 minute slot double books the therapist, and nobody finds out until the day.
+
+## Writing a scenario
+
+Turns in, expected outcome out.
+
+**An order**, which has line items:
+
+```yaml
+id: modifier_stacking
+description: >
+  Two modifiers on one item, added in a separate turn from the item itself.
+tags: [order, modifiers]
+
+turns:
+  - "Hi, can I get two large pepperoni pizzas"
+  - "Actually make those thin crust"
+  - "And extra cheese on them please"
+
+expect:
+  entries:
+    - name: pepperoni pizza
+      quantity: 2
+      unit_price: 12.00
+      tags: [thin crust, extra cheese]
+  total: 24.00
+```
+
+**A booking**, which has none:
+
+```yaml
+id: service_switch_duration
+turns:
+  - "Can I book a deep tissue massage for Friday"
+  - "Actually make it a sports massage instead"
+  - "4:00 pm, and yes please book it"
+
+expect:
+  service: sports massage
+  day: friday
+  time: "16:00"
+  duration_minutes: 90
+  confirmed: true
+```
+
+Same engine. Anything numeric under an entry becomes an exact comparison. Anything at the top level is a field: numbers and booleans exact, strings fuzzy.
+
+You can also assert on a reply, though use it sparingly since phrasing is the brittle part:
+
+```yaml
+turns:
+  - user: "Do you sell garlic bread?"
+    expect_reply_contains: ["garlic bread"]
+```
+
+## Connecting your own agent
+
+Implement three methods.
+
+```python
+from outturn.models import Outcome, Entry
+
+class MyAgent:
+    name = "my-agent"
+
+    def reset(self) -> None:
+        """Fresh conversation. Called before every run."""
+        self.session = start_session()
+
+    def send(self, text: str) -> str:
+        """One caller turn in, the agent's reply out."""
+        return self.session.turn(text)
+
+    def outcome(self) -> Outcome:
+        """The structured result, right now."""
+        return Outcome(
+            entries=tuple(
+                Entry(name=l.name,
+                      numbers={"quantity": l.qty, "unit_price": l.price},
+                      tags=tuple(l.modifiers))
+                for l in self.session.order.lines
+            ),
+            fields={"total": self.session.order.total},
+        )
+```
+
+Then point outturn at it. **Your agent lives in your repo, not in this one.**
+
+```bash
+outturn scenarios/ --adapter myproject.agents:MyAgent --runs 10
+```
+
+Anything importable works. If the object is missing one of the three methods,
+outturn says so before the run starts rather than failing with an
+AttributeError halfway through.
+
+If your agent cannot hand back a structured outcome, outturn cannot help you, and that is itself the finding. State that lives only in the model's context is not inspectable, and what is not inspectable is not testable. Move the outcome into code and the tool works.
+
+## LiveKit
+
+There is a driver at `outturn/adapters/livekit.py`. It takes a session factory and one callable that reads your state and returns an Outcome, because the outcome does not live in LiveKit, it lives in whatever your own function tools wrote it to.
+
+**Verified against livekit-agents 1.8.2.** Tested with the ollama.com cloud API (model `gemma4:31b`, OpenAI-compatible endpoint). Confirmed:
+
+- A session starts with no room and no audio.
+- State written by function tools persists across multiple `session.run()` calls on the same session, so multi-turn scenarios work as written.
+- The assistant reply is a `ChatMessageEvent` in `result.events` with `item.content[0]` as the text.
+
+Pin your own install to `livekit-agents==1.8.2` until you have tested against a newer version. This API is young and the `RunResult` shape has changed between releases.
+
+## In CI
+
+```bash
+outturn scenarios/booking --adapter demo-booking --runs 10 --threshold 0.95
+```
+
+Exits non zero if overall accuracy falls below the threshold. Every bug you fix becomes a scenario, so it can never come back silently. `--json` gives machine readable output for tracking accuracy over time.
+
+## The scenarios worth writing
+
+The ones that break agents, roughly in order of how often they do:
+
+- **Corrections mid call.** The customer changes their mind after the agent has already recorded something. This is where most outcomes go wrong, and the failure is usually a field that did not get updated alongside the one that did.
+- **Reference without naming.** "Make it three" with no item named.
+- **Cancellation.** Added, then removed. Do the derived values follow?
+- **Confirmation.** Did the agent act on intent rather than on an actual yes? Booking a customer who was still thinking is a real and expensive failure.
+- **Name collisions.** Two items or two services that sound alike over a phone line.
+- **Illegal combinations.** Extra cheese on a coke. Should be rejected by schema, not accepted politely and discovered later.
+- **Out of scope questions that are really orders.** "Do you sell X" is a customer trying to buy X.
+
+## What this does not test
+
+outturn drives your agent through text. That is fast enough to run in CI on every commit, and it isolates the reasoning and outcome layer from the audio layer.
+
+It does not test speech to text, endpointing or turn taking, and those are real sources of failure, particularly on telephony where audio is narrowband and degrades worst on exactly what matters here: names, numbers and proper nouns.
+
+**So this measures whether your agent understands correctly, not whether it hears correctly.** Both matter. For the timing half of the picture, see [voice-latency-profiler](https://github.com/OsasDTEch/voice-latency-profiler).
+
+## Status
+
+v0.1. The core works and is tested, 31 tests. Roadmap, roughly in order:
+
+- [x] LiveKit driver verified against livekit-agents 1.8.2 (ollama.com cloud, `gemma4:31b`)
+- [ ] Path assertions: which tools were called, with which arguments
+- [ ] Pipecat driver
+- [ ] Audio mode, TTS in and STT out, for end to end runs
+- [ ] Accuracy tracked over time, so regressions show as a trend
+
+`PRD.md` and `TRD.md` in this repo cover the reasoning and the internals.
+
+This project supersedes [voice-agent-evals](https://github.com/OsasDTEch/voice-agent-evals), which asserted on carts only. An order is one kind of outcome among many, and the narrower version was useful to about a tenth of the agents worth testing.
+
+## Licence
+
+MIT. Built by [Wisdom Omons](https://linkedin.com/in/omons-wisdom).

outturn-0.1.0/README.md

@@ -0,0 +1,217 @@
+# outturn
+
+**Did the agent produce the right outcome? As a number.**
+
+A conversation does not end in words. It ends in an order, a booking, a routed ticket, a qualified lead. That is structured data, and structured data can be compared exactly. So whether your agent got it right does not have to be something you learn from a refund. It can be a percentage that runs on every commit.
+
+```
+  100%  simple_booking                     8/8
+   50%  service_switch_duration            4/8  FLAKY
+        4x wrong_field: duration_minutes (expected 90, got 60)
+  100%  never_confirmed                    8/8
+
+outcome accuracy: 83.3%  (20/24 runs)
+flaky scenarios (1): service_switch_duration
+a scenario that passes sometimes is a bug that ships sometimes.
+```
+
+---
+
+## Why this exists
+
+Most voice agent testing is a person calling the number and listening. That finds the bug in front of you and none of the others, it cannot run in CI, and it produces an opinion instead of a number.
+
+The alternatives are not much better. Asserting on the transcript is asserting on phrasing, which changes every time you touch the prompt. Using a model to grade the conversation means one nondeterministic system judging another.
+
+The outcome is the way out. It is the thing the customer actually receives, it is already structured, and it can be compared exactly.
+
+## Three design decisions
+
+**Numbers are exact, words are fuzzy.** A quantity of 3 is not close to 2, and a 90 minute appointment is not close to a 60 minute one. But "deep tissue massage" and "Deep Tissue Massage (60min)" are the same service. So every number is compared exactly and every word by normalized similarity.
+
+**Every scenario runs N times and reports a pass rate.** Agents are nondeterministic. One green run is not evidence. A bug that appears one run in five is invisible to a boolean test and obvious in a percentage, so outturn reports rates and flags anything that passed sometimes and failed sometimes as FLAKY. Intermittent is worse than broken, because intermittent hides.
+
+**An outcome is repeated things plus scalars.** That is all. An order is entries plus a total. A booking is no entries at all, just fields. A triage is fields. One model, no special cases per domain, which is why the same engine handles an ordering agent and a scheduling agent without a line of new code.
+
+## Install
+
+```bash
+pip install outturn
+```
+
+Or from source, if you want the demo scenarios to play with:
+
+```bash
+git clone https://github.com/OsasDTEch/outturn
+cd outturn
+pip install -e ".[dev]"
+```
+
+## Run it right now
+
+Two deliberately imperfect demo agents ship with the repo, so you can see real output before writing any integration.
+
+```bash
+outturn scenarios/order   --adapter demo-order   --runs 8 --seed 42
+outturn scenarios/booking --adapter demo-booking --runs 8 --seed 42
+```
+
+Each fails on purpose, because an eval you cannot fail is not an eval.
+
+The ordering agent drops a modifier at random under load, which is what FLAKY looks like, and its scope guard is tuned too tight so "do you sell garlic bread" is treated as an off topic question rather than a customer trying to order. That second one is not a strawman, it is behaviour observed on a shipped restaurant agent.
+
+The booking agent forgets to carry the duration across when the customer switches service mid call. A 90 minute massage in a 60 minute slot double books the therapist, and nobody finds out until the day.
+
+## Writing a scenario
+
+Turns in, expected outcome out.
+
+**An order**, which has line items:
+
+```yaml
+id: modifier_stacking
+description: >
+  Two modifiers on one item, added in a separate turn from the item itself.
+tags: [order, modifiers]
+
+turns:
+  - "Hi, can I get two large pepperoni pizzas"
+  - "Actually make those thin crust"
+  - "And extra cheese on them please"
+
+expect:
+  entries:
+    - name: pepperoni pizza
+      quantity: 2
+      unit_price: 12.00
+      tags: [thin crust, extra cheese]
+  total: 24.00
+```
+
+**A booking**, which has none:
+
+```yaml
+id: service_switch_duration
+turns:
+  - "Can I book a deep tissue massage for Friday"
+  - "Actually make it a sports massage instead"
+  - "4:00 pm, and yes please book it"
+
+expect:
+  service: sports massage
+  day: friday
+  time: "16:00"
+  duration_minutes: 90
+  confirmed: true
+```
+
+Same engine. Anything numeric under an entry becomes an exact comparison. Anything at the top level is a field: numbers and booleans exact, strings fuzzy.
+
+You can also assert on a reply, though use it sparingly since phrasing is the brittle part:
+
+```yaml
+turns:
+  - user: "Do you sell garlic bread?"
+    expect_reply_contains: ["garlic bread"]
+```
+
+## Connecting your own agent
+
+Implement three methods.
+
+```python
+from outturn.models import Outcome, Entry
+
+class MyAgent:
+    name = "my-agent"
+
+    def reset(self) -> None:
+        """Fresh conversation. Called before every run."""
+        self.session = start_session()
+
+    def send(self, text: str) -> str:
+        """One caller turn in, the agent's reply out."""
+        return self.session.turn(text)
+
+    def outcome(self) -> Outcome:
+        """The structured result, right now."""
+        return Outcome(
+            entries=tuple(
+                Entry(name=l.name,
+                      numbers={"quantity": l.qty, "unit_price": l.price},
+                      tags=tuple(l.modifiers))
+                for l in self.session.order.lines
+            ),
+            fields={"total": self.session.order.total},
+        )
+```
+
+Then point outturn at it. **Your agent lives in your repo, not in this one.**
+
+```bash
+outturn scenarios/ --adapter myproject.agents:MyAgent --runs 10
+```
+
+Anything importable works. If the object is missing one of the three methods,
+outturn says so before the run starts rather than failing with an
+AttributeError halfway through.
+
+If your agent cannot hand back a structured outcome, outturn cannot help you, and that is itself the finding. State that lives only in the model's context is not inspectable, and what is not inspectable is not testable. Move the outcome into code and the tool works.
+
+## LiveKit
+
+There is a driver at `outturn/adapters/livekit.py`. It takes a session factory and one callable that reads your state and returns an Outcome, because the outcome does not live in LiveKit, it lives in whatever your own function tools wrote it to.
+
+**Verified against livekit-agents 1.8.2.** Tested with the ollama.com cloud API (model `gemma4:31b`, OpenAI-compatible endpoint). Confirmed:
+
+- A session starts with no room and no audio.
+- State written by function tools persists across multiple `session.run()` calls on the same session, so multi-turn scenarios work as written.
+- The assistant reply is a `ChatMessageEvent` in `result.events` with `item.content[0]` as the text.
+
+Pin your own install to `livekit-agents==1.8.2` until you have tested against a newer version. This API is young and the `RunResult` shape has changed between releases.
+
+## In CI
+
+```bash
+outturn scenarios/booking --adapter demo-booking --runs 10 --threshold 0.95
+```
+
+Exits non zero if overall accuracy falls below the threshold. Every bug you fix becomes a scenario, so it can never come back silently. `--json` gives machine readable output for tracking accuracy over time.
+
+## The scenarios worth writing
+
+The ones that break agents, roughly in order of how often they do:
+
+- **Corrections mid call.** The customer changes their mind after the agent has already recorded something. This is where most outcomes go wrong, and the failure is usually a field that did not get updated alongside the one that did.
+- **Reference without naming.** "Make it three" with no item named.
+- **Cancellation.** Added, then removed. Do the derived values follow?
+- **Confirmation.** Did the agent act on intent rather than on an actual yes? Booking a customer who was still thinking is a real and expensive failure.
+- **Name collisions.** Two items or two services that sound alike over a phone line.
+- **Illegal combinations.** Extra cheese on a coke. Should be rejected by schema, not accepted politely and discovered later.
+- **Out of scope questions that are really orders.** "Do you sell X" is a customer trying to buy X.
+
+## What this does not test
+
+outturn drives your agent through text. That is fast enough to run in CI on every commit, and it isolates the reasoning and outcome layer from the audio layer.
+
+It does not test speech to text, endpointing or turn taking, and those are real sources of failure, particularly on telephony where audio is narrowband and degrades worst on exactly what matters here: names, numbers and proper nouns.
+
+**So this measures whether your agent understands correctly, not whether it hears correctly.** Both matter. For the timing half of the picture, see [voice-latency-profiler](https://github.com/OsasDTEch/voice-latency-profiler).
+
+## Status
+
+v0.1. The core works and is tested, 31 tests. Roadmap, roughly in order:
+
+- [x] LiveKit driver verified against livekit-agents 1.8.2 (ollama.com cloud, `gemma4:31b`)
+- [ ] Path assertions: which tools were called, with which arguments
+- [ ] Pipecat driver
+- [ ] Audio mode, TTS in and STT out, for end to end runs
+- [ ] Accuracy tracked over time, so regressions show as a trend
+
+`PRD.md` and `TRD.md` in this repo cover the reasoning and the internals.
+
+This project supersedes [voice-agent-evals](https://github.com/OsasDTEch/voice-agent-evals), which asserted on carts only. An order is one kind of outcome among many, and the narrower version was useful to about a tenth of the agents worth testing.
+
+## Licence
+
+MIT. Built by [Wisdom Omons](https://linkedin.com/in/omons-wisdom).

outturn-0.1.0/outturn/__init__.py

@@ -0,0 +1,5 @@
+"""outturn: did the agent produce the right outcome? As a number."""
+from .models import Discrepancy, Entry, Kind, Outcome, Scenario, Turn
+
+__version__ = "0.1.0"
+__all__ = ["Outcome", "Entry", "Scenario", "Turn", "Discrepancy", "Kind", "__version__"]

outturn-0.1.0/outturn/__main__.py

@@ -0,0 +1,5 @@
+import sys
+
+from .cli import main
+
+sys.exit(main())

outturn-0.1.0/outturn/adapters/__init__.py

@@ -0,0 +1,68 @@
+"""Adapter lookup.
+
+Two ways to name an adapter:
+
+    --adapter demo-booking
+        one of the demo agents that ship with outturn
+
+    --adapter myproject.agents:MyAgent
+        anything importable. Your agent lives in your repo, not in this one.
+
+The second form is the point. You should never have to edit a file inside
+this package to test your own agent.
+"""
+from __future__ import annotations
+
+import importlib
+
+from .base import Agent
+from .demo_booking import DemoBookingAgent
+from .demo_order import DemoOrderAgent
+
+BUILTIN: dict[str, type] = {
+    DemoOrderAgent.name: DemoOrderAgent,
+    DemoBookingAgent.name: DemoBookingAgent,
+}
+
+
+class AdapterError(ValueError):
+    pass
+
+
+def _load_path(spec: str) -> type:
+    """Import 'package.module:ClassName' or 'package.module.ClassName'."""
+    if ":" in spec:
+        module_name, _, attr = spec.partition(":")
+    else:
+        module_name, _, attr = spec.rpartition(".")
+    if not module_name or not attr:
+        raise AdapterError(
+            f"{spec!r} is not a known adapter and does not look like an import path. "
+            f"Use 'module:ClassName', or one of: {', '.join(sorted(BUILTIN))}"
+        )
+    try:
+        module = importlib.import_module(module_name)
+    except ImportError as e:
+        raise AdapterError(f"could not import {module_name!r}: {e}") from e
+    try:
+        return getattr(module, attr)
+    except AttributeError as e:
+        raise AdapterError(f"{module_name!r} has no attribute {attr!r}") from e
+
+
+def get(spec: str) -> Agent:
+    """Resolve an adapter name or import path into an instance."""
+    cls = BUILTIN.get(spec) or _load_path(spec)
+
+    agent = cls() if isinstance(cls, type) else cls   # a factory function is fine too
+
+    for method in ("reset", "send", "outcome"):
+        if not callable(getattr(agent, method, None)):
+            raise AdapterError(
+                f"{spec!r} is missing {method}(). An adapter needs reset(), send(text) "
+                f"and outcome()."
+            )
+    return agent
+
+
+__all__ = ["Agent", "AdapterError", "BUILTIN", "get", "DemoOrderAgent", "DemoBookingAgent"]

outturn-0.1.0/outturn/adapters/base.py

@@ -0,0 +1,25 @@
+"""The adapter contract. Three methods.
+
+    reset()      start a fresh conversation
+    send(text)   one caller turn in, the agent's reply out
+    outcome()    the structured result, right now
+
+If your agent cannot hand back a structured outcome, outturn cannot help you,
+and that is itself the finding. State that lives only inside the model's
+context is not inspectable, and what is not inspectable is not testable.
+Move the outcome into code and the tool works.
+"""
+from __future__ import annotations
+
+from typing import Protocol, runtime_checkable
+
+from ..models import Outcome
+
+
+@runtime_checkable
+class Agent(Protocol):
+    name: str
+
+    def reset(self) -> None: ...
+    def send(self, text: str) -> str: ...
+    def outcome(self) -> Outcome: ...

outturn-0.1.0/outturn/adapters/demo_booking.py

@@ -0,0 +1,75 @@
+"""A deliberately imperfect appointment booking agent.
+
+This one exists to prove the point of the whole rewrite: a booking has no
+line items at all. It is a handful of scalar fields. The same engine handles
+it without a single special case.
+
+Its planted flaw is the one real booking agents actually have: it hears the
+service and the day, and forgets to carry the duration across when the
+customer changes their mind mid call.
+"""
+from __future__ import annotations
+
+import random
+import re
+
+from ..models import Outcome
+
+SERVICES = {
+    "deep tissue massage": 60,
+    "swedish massage": 60,
+    "sports massage": 90,
+    "facial": 45,
+}
+_DAYS = ("monday", "tuesday", "wednesday", "thursday", "friday", "saturday", "sunday")
+
+
+class DemoBookingAgent:
+    name = "demo-booking"
+
+    def __init__(self, forget_duration_rate: float = 0.4) -> None:
+        self.forget_duration_rate = forget_duration_rate
+        self._state: dict = {}
+
+    def reset(self) -> None:
+        self._state = {"confirmed": False}
+
+    def send(self, text: str) -> str:
+        t = text.lower().strip()
+        changed = False
+
+        for service, minutes in SERVICES.items():
+            if service in t or service.split()[0] in t:
+                switching = "service" in self._state and self._state["service"] != service
+                self._state["service"] = service
+                # the planted flaw: on a switch it sometimes keeps the old duration
+                if not switching or random.random() > self.forget_duration_rate:
+                    self._state["duration_minutes"] = minutes
+                changed = True
+                break
+
+        m = re.search(r"\b(\d{1,2})[:.](\d{2})\s*(am|pm)?\b", t)
+        if m:
+            hour, minute, ampm = int(m.group(1)), m.group(2), m.group(3)
+            if ampm == "pm" and hour < 12:
+                hour += 12
+            self._state["time"] = f"{hour:02d}:{minute}"
+            changed = True
+
+        for day in _DAYS:
+            if day in t:
+                self._state["day"] = day
+                changed = True
+                break
+
+        if any(w in t for w in ("yes", "confirm", "book it", "that works", "go ahead")):
+            self._state["confirmed"] = True
+            return "Booked. You will get a confirmation by text."
+
+        if changed:
+            bits = [str(self._state.get(k)) for k in ("service", "day", "time") if self._state.get(k)]
+            return "Got it, " + ", ".join(bits) + ". Shall I book that?"
+        return "Sorry, I did not catch that."
+
+    def outcome(self) -> Outcome:
+        return Outcome(entries=(), fields=dict(self._state))