Understand the decision story
Choose a role, read the nine checkpoints, and see what a reviewer should be able to verify. No command line or repository setup is required.
Follow the decision story →Hands-on implementation tutorial
Build one governed AI path, end to end.
Run the synthetic Golden Credit Assist example, trace every lifecycle decision to architecture and evidence, challenge its failure paths, and make a bounded scale, adapt, or stop decision.
LeadersOwn the decision
Delivery teamsEngineer the behavior
ArchitectsMake control repeatable
One boundary→One release→One evidence chain
Evidence boundary
This deterministic educational implementation is not a live credit system, production guidance by itself, a benchmark of EAINE effectiveness, legal or regulatory evidence, certification, or proof of superiority.
Suggested reading path
Choose a decision story or a hands-on engineering exercise.
Non-technical readers can follow the role lenses and nine checkpoints without running anything. Engineers can also reproduce the example and inspect every framework reference.
Run the engineering example
Use the repository and specified Node.js version to reproduce tests, generate current evidence, and inspect the implementation controls.
Run the technical exercise →Expected flow: Select a lens, run the baseline checks, step through the nine checkpoints, review lifecycle evidence, and decide scale/adapt/stop with an explicit owner and evidence set.
Three role lenses · one operating record
Carry your decision through the same implementation.
The lenses change what you inspect and decide—not the system boundary, lifecycle, release digest, or evidence chain.
Enterprise leader
Is this bounded workflow ready for controlled field validation, adaptation, or stopping?
Outcome · ownership · risk appetite · residual risk · scale decisionDelivery team
Is the exact behavior testable, releasable, operable, and reversible?
Requirements · versions · evaluation · release · telemetry · recoveryPlatform architect
Which shared boundaries and capabilities make the controlled path repeatable?
Trust zones · identities · interfaces · policy · evidence · recoveryReproduce before interpreting
Run the accepted baseline.
Use a fresh repository clone and Node.js 22.15.1. The example has no credentials, network provider, database, or third-party runtime dependency.
Fresh cloneNode 22.15.1Repository root
node --test reference-implementation/golden-credit-assist/tests/golden.test.mjsnode reference-implementation/golden-credit-assist/src/build-evidence.mjs --checknode reference-implementation/golden-credit-assist/src/validate.mjs
Expected outcomes: Baseline behavior test suite passes without regressions. Evidence digest is generated and matches current implementation checks. Implementation validation passes all configured conformance checks.
Shared progress path
Nine checkpoints from intent to governed learning.
Each checkpoint names a consequential decision and the proof a reviewer should be able to inspect.
- 01
Bound the use case
Define what the system may assist with—and the decision it can never make.
What you should be able to verifySynthetic case summary only; authenticated human remains the sole credit-decision authority.
Framework references
STD-009 · STD-010 · DEC-011 · REC-001/002 - 02
Reproduce the baseline
Run tests, verify the evidence digest, and validate the declared implementation.
What you should be able to verifyNo passing test, no current evidence bundle, no tutorial pass.
Framework references
PB-001 Steps 4–5 · CMP-005–009 - 03
Classify applicability and risk
Recompute the profile and tier instead of accepting a descriptive label.
What you should be able to verifyEAINE-R4 Critical; controls and accountable approval required; no statutory-equivalence claim.
Framework references
STD-009 · STD-010 · REC-001 - 04
Trace all nine lifecycle stages
Connect each accepted decision to its human role, components, evidence, and release digest.
What you should be able to verifyDEC-011 through DEC-019 form one controlled learning loop.
Framework references
STD-002 · CMP-001–015 · REC-001–019 - 05
Map the architecture
Locate policy, identity, knowledge, provider, runtime, telemetry, and evidence boundaries.
What you should be able to verifyA compact executable projection of all 15 canonical component responsibilities.
Framework references
IF-003/004/006/008/010 · TZ-001–006 - 06
Challenge behavior
Run positive, negative, adversarial, regression, and recovery cases.
What you should be able to verifyUnsafe or unauthorized behavior rejects or escalates; recovery is verified after fallback succeeds.
Framework references
CMP-009–011 · REC-009–012 - 07
Inspect release evidence
Verify the exact digest, accepted decisions, operating signals, limitations, and null findings.
What you should be able to verifyA pass supports bounded mechanics—not production readiness or framework effectiveness.
Framework references
DEC-017/018 · REC-013–016/019 - 08
Route a controlled change
Observe an unapproved behavior version fail closed, then identify the required lifecycle re-entry.
What you should be able to verifyNo prompt, policy, provider, or behavior change can self-authorize a new release.
Framework references
DEC-019 · REC-017 · CMP-002/003/015 - 09
Decide: scale, adapt, or stop
Make a bounded next-step decision with an owner, evidence, limitations, and review date.
What you should be able to verifyScale means controlled field validation—not a production, compliance, safety, or certification claim.
Framework references
Evidence before claims · accountable human decision
Lifecycle evidence map
Every stage ends in a human-accountable decision.
The compact implementation projects some components as configuration or records, but preserves all 15 responsibilities and the complete nine-stage trace.
Open the complete lifecycle identifier map
| Stage | Decision | Components | Evidence |
|---|---|---|---|
| Discovery | DEC-011 | CMP-001/002 | REC-001/002 |
| Requirements Engineering | DEC-012 | CMP-001/002/004/010 | REC-003/012 |
| Architecture and Design | DEC-013 | CMP-002/010/011 | REC-004/005/009 |
| Development | DEC-014 | CMP-005/006/007/008 | REC-004/006/007/008 |
| Quality Engineering | DEC-015 | CMP-009 | REC-010/011 |
| Security Validation | DEC-016 | CMP-010/011 | REC-009/012 |
| Deployment and Release | DEC-017 | CMP-003/014 | REC-013/019 |
| Operations | DEC-018 | CMP-012/013 | REC-014/015 |
| Continuous Improvement | DEC-019 | CMP-015/002 | REC-016/017 |
Vision alignment
The tutorial makes EAINE’s commitments observable.
Alignment is demonstrated through engineering boundaries and evidence, not by repeating principles without an implementation consequence.
Human accountability
The model may propose assistance; named people own outcome, release, residual risk, operation, and the credit decision.
Governed context
Only authorized, cited knowledge enters the provider request. Relevance never becomes authority.
Reusable knowledge
Versions, contracts, records, tests, and runtime signals become inspectable organizational assets.
Responsible engineering
Security, responsible AI, release control, observability, and recovery are lifecycle work.
Evidence before claims
Passing evidence supports only the declared synthetic mechanics; limitations and null findings remain visible.
Continuous learning
Signals enter an owned improvement backlog and reopen the lifecycle instead of silently changing behavior.
Complete the tutorial
Leave with a bounded decision—not a broad claim.
Record scale to controlled field validation, adapt, or stop; cite the supporting evidence, limitations, accountable owner, and next review date.
Choose the right EAINE surfaceConceptual walkthrough Runnable tutorial 90-day adoption path Canonical architecture