AI suggestions with human authority: bounded candidates, transactional confirmation and recovery

Language: English | 简体中文

I added AI-assisted Concept suggestions to FLH to reduce the manual effort of reviewing extracted knowledge. The model proposes existing Concepts and explains its choice; the user confirms each item before membership changes. The implementation keeps generated evidence, current state and human authority separate.

My engineering contribution: defining bounded inputs and candidates, designing generation and confirmation as different operations, and hardening their replay, cancellation and stale-state behavior.

发布日期：2026-10-22

Give the model a bounded decision

The user explicitly selects up to 10 reviewable units. For each, the service prepares at most five existing candidates using exact-signature matching and BM25. A unit with no candidates is not sent to the provider. Suggestions can recommend one candidate or express uncertainty; they cannot create arbitrary Concept IDs.

The provider response is checked for missing, duplicate or foreign unit IDs, out-of-catalog Concepts and invalid reasons. A malformed response records a failed run rather than partially accepting items.

Candidate recall is part of the design: a suitable Concept with no lexical overlap may never be offered. This makes the current feature useful as review assistance while leaving room for later candidate-retrieval improvements.

Generation writes evidence, confirmation changes membership

Generating a suggestion creates a stored run and advisory items. It changes no memberships, human labels or admission decisions. The interface offers individual confirmation and an option to leave a suggestion unused.

Confirmation is a transaction: acquire the write lock, recheck the unit and target, append the attributed human SAME event, update the current membership and store the receipt. A changed extraction, new membership, INVALID judgment, retired or changed target, or newly recorded DISTINCT blocks confirmation with a conflict.

Concurrent confirmations of the same item produce one event. Replaying a confirmation returns that event without reassigning the unit.

Recover a result without paying for it again

A keyed generation run can be looked up after a lost response. The follow-up review found a race: a second request could read “not committed” before taking the in-flight slot, then call the provider after the first request finished. Taking the slot before lookup closes that gap within one server process.

Another failure occurred when the client disconnected after the provider returned. Using the canceled request context discarded a possibly billed result. The result commit now uses a detached context with a 10-second bound, so the completed run can be recovered by key.

Failed runs replay as failures. Trying again is an explicit new request with a new key. Provider execution can still repeat if a server stops before commit, storage fails or multiple server processes race. The durable guarantee is one stored run per key, rather than an unsupported promise of exactly-once external billing.

Historical confirmation is not current authority

A confirmed suggestion may later be corrected. Its original event still exists, but it may no longer own current membership. The response derives confirmation.still_current, and the UI labels superseded confirmation as historical.

That is the same boundary used throughout FLH: evidence is preserved, and current authority is read from the current projection.

Bilingual review follows the same principle

The recent work also stores English and Chinese explanation variants from the same explicit provider request. Interface language and explanation language are separate preferences. Feedback records which stored languages were shown and permits language-specific corrections.

Accepting one language does not imply the other was reviewed. Older records keep their original text with language-unrecorded labels. The change adds explanatory views without changing Concept signatures or embedding representations.

Verification

The suggestion tests use isolated databases and a fake provider to check advisory-only generation, bounded candidates, malformed output, concurrent keys, stale confirmation and replay. Mutation checks restore the old race or canceled commit behavior and demonstrate failing regressions. The follow-up’s full verification records 312 frontend tests plus Go tests, vet and builds; that is the suite at that snapshot, not 312 new tests for this feature.

Real-model suggestion and bilingual quality remain to be evaluated on reviewed examples. The delivered engineering result is the complete workflow and its recovery contract.

Implementation used Claude Code and Codex under my direction, task definitions and review.

Suggestion validation · Correctness follow-up · Bilingual explanations · About me

Implementation milestone.