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.

Run the implementationChoose your role lens
LeadersOwn the decision
Delivery teamsEngineer the behavior
ArchitectsMake control repeatable
One boundaryOne releaseOne 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.

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.

01

Enterprise leader

Is this bounded workflow ready for controlled field validation, adaptation, or stopping?

Outcome · ownership · risk appetite · residual risk · scale decision
02

Delivery team

Is the exact behavior testable, releasable, operable, and reversible?

Requirements · versions · evaluation · release · telemetry · recovery
03

Platform architect

Which shared boundaries and capabilities make the controlled path repeatable?

Trust zones · identities · interfaces · policy · evidence · recovery

Reproduce 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
eaine / tutorial
node --test reference-implementation/golden-credit-assist/tests/golden.test.mjs
node reference-implementation/golden-credit-assist/src/build-evidence.mjs --check
node reference-implementation/golden-credit-assist/src/validate.mjs
Expected: tests pass · evidence is current · implementation is valid

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.

  1. 01

    Bound the use case

    Define what the system may assist with—and the decision it can never make.

    Inspectable outcome

    Synthetic case summary only; authenticated human remains the sole credit-decision authority.

    STD-009 · STD-010 · DEC-011 · REC-001/002
  2. 02

    Reproduce the baseline

    Run tests, verify the evidence digest, and validate the declared implementation.

    Inspectable outcome

    No passing test, no current evidence bundle, no tutorial pass.

    PB-001 Steps 4–5 · CMP-005–009
  3. 03

    Classify applicability and risk

    Recompute the profile and tier instead of accepting a descriptive label.

    Inspectable outcome

    EAINE-R4 Critical; controls and accountable approval required; no statutory-equivalence claim.

    STD-009 · STD-010 · REC-001
  4. 04

    Trace all nine lifecycle stages

    Connect each accepted decision to its human role, components, evidence, and release digest.

    Inspectable outcome

    DEC-011 through DEC-019 form one controlled learning loop.

    STD-002 · CMP-001–015 · REC-001–019
  5. 05

    Map the architecture

    Locate policy, identity, knowledge, provider, runtime, telemetry, and evidence boundaries.

    Inspectable outcome

    A compact executable projection of all 15 canonical component responsibilities.

    IF-003/004/006/008/010 · TZ-001–006
  6. 06

    Challenge behavior

    Run positive, negative, adversarial, regression, and recovery cases.

    Inspectable outcome

    Unsafe or unauthorized behavior rejects or escalates; recovery is verified after fallback succeeds.

    CMP-009–011 · REC-009–012
  7. 07

    Inspect release evidence

    Verify the exact digest, accepted decisions, operating signals, limitations, and null findings.

    Inspectable outcome

    A pass supports bounded mechanics—not production readiness or framework effectiveness.

    DEC-017/018 · REC-013–016/019
  8. 08

    Route a controlled change

    Observe an unapproved behavior version fail closed, then identify the required lifecycle re-entry.

    Inspectable outcome

    No prompt, policy, provider, or behavior change can self-authorize a new release.

    DEC-019 · REC-017 · CMP-002/003/015
  9. 09

    Decide: scale, adapt, or stop

    Make a bounded next-step decision with an owner, evidence, limitations, and review date.

    Inspectable outcome

    Scale means controlled field validation—not a production, compliance, safety, or certification claim.

    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.

StageDecisionComponentsEvidence
DiscoveryDEC-011CMP-001/002REC-001/002
Requirements EngineeringDEC-012CMP-001/002/004/010REC-003/012
Architecture and DesignDEC-013CMP-002/010/011REC-004/005/009
DevelopmentDEC-014CMP-005/006/007/008REC-004/006/007/008
Quality EngineeringDEC-015CMP-009REC-010/011
Security ValidationDEC-016CMP-010/011REC-009/012
Deployment and ReleaseDEC-017CMP-003/014REC-013/019
OperationsDEC-018CMP-012/013REC-014/015
Continuous ImprovementDEC-019CMP-015/002REC-016/017
Inspect the architectureReview all lifecycle stages

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.

01

Human accountability

The model may propose assistance; named people own outcome, release, residual risk, operation, and the credit decision.

02

Governed context

Only authorized, cited knowledge enters the provider request. Relevance never becomes authority.

03

Reusable knowledge

Versions, contracts, records, tests, and runtime signals become inspectable organizational assets.

04

Responsible engineering

Security, responsible AI, release control, observability, and recovery are lifecycle work.

05

Evidence before claims

Passing evidence supports only the declared synthetic mechanics; limitations and null findings remain visible.

06

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.

Scale

Controlled field validation

A separately governed, permissioned study is justified. This is not production approval.

Adapt

Re-enter the lifecycle

The boundary, behavior, architecture, controls, or evidence needs another governed pass.

Stop

Preserve the evidence

Value, permission, control, evidence, or recoverability is insufficient for the next step.

Choose the right EAINE surfaceConceptual walkthrough Runnable tutorial 90-day adoption path Canonical architecture
Open the canonical repository guidePlan a bounded pilot