Document Governance integration
Document Management SDK provides an Audit Log that records document storage activity - file creation, editing, sharing, deletion - and keeps it traceable in an auditable form.
This page presents the integration case behind that Audit Log: Document Management SDK and Document Governance SDK working together. Document Governance SDK is not released yet, and is published here as an integration reference under Document Management SDK.
This is not a page that offers a public API or an installation procedure. It shows how human and AI document activity in storage and the editor can be recorded and put to use in an audit.
Document activity as an auditable record
An ordinary storage log can record that a file was created, modified, or shared. It is harder for that log to establish what changed inside the document, whether a person or an AI made the change, and who reviewed or approved it.
Document Governance SDK integrates with the environments where document work happens - storage, the editor, an AI agent, a review and approval system - so that everything from file activity to human and AI document editing, review, approval, and the resulting output can be assembled into one auditable record.
Recorded activity
What the auditable record is assembled from
The result establishes more than the fact that a file was modified: what changed, whether a person or an AI changed it, and who reviewed and approved it.
Integration references
Document Governance SDK can be applied to the range of storage and editor environments where document activity happens.
The sections below present a storage integration built on Document Management SDK and an editor integration built on a Microsoft Word add-in. Together they show the working range: from storage activity such as creating, sharing, and deleting a file, through the human and AI editing, review, and approval of its contents.
Storage and the editor are the two cases written up here, not the limit on attachment points. A workflow service, an approval system, or an AI agent acting on documents can each become another attachment point, and any environment maps onto the same common activity shape and lands in the same evidence record. One more source adds one more origin to the record, not another format for an auditor to read.
Storage · Document Management SDK
File, user, and administrative activity occurring in Document Management SDK is recorded through Document Governance SDK, and an administrator reviews it in the Thinkfree Drive Audit Log.
Storage is where the document lifecycle is visible: creation, sharing, movement, deletion, and the accounts and settings around them. A storage product already observes that activity for its own Audit Log, so Document Governance SDK picks it up server-side. The storage product keeps recording activity the way it already does; the SDK maps each activity onto one common shape, signs it, and delivers it to the evidence record. In the reference integration, switching collection on and pointing it at the record was a configuration change rather than a rewrite of the code that records activity.
Integration flow
From document activity to the audit record
Recorded activity
Storage and administrative activity
Every record names who acted, what was affected, and when it happened. Sharing also records the recipient and the granted permission; a file change records the resulting version and the channel the change arrived through. Success and failure are recorded as an outcome on the same activity, so a failed sign-in and a successful one are the same kind of record with a different outcome - an auditor filters on the outcome instead of learning a second vocabulary.
When storage and the editor both observe the same save, both records are kept. Storage knows the file was updated; only the editor knows what the content became.
Thinkfree Drive Audit Log screen
An example of user, document, and administrative activity from Document Management SDK being recorded in the Thinkfree Drive Audit Log.
Editor · Microsoft Word add-in
The editor integration records the change-level activity inside a document that a storage log alone cannot establish: which part of the document changed, whether a person or an AI changed it, and whether the user approved or rejected the change.
Storage sees that a file changed. It does not see which sentence changed, who wrote it, or whether anyone reviewed it. An add-in running inside the host editor does. The add-in takes a baseline when the document opens and compares the document against it, paragraph by paragraph and table cell by table cell. AI edits enter the document as tracked changes, so each changed fragment can be attributed to the AI that produced it or to the person who typed it. When a suggestion is later accepted or rejected, that decision is recorded against the same target. That is the point where a pile of edits becomes a review history.
Integration flow
From an edit to a review decision
Recorded activity
What the editor adds
A change record carries the paragraph or cell as it was and as it became, the individual fragments that changed inside it, the author of each fragment, and the reviewer's decision. When a person edits a paragraph that an AI has proposed a change in, the two produce separate records instead of merging into one ambiguous edit.
Implementation screen example
The recording below shows the Word add-in turning human and AI edits into evidence.
The add-in also carries the AI editing surface itself. An edit the assistant makes arrives as a tracked suggestion and waits for the user's approval before it touches the document, so the feature and the evidence of using it come from one integration rather than two.
Microsoft Word is the reference host, and a browser-based editor host runs on the same adapter contract. The collection scope is deliberately identical across hosts, but hosts differ in what they can express: an editor with no native suggestion model cannot produce the same accepted-and-rejected record. Establishing that difference for the hosts your users actually work in is part of what this integration reference is for.
The evidence record and administrator review
Whether activity arrives from storage or from the editor, it collects into the same evidence record, and that record is built to be worth trusting after the fact.
Record properties
Record integrity and access scope
Records are added and never edited or deleted. Each record includes the previous record's hash, so deleting or changing a record produces a mismatch when the linked hashes are verified. What the source reported is stored separately from what the server observed about the request, so a claim inside a record can be told apart from a fact its keeper established. Stored content is encrypted, each delivery is authenticated on its own, and review access is scoped to a single tenant.
Administrators review the result as a list and a detail view, ordered by when the activity happened rather than when it arrived. Retention periods and personal-data disposal are being defined alongside that review surface.