Generate a Pre-Meeting Readout

Before you begin

Roles required: Consultant, account lead.

You need the customer_scope value for the account or project the meeting is for. This is typically a short string identifier such as acme-corp or project-atlas. If you are unsure of the value, check with your governance lead or platform administrator.

You need the meeting date in ISO format (YYYY-MM-DD). If the exact date is not yet set, use the expected date — you can re-generate the readout closer to the meeting to pick up any newly validated answers.

Assumed state: Approved answers exist in the registry for this customer scope. See Publish an Approved Answer to the Registry.

Steps

1. Request the pre-meeting readout

Send a POST request to /v1/readout/pre-meeting with the customer scope and meeting date:

curl -s -X POST http://localhost:8000/v1/readout/pre-meeting \
  -H "Content-Type: application/json" \
  -d '{
    "customer_scope": "acme-corp",
    "meeting_date": "2026-07-01",
    "include_disputed": false
  }'

Request fields:

Field	Description
`customer_scope`	The customer or project scope identifier
`meeting_date`	ISO date for the meeting (YYYY-MM-DD)
`include_disputed`	Set to `true` to include DISPUTED answers as warnings; default `false`

The response returns a readout record with a readout_id:

{
  "readout_id": "rdout_01j2k3l4m5n6p7q8r9x5",
  "customer_scope": "acme-corp",
  "meeting_date": "2026-07-01",
  "status": "assembled",
  "answer_count": 24,
  "open_issue_count": 3,
  "expiry_warning_count": 2,
  "created_at": "2026-06-07T15:00:00Z"
}

Note: Readout scope is enforced at the repository layer. The service returns only answers tagged to the customer_scope you specify. Answers for other customer scopes are never included, even if you omit a filter or search broadly.

2. Read the assembled readout

Retrieve the full readout content using the readout_id:

curl -s "http://localhost:8000/v1/readout/rdout_01j2k3l4m5n6p7q8r9x5"

The readout body is organized into sections by Horn type. Review the structure before the next step.

3. Export the readout as a Markdown file

For use in meeting preparation documents, slide decks, or shared workspaces, export the readout as Markdown:

curl -s "http://localhost:8000/v1/readout/rdout_01j2k3l4m5n6p7q8r9x5/export?format=markdown" \
  -o "acme-corp-readout-2026-07-01.md"

You can also export as JSON-LD for structured downstream consumption:

curl -s "http://localhost:8000/v1/readout/rdout_01j2k3l4m5n6p7q8r9x5/export?format=jsonld" \
  -o "acme-corp-readout-2026-07-01.jsonld"

The Markdown export returns Content-Type: text/markdown. The JSON-LD export returns Content-Type: application/ld+json. All other readout endpoints return application/json.

4. Review the post-meeting readout option

After the meeting, you can generate a post-meeting readout that captures follow-up items and any new questions that arose:

curl -s -X POST http://localhost:8000/v1/readout/post-meeting \
  -H "Content-Type: application/json" \
  -d '{
    "customer_scope": "acme-corp",
    "meeting_date": "2026-07-01",
    "new_questions": [
      "Does the platform support multi-region failover?",
      "What is the SLA for the SSO integration?"
    ]
  }'

New questions submitted post-meeting are created as OPEN_ISSUE candidates and enter the generation pipeline for follow-up.

5. Review key sections in the readout

When reviewing the exported readout, focus on these sections:

Confirmed Capabilities (FACT / CAPABILITY answers) These are validated claims about what the product can and cannot do. Use these during the meeting to answer feature and capability questions with confidence. Each claim is backed by a validation_record_id and evidence_links.

Procedures Step-by-step processes relevant to this customer. These are validated PROCEDURE-type answers. Reference them when discussing implementation or onboarding steps.

Open Issues Unresolved questions — either classified as OPEN_ISSUE or questions for which no validated answer exists in this scope. Do not present open issues as confirmed answers. Note each one for follow-up.

Expiry Warnings Answers whose review_due date is within 30 days. These answers are still APPROVED but may be approaching staleness. Treat expiry-warned answers as potentially stale and verify with your subject-matter expert before presenting them as current.

Note: Answers marked DISPUTED are excluded from the readout by default. If you need to review them, re-run the readout with "include_disputed": true. When included, disputed answers are shown with a warning indicator. Do not present disputed answers as confirmed facts in customer-facing meetings.

6. Address open issues before or after the meeting

If the readout contains open issues:

Note them explicitly in your meeting preparation
If internal sources (prior transcripts, product documentation, engineering notes) might contain the answer, submit a generation work item for each open question
If the question arises in the meeting and is answered, capture the conversation as a new ingest artifact immediately after the meeting

Important: The readout is a point-in-time snapshot assembled when you call POST /v1/readout/pre-meeting. If new answers are validated or existing answers are updated between now and the meeting, re-run the readout to get the latest state. Do not rely on a readout generated more than 24 hours before a meeting without confirming that no material changes have occurred.

Result

You have a structured readout organized by Horn type covering all validated knowledge for this customer scope and meeting date. The readout includes confirmed capabilities, relevant procedures, open issues requiring follow-up, and expiry warnings for answers approaching their review date. The readout is available as a Markdown file ready for use in meeting preparation documents.

See also: Maintain Answer Lifecycle; Publish an Approved Answer to the Registry; Ingest a Conversation Source