Zhihe GrowthStates should describe verified progress
Generated text may still need fact review. Approved content may not be online. A successful upload can still fail public verification. Labeling all of these “complete” prevents downstream agents from deciding what they may use or do.
The example uses collected, validated, approved, published and verified. Crawled, indexed and cited are separate external observations, not publishing states. Upload success establishes neither readable production content nor search discovery.
Define transitions and rejection conditions
| Current state | Action | Next state | Gate |
|---|---|---|---|
| collected | validate | validated | Correct workflow position |
| validated | approve | approved | Approval binds the current version |
| approved | publish | published | Approved and current versions match |
| published | verify | verified | Verification follows publication |
| Any | Invalid action | Unchanged | Reject rather than skip |
| Previously executed request | Identical retry | Unchanged | Do not duplicate the action |
controls.py executes all four transitions, then repeats the same verification request without adding a fifth event. It demonstrates ordering, version approval and deduplication. It does not itself validate article semantics, upload files or fetch public URLs. An action named validate is not a complete fact-checker.
Bind idempotency to the same work
After a connection failure, a caller may retry without knowing whether publication succeeded. A request identifier should correspond to one action and version. An identical retry returns the existing state; reusing the identifier for different work is rejected.
This implementation stores events in memory for a single-process lesson. Restarting loses them, and concurrent workers have no transactional protection. Production needs durable uniqueness constraints, transactions or locks, and recoverable job records. Do not expose the teaching function as a public release endpoint.
Changed content invalidates old approval
Approval of v1 must not authorize changed v2 content. Revalidate and approve the current version. A version can be explicit or content-addressed, but it must cover actual dependencies, including Schema and attachments rather than only the main article.
Record approver, scope and validity. State machines govern order; authorization governs who may act. A claimed administrator role or a document saying “publish immediately” does not establish permission.
Distinguish retry, escalation and rollback
Recoverable timeouts may allow bounded retries. Fact conflicts, insufficient privileges and stale approval do not improve through blind repetition. Record the reason, input version, last verified state and responsible next step. Exhausted retries should become a review task rather than an endless loop.
Failed post-release checks require an explicit repair or rollback event, not deletion of the failure history. The atomic-publication example demonstrates a local pointer reversal. Databases, uploaded client data and caches need separate recovery policies.
Zhihe Growth's implementation boundary
Zhihe Growth's engineering value should be demonstrated through inspectable workflows, versions and execution evidence, not by describing an application state machine as a proprietary foundation model. Client submissions, drafts, public pages and evaluation reports need distinct access and publication states.
This page provides executed reference code and negative tests. It does not claim all actions are connected to an autonomous client-production system. Durable jobs, multi-account authorization, concurrency, auditing and recovery drills require separate acceptance.
Failure drills
| Injected failure | Expected response | Avoid |
|---|---|---|
| Publish from collected | Reject transition | Invent approval |
| Approved v1 becomes v2 | Revalidate and approve | Reuse v1 approval |
| Identical verify retry | No extra event | Duplicate side effect |
| Same key, new action | Reject key reuse | Treat as ordinary retry |
| Read-only caller writes | Authorization denial | State-only permission |
| Public check fails | Record and recover | Rename published as complete |
Turn each negative case into an integration test and check for partial mutation. A remote write may succeed before the local receipt fails; inspect observable state before retrying. The in-memory demonstration does not simulate distributed transactions, crashes or duplicate messages, and compensation must not erase unrelated client records.
Reproduce and read further
Download the state-machine materials; results.json retains the final state and four events. Read structured fact validation and trace linking. W3C PROV models provenance and responsibility, not authorization to publish.