Create and update Priorities, Issues, Processes, and Metrics by talking to Olga: she writes nothing until you confirm.
Phase 1
This is part of what RunOlga delivers in Phase 1.
You populate RunOlga by talking to Olga instead of filling out forms. You describe what you want to capture; she gathers the fields a record needs, reads the result back, and saves it only once you confirm.
Olga turns a record into a short conversation. The shape of every exchange is the same, whatever you are capturing:
She asks for the required fields, one or two at a time. Rather than presenting a form, Olga walks the required schema fields conversationally, keeping each turn small enough to answer in a sentence.
She clarifies when something is vague. If an answer is too thin to store as a clean record, she asks a clarifying question — up to three per interaction — and then moves on with what you have given her.
She covers the optional fields, and lets you skip them. Optional fields are offered, not required. You can fill them in or pass, and the record still saves.
She reads the structured record back. Once she has everything required, Olga repeats the assembled record to you so you can see exactly what will be stored.
She waits for your explicit confirmation before writing anything.
Olga writes nothing until you confirm
No record is created or updated until you explicitly confirm it in the conversation. Olga proposes the structured record and stops; the write happens only on your say-so. This is enforced by RunOlga, not left to Olga's judgment. See grounding and confirmation.
The clarifying-question limit matters: Olga asks enough to capture a usable record, not endlessly. Three questions is the ceiling for a single interaction, so the conversation stays short and you stay in control of the pace.
Tasks are also created by talking to Olga, but through a distinct flow: when you create a Priority, Olga proposes a task breakdown you iterate on and approve. That is priority-to-task decomposition, the most significant Phase 1 capability, rather than the field-by-field entry described here.
The exchange below is illustrative — it shows the shape of the conversation, not a fixed script. Olga is logging an Issue, so she gathers what an Issue needs: a description, a status, and a severity.
You: Log an issue with caregiver retention in Oakland.
Olga: Got it. How severe is this right now — and is there a specific cause I should capture, or just the trend?
You: Pretty severe. Three caregivers left the Oakland team this month.
Olga: Here's the issue I'll log:
Description: Caregiver retention in Oakland — three caregivers left the team this month.Status: openSeverity: high
Want me to save it, or change anything first?
You: Save it.
Olga: Logged.
Olga asked one clarifying question to turn "an issue with caregiver retention" into a record with a description and a severity, read the structured result back, and wrote nothing until you said save.
Conversational data entry is how Olga captures what you decide to record. She gathers the fields, keeps the record clean, and confirms before saving.
She does not decide what belongs in a record or recommend what you should enter. She will not tell you an Issue is more severe than you said, suggest a Priority you have not raised, or judge whether what you are capturing is the right thing to capture. Olga prepares, proposes the structured record, and captures your confirmation; the content and the decision to save it are yours.