Architecture

​

The steps

1. Write. Your application writes documents to a namespace. Brussle stores each write in the namespace’s log before it acknowledges the write. When the write returns, the documents are durable. A write can ask Brussle to wait for the answers of the documents that it wrote, with wait_for.
2. Find. The reference index records which answers read which documents. From the log, Brussle finds each answer that read a changed document. Those answers become pending. Answers that did not read the document are untouched.
3. Settle. Brussle waits for a burst of changes to end before it judges. For a change to a related document, the wait is the judgment’s fan-out debounce_ms, 10 minutes by default, and at most max_wait_ms, 1 hour by default. See freshness policies.
4. Skip or judge. If nothing that an answer reads changed, Brussle reuses the earlier answer without an engine call. Otherwise it compiles the context from the recipe, checks the namespace’s budget, and calls the engine.
5. Record. Each engine call becomes an evaluation: the exact text that the engine read, the related documents and their revisions, the engine’s output, and the question and engine versions. The answer becomes fresh.
6. Serve. Your application queries the answers, filters on them, and gets an event when a document enters or leaves a subscription.

​

What each step means for you

• An answer is pending between steps 2 and 5. A read with wait_ms waits for it. A query with answers: "fresh_only" leaves it out. See freshness.
• Step 3 is why a read right after a change to a related document can still show pending. Set a shorter debounce_ms when you need the new answer sooner.
• Step 4 is why a write that changes nothing the recipe reads costs nothing.
• Step 5 is why you can explain any answer later: open its evaluation. See what you can rely on.