Archived historical specimen.
The current runnable public workflow demo is reliable-ai-workflow-demo.
This repository remains available for provenance and can be reactivated if its specific specimen is needed.
A zero-dependency Node.js demo that adopts only the Candidate set explicitly bound by Authorization.
Candidate and Authorization match exactly
-> Canonical changes once: 0 records to 5
Mismatch
-> Canonical does not change: mutation 0
Unknown values
-> remain null
It neither decides which version is correct nor approves publication or deployment.
Node.js 20 or later is required. No dependency installation, network connection, or signup is needed.
npm run demo:publicRun the complete check set:
npm run test:ra2
npm run test:ra3
npm run verify:public| Command | What it checks |
|---|---|
npm run demo:public |
Successful 0→5 adoption, preserved unknowns, repository mutation 0 |
npm run test:ra2 |
The success path, eight failure cases, and three execution guards |
npm run test:ra3 |
Repeatability, mismatch behavior, and the publication boundary |
npm run verify:public |
The 41-file Manifest, file hashes, leakage checks, and README boundary |
When Candidate and Authorization match, the empty Canonical receives exactly five records in one mutation:
PUBLIC_DEMO = PASS
CANONICAL_STATE_BEFORE = EMPTY
CANONICAL_STATE_AFTER = ADOPTED_EXACT_SET
AUTHORIZED_RECORD_COUNT = 5
CANONICAL_RECORD_COUNT = 5
UNRESOLVED_RECORD_COUNT_BEFORE = 1
UNRESOLVED_RECORD_COUNT_AFTER = 1
UNRESOLVED_STATE_PRESERVED = true
CANONICAL_MUTATION_COUNT = 1
TRACKED_REPOSITORY_MUTATION_COUNT = 0
DEPLOYMENT_APPROVED = false
PUBLICATION_APPROVED = false
One record is intentionally incomplete:
cue_id = cue-04-unresolved-transition
light_token = null
duration_ms = null
unresolved_fields = ["light_token","duration_ms"]
The two null values are not filled in. Preserving an unknown value is a valid
result, not a failed run.
AI-assisted work produces plausible revisions quickly. A file can be the newest one and still differ from the version that was reviewed. It can also be reviewed without having been adopted, or adopted without being approved for publication.
This demo keeps three artifacts separate:
| Artifact | Role |
|---|---|
| Candidate | The five proposed records |
| Authorization | The exact set permitted for this adoption |
| Canonical | The formal state after a successful adoption |
Authorization binds the Candidate and Schema byte-level SHA-256 hashes, artifact paths, ordered record IDs, record count, decision, and expected Canonical before-state.
The adoption runs only when every bound value still matches. A changed Candidate, altered Authorization, unexpected Canonical before-state, missing record, additional record, or duplicate ID stops the run before Canonical is replaced.
| Mismatch | Result |
|---|---|
| Candidate changes after Authorization | AUTHORIZATION_INVALID, mutation 0 |
| Authorization decision changes | AUTHORIZATION_INVALID, mutation 0 |
| Canonical has the wrong before-state | CANONICAL_NOT_IN_AUTHORIZED_BEFORE_STATE, mutation 0 |
| Records are missing, additional, or duplicated | adoption fails, mutation 0 |
| A simulated failure occurs before replacement | no partial Canonical, mutation 0 |
Approval of four records does not result in four records being adopted. Success changes Canonical once; failure changes it zero times.
The public command copies the required files into an operating-system temporary directory. It never mutates Candidate, Authorization, Canonical, or recorded results in the repository.
Before the first write, the implementation validates every input in memory. It then writes the complete output to a temporary file in the Canonical directory, syncs it, and renames it into place. A separate verifier recalculates record equality, hashes, counts, unresolved values, and the mutation receipt.
This is a local file demo, not a concurrent-writer or distributed transaction system.
npm run test:ra2
npm run test:ra3The 28 tests cover exact-set adoption, eight failure cases, three execution guards, Candidate and Authorization tampering, the Canonical before-state, repeatability, preserved unknowns, repository mutation 0, publication isolation, and public-language boundaries.
This demo does not:
- decide whether the records are true, correct, safe, or worth adopting;
- verify the identity or authority of the Authorization issuer;
- provide digital signatures or key management;
- implement complete concurrent-writer control or distributed transactions;
- approve publication or deployment;
- use GitHub as Canonical storage, an Authorization issuer, or a PR approval system;
- claim production or product readiness.
Same as reviewed ≠ true
Exact-set adoption ≠ correct meaning
Adopted into Canonical ≠ approved for publication or deployment
Authorization file present ≠ issuer identity or authority verified
GitHub is only the distribution surface for the code, its history, and a fixed commit.
authorization/ toy Authorization binding the exact set
canonical/ recorded adopted result
fixtures/ fictional Candidate and empty Canonical
src/ validation, adoption, and independent verification
tests/ success, failure, guard, and publication-boundary checks
docs/ protocol, expected behavior, limitations, and reexecution
publication/ 41-file Manifest and leakage-check results
See Third-Party Runbook, Publication Boundary, and Public Demo.
- Wedge Case 0 separates state and halt categories.
- Wedge Case 1 separates an item HOLD from a workflow HOLD.
- Wedge Case 2 separates handoff readiness, approval, and execution authorization.
- Wedge Case 3 separates a proposed set, its authorized scope, and Canonical.
Each case adds one boundary; it does not replace the earlier cases.
If you run the demo, find a boundary case, or have a question about its stated limits, open an issue. Include only public-safe material: what you tried, the conditions, what you observed, and what you expected.
For related runnable examples and field notes, visit the Jinen Project public hub.
AIや複数人と作業していると、似た修正版が増えていきます。
どれが最新か分かっても、その内容が確認時と同じか、正式版へ反映済みか、 公開してよいかは別の問題です。
このデモは、確認した範囲と同じものだけを正式版へ反映します。
CandidateとAuthorizationが完全一致
→ Canonicalを0件から5件へ一度だけ変更
不一致
→ Canonicalを変更しない（mutation 0）
未確認の値
→ nullのまま保持
Node.js 20以降を使用します。npm install、外部package、network接続、
signupは必要ありません。
npm run demo:public
npm run test:ra2
npm run test:ra3
npm run verify:public成功時は空のCanonicalへ5件を一度だけ反映します。未解決Record
cue-04-unresolved-transitionのlight_tokenとduration_msは、
どちらもnullのままです。repository内のArtifactは変更しません。
CANONICAL_STATE_BEFORE = EMPTY
CANONICAL_STATE_AFTER = ADOPTED_EXACT_SET
CANONICAL_RECORD_COUNT = 5
CANONICAL_MUTATION_COUNT = 1
UNRESOLVED_STATE_PRESERVED = true
TRACKED_REPOSITORY_MUTATION_COUNT = 0
未解決は失敗ではありません。分からないものを分からないまま残せたことが 正常な結果です。
Candidate、Schema、Authorization、変更前Canonicalのいずれかが Authorizationの指定と一致しなければ、Canonicalを変更しません。
CANONICAL_MUTATION_COUNT = 0
PARTIAL_CANONICAL_VISIBLE = false
Candidate改変、Authorization改変、変更前state違い、Recordの不足・追加・ 重複、保存前失敗は、RA-2／RA-3 testsで再実行できます。
- 内容の真実性、意味の正しさ、品質、安全性
- Authorization発行者の本人性や権限
- digital signatureやkey management
- 複数writerの完全な競合制御
- deployment／publication approval
- production／product readiness
内容が確認時と同じ ≠ 内容が真実
指定範囲だけを採用 ≠ 採用内容が正しい
正式版へ反映した ≠ 公開・配備を承認した
GitHubはコード、履歴、固定commitの配布先です。Canonicalの保存先、 Authorization発行機構、PR承認システムとして使うデモではありません。