The Deterministic Layer Behind the Agent
Once an OpenWiki worker has written a page and submitted its Claim decisions, the model's job is not quite finished—and the system's job is not to trust the result blindly. OpenWiki's deterministic finalization layer takes the accepted Markdown and makes its structure, metadata, links, evidence projection, and provenance consistent. Understanding this fixed post-authoring sequence shows which guarantees can be repeated across model providers and which questions still belong to the quality of the explanation itself.
What the model hands over
The authoring agent is good at work that requires interpretation: reading a repository, deciding which relationships deserve explanation, choosing page boundaries, and writing prose that a person can follow. Those decisions are difficult to reduce to a fixed algorithm. They also vary with the model, the available tools, and the context supplied by a native or host-driven run.
Other tasks are valuable precisely because they should not vary. A generated page must have valid Open Knowledge Format (OKF) front matter. Directory indexes should describe the pages that actually exist. A link that points nowhere should not be silently treated as valid. Claim evidence should be visible in machine-readable metadata, and an unchanged page should not receive a new “generated” timestamp merely because a model touched its front matter. OpenWiki assigns these tasks to code-owned finalizers rather than asking a model to remember a long list of formatting rules.
The finalizer works against a preparation baseline. Before authoring, OpenWiki migrates existing concept pages toward valid OKF front matter and records the exact hash of each existing page body, along with its prior generated event. The body hash excludes front matter but retains whitespace, so the later comparison can distinguish a real content change from a metadata-only rewrite. The preparation state is serialized with the run, allowing a resumed process to finalize against the same pre-authoring baseline.
That baseline prevents provenance from becoming a misleading run log. If an agent changes a page body, the finalizer can stamp the new producer and time. If the body is unchanged but the agent removed or altered the generated field, the prior event can be restored. The final metadata describes who produced a changed body, not merely which process happened to inspect the file.
The preparation snapshot is also what makes a restart deterministic. A process may stop after some workers have completed and before the final passes run. On resume, OpenWiki does not have to infer the old body from a later state or treat every current timestamp as new evidence; it rehydrates the saved baseline and compares the current pages with that baseline. This keeps provenance tied to an actual change in the page body, while the run checkpoint keeps the page queue tied to an actual completion event.
The finalizer's order is a dependency chain
Post-authoring work runs in a fixed order: Mermaid validation, index synchronization, internal-link validation, optional Claim-source projection, and generated-provenance reconciliation. The sequence is not cosmetic. Earlier passes can change bytes or links that later passes must inspect.