“What did we decide about the launch date?” is a simple question that can be difficult to answer after months of meetings. A filename search may find the correct meeting without finding the decision. A semantic search may find a related discussion that never became an approved decision.

This guide designs a small meeting-notes search workflow around OriginChainDB. The important outcome is a traceable result: a useful passage, the meeting it came from and the revision that was indexed. Start with synthetic notes and verify the exact indexing interface against your deployment.

1. Separate discussion from decision

Give each meeting a stable ID. Record its date, title and readable source location. Within the meeting, identify decision passages separately from open questions and general discussion. A result that says “we might launch in June” must not be displayed as an approved June launch.

Use an explicit status field or passage category rather than asking an embedding model to infer approval. Retrieval can help locate evidence; it should not silently change the business meaning of that evidence.

2. Store source records you can inspect

An illustrative starting schema is:

CREATE SCHEMA notes_demo_20261010;

CREATE TABLE notes_demo_20261010.passages (
  id TEXT PRIMARY KEY,
  meeting_id TEXT,
  meeting_title TEXT,
  revision BIGINT,
  category TEXT,
  body TEXT
);
INSERT INTO notes_demo_20261010.passages
  (id,meeting_id,meeting_title,revision,category,body)
VALUES
  ('m1-d1','m1','Release review',1,'decision',
   'The release review is scheduled for 18 June. Maya owns the checklist.'),
  ('m1-q1','m1','Release review',1,'question',
   'The public launch date remains undecided until the review finishes.'),
  ('m2-d1','m2','Support planning',1,'decision',
   'Support training is scheduled for 21 June. Ravi owns the session.');

The fixture makes three different facts explicit. A question about the public launch date should not inherit the review date simply because both passages mention a release.

3. Choose the retrieval unit

Index a passage with enough surrounding context to be understood. In this example, include the meeting title, category and body in the indexed text. Keep the stored source fields separate so the result can show them clearly.

Use the passage ID as the search document ID. Store the source revision in your indexing-job metadata. This connects a returned hit to exactly the text that was intended for indexing.

Follow the OriginChainDB FTS schema guide to index the text into the selected table and field. Creating the SQL source row is not, by itself, proof that the separate FTS write has completed. Inspect the response and test retrieval before marking the passage searchable.

4. Test meaningful questions

Try “release review,” “support training” and “public launch date.” For each query, record the returned source IDs and inspect the actual passages. Do not evaluate only the count of results.

The first question should help a reader find m1-d1. The second should help find m2-d1. For the third, the useful evidence is that the launch date is undecided. A search interface should allow that answer rather than force every question into a fabricated date.

If you add vector retrieval, use a compatible document and query embedding setup and a collection dimension that matches the model output. Evaluate paraphrases such as “when do we train the support team?” using the same labeled source IDs. This is an additional retrieval experiment, not evidence that vectors automatically outperform FTS.

5. Resolve hits to current, permitted evidence

After retrieval, fetch the corresponding source records and check which revision is applicable. Enforce authorization before returning the passage, title, snippet or citation. A hidden meeting title can itself disclose information, even if the full body is suppressed.

For the first UI, show the passage category, meeting title, revision and body together. A person should be able to distinguish a decision from a question without opening three different screens. Include the source location when your application has one.

6. Handle corrections as part of the workflow

Change the review date in a new source revision. Re-index the same logical passage ID using the documented replacement behavior. Confirm that the new date is retrievable and that the old passage is no longer presented as current evidence.

If indexing fails, leave the job recoverable and show the source/index status internally. Do not announce that every search view is current merely because the source row saved successfully. A source revision and an indexing outcome are different pieces of evidence.

7. Keep the scope useful

Begin with a few meetings and ten realistic questions. Include an unanswered question, a corrected decision and an unauthorized meeting. Check that the application can return a useful passage, explain uncertainty and exclude disallowed content.

This workflow makes meeting search more than keyword matching. It preserves the difference between what was discussed, what was decided and what a reader is allowed to see. Those distinctions remain useful whether you later add a chat interface or keep a simple search box.

Index one passage with its meaning visible

The first decision can be indexed using the documented FTS write route. The following Bash example assumes the source rows already exist and the host, tenant and token are provided through the normal secure environment:

curl --fail-with-body -X POST \
  "https://$OC_HOST/v1/tenants/$OC_TENANT/fts/notes_demo_20261010.passages/body" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"doc_id":"m1-d1","text":"Release review. Decision. The release review is scheduled for 18 June. Maya owns the checklist."}'

Repeat for the other two passage IDs using their actual source text. Then query a known phrase of words using boolean mode:

curl --fail-with-body --get \
  "https://$OC_HOST/v1/tenants/$OC_TENANT/fts/notes_demo_20261010.passages/body" \
  -H "Authorization: Bearer $OC_TOKEN" \
  --data-urlencode "q=public launch date" \
  --data-urlencode "mode=boolean"

The expected source is m1-q1. Its body says the date remains undecided. Resolving the hit correctly is therefore as important as retrieving it: the interface must not copy 18 June from another passage and present that as the launch date.

Preserve action ownership separately when the product needs it

The sentence “Maya owns the checklist” describes an action inside a decision passage. If the application needs an action tracker, make that a deliberate extraction with its own stable ID and source reference. An illustrative action record could contain meeting ID m1, owner Maya, task Prepare the review checklist and source passage m1-d1. A person should verify the extracted assignment before it becomes an operational task.

Do not infer a due date from a nearby event date unless the note states that relationship. A review scheduled for 18 June does not automatically mean the checklist is due on 18 June. This is why the diagram distinguishes decisions, actions and open questions: they may occur in the same meeting, but their fields and downstream uses differ.

Define how a correction appears to the reader

Suppose the approved review date changes from 18 June to 20 June. Create a new source revision and carry its identity through indexing. A result card should show the applicable revision and link to the corrected source. If historical decisions remain accessible, label them as historical rather than mixing them invisibly into current search.

Test a query that previously returned the old date, not only one that uses the new wording. Also test a question about the still-undecided launch date. Updating one decision must not accidentally turn an unresolved question into a confirmed plan. Record which passage changed and which passages should remain unchanged.

Judge the first release by evidence quality

Use an acceptance table with the expected passage ID, category and supported answer for each question. Include a phrase match, a paraphrase, a corrected record, a private meeting and a question absent from all notes. Check that a user cannot infer a private meeting’s title or existence through an unauthorized result snippet.

Return a useful empty state when the corpus has no supporting evidence. “No approved decision found in these meeting notes” is more precise than “nothing found” and safer than guessing a date. The workflow is complete when it can retrieve the intended passage, explain what kind of statement it is, identify its current source and preserve uncertainty where the meeting did not reach a decision.