Context is lost between sessions
Long-running AI-assisted work can lose the reasoning that justified a decision once the conversation ends.
Selected work · Product, risk & AI-native system design
Building with AI while keeping authority and accountability human.
AEAS, the Agentic Engineering Assurance System, is a public system record for substantial AI-assisted delivery. I designed it to keep intent, implementation, review, evidence, risk decisions, and release distinct and traceable.
Ata Nasseri, Product Manager · FinTech & Consumer Credit · Risk & AI-Native Product Development
Role in AEAS: System Designer and Assurance Owner
Human authorityOwner approved
AI-assisted implementation
Accelerated implementation
Fast, variable work inside an authorized package.
Governance boundary
- Intent: Owner intent
- Pinned handoff: Pinned handoff
- Review: Read-only technical audit
- Owner decision: Owner decision
Traceable delivery
Ordered, inspectable work
- Evidence
- Controlled release
- Governed reviews represented
- 3Governed reviews represented
- Preserved audit reports
- 7Preserved audit reports
- Recorded findings
- 33Recorded findings
- Fixed · criteria revision
- 32 · 1Fixed · criteria revision
Figures describe the retained AEAS record. Signed release and DOI archive are public; independent review has not yet been performed.
The real question was whether a human owner could still explain what was authorized, what changed, what was reviewed, what risk remained, and what was released.
Why AEAS
When delivery accelerates, accountability has to become more explicit, not less.
- Turned an ambiguous AI-delivery problem into a governed operating model.
- Defined decision rights, acceptance criteria, risk gates, and release authority.
- Connected product intent, implementation, technical review, evidence, and controlled release.
- Used AI for leverage while preserving named human accountability.
What can drift
What AEAS makes explicit
Bounded review rounds
Each round has an explicit scope, criteria, and a retained record that outlives the conversation.
The source keeps moving
A reviewer can otherwise inspect a state that changes before findings are resolved.
Pinned source checkpoints
Each handoff identifies the exact source state to which the review and evidence refer.
Authority disappears into conversation
Instructions, assumptions, and approvals can become difficult to distinguish later.
Named, durable owner decisions
Criteria, dispositions, residual-risk decisions, and release authority remain attached to a human owner.
AI can compress the distance between an idea and an implementation. But over a substantial body of work, speed creates a second problem: continuity.
What exactly was authorized? Which version was reviewed? Does collected evidence prove that a control was enforced? Who accepts a remaining risk? And how do we know that the approved state is the state that was released?
I designed and governed AEAS not to demonstrate that AI can write code. That is no longer the interesting question. I designed it to explore the system around the work: the roles, boundaries, evidence, decision rights, and release controls that keep human accountability real when AI becomes part of delivery.
AI-assisted implementation and a read-only technical audit role operated inside those human-defined boundaries. Their capability did not inherit the owner’s authority.
AEAS is one inspectable expression of how I work across product, risk, complex systems, and AI-native development. The repository contains the evidence; the professional value lies in the judgment and operating model behind it.
My role
I designed the operating model and held the human decision rights.
Ata Nasseri
System Designer and Assurance Owner
I defined the structure within which the work could be authorized, reviewed, challenged, and released.
- Objectives and acceptance criteria
- Defined the objectives, constraints, and criteria used to judge completion.
- Authority boundaries
- Separated owner, implementation, and read-only technical-audit responsibilities.
- Findings and risk decisions
- Authorized review rounds and decided fixes, criteria changes, and residual-risk treatment.
- Release authority
- Preserved human-only authority for criteria changes, risk acceptance, and release approval.
AI-assisted implementation and read-only technical audit operated within the boundaries I defined. This was operational separation, not institutional independence or external certification, and I do not claim personal authorship of every implementation artifact.
One project · a broader practice
My work spans FinTech, consumer credit, regulated financial infrastructure, venture building, risk, and AI-native product development. The settings differ, but I repeatedly return to the same task: understand the system, make the important assumptions visible, identify who can decide what, and build a path from uncertainty to an accountable outcome.
- Make assumptions visible
- Turn tacit expectations into explicit constraints, acceptance criteria, and evidence boundaries that others can inspect and challenge.
- Own the problem end to end
- Connect intent, delivery, review, decision, and release rather than optimizing one isolated step and calling the problem solved.
- Move with risk in view
- Treat risk as part of product design and execution, not as a late-stage objection or a reason to avoid movement.
- Keep judgment human
- Use AI for speed, synthesis, and leverage while keeping material decisions, evidence interpretation, and accountability with a named human owner.
A named human owner retains criteria, risk, and release decisions; an implementation role changes the system within a bounded package; an operationally separate read-only technical audit role inspects a pinned state and records findings.
Named human owner
Decision rights◆ Human decision rightsDefines objectives, constraints, acceptance criteria, and continuation conditions. Retains authority for criteria changes, residual-risk decisions, finding dispositions, and release approval.
AI-assisted implementation role
System changeProduces and corrects work within the bounded package. It does not inherit authority to change criteria, accept residual risk, validate its own result, or approve release.
- No criteria change
- No residual-risk decision
Read-only technical audit role
Pinned-state inspectionInspects the identified source state and records findings without modifying the inspected implementation and without authorizing release.
- No modification of inspected state
- No release approval
Named human owner
- Can
- Define criteria, authorize continuation, disposition findings, decide on residual risk, and approve release.
- Does not delegate
- Does not delegate human-only decision rights to technical roles.
- Receives
- The candidate state, findings, evidence, and limitations.
- Produces
- Authorization, resolution decisions, or a return for further work.
Within AEAS, implementation capability does not confer audit or release authority; audit capability does not confer release authority.
The technical audit role was operationally separate and read-only. This is not a claim of external or institutional independence.
The governance model
Capability is not the same as control.
The design requirements were not limited to model performance. They also concerned the way work, authority, evidence, and change were organized.
Authority remains explicit
Important decisions remain attached to a named human owner and a durable decision record, so an instruction is never mistaken for an assumption or an approval for a suggestion.
Implementation and review remain distinct
A role that builds the work must not silently reinterpret the criteria or validate its own result, otherwise review exists in form while losing its function.
Evidence, approval, and release identity remain connected
The reviewed state, owner decision, and released artifact must remain traceable to the same evidence-bearing identity, so the approved state cannot drift before release.
Separate the roles. Preserve the handoffs. Keep the decision human.
AEAS moves from human owner intent through bounded implementation, a pinned handoff, read-only technical audit, owner decision, and controlled release. Technical capability does not inherit human authority.
- HUMAN AUTHORITYHuman owner intent▪ Criteria recorded
- HUMAN-DEFINED SCOPEBounded work package
- BOUNDED TECHNICAL ROLEAI-assisted implementation
- IDENTIFIED SOURCE STATEPinned handoff▪ Source state identified
- BOUNDED TECHNICAL ROLERead-only technical audit▪ Findings recorded
- HUMAN AUTHORITYResolution and owner decision▪ Disposition recorded
- HUMAN-AUTHORIZED RELEASEControlled release▪ Release identity
- HUMAN AUTHORITYHuman owner intentThe named owner defines the objective, constraints, acceptance criteria, and decision rights.▪ Criteria recorded
- HUMAN-DEFINED SCOPEBounded work packageScope and success conditions are made durable before implementation begins.
- BOUNDED TECHNICAL ROLEAI-assisted implementationThe implementation role changes the system within the authorized package; capability does not confer approval authority.
- IDENTIFIED SOURCE STATEPinned handoffThe source state submitted for review is identified so findings and evidence refer to the same object.▪ Source state identified
- BOUNDED TECHNICAL ROLERead-only technical auditAn operationally separate, read-only role inspects the pinned state and records findings without modifying it.▪ Findings recorded
- HUMAN AUTHORITYResolution and owner decisionFindings are addressed; criteria changes, residual-risk treatment, and the decision to proceed remain human.▪ Disposition recorded
- HUMAN-AUTHORIZED RELEASEControlled releaseThe accepted state moves through release controls intended to preserve identity and provenance.▪ Release identity
- After the owner decision, work either returns to the bounded work package for revision or continues to controlled release as the accepted state.
1. Human owner intent
The named owner defines the objective, constraints, acceptance criteria, and decision rights.
2. Bounded work package
Scope and success conditions are made durable before implementation begins.
3. AI-assisted implementation
The implementation role changes the system within the authorized package; capability does not confer approval authority.
4. Pinned handoff
The source state submitted for review is identified so findings and evidence refer to the same object.
5. Read-only technical audit
An operationally separate, read-only role inspects the pinned state and records findings without modifying it.
6. Resolution and owner decision
Findings are addressed; criteria changes, residual-risk treatment, and the decision to proceed remain human.
7. Controlled release
The accepted state moves through release controls intended to preserve identity and provenance.
Recorded outcomes
Evidence with its boundaries intact.
These figures describe what the retained AEAS record reports. They are not claims of external certification, defect-free operation, or independent replay.
3
governed reviews represented
The retained record preserves audit reports across three governed reviews.
7
preserved audit reports
Six were substantive; one attempted round was explicitly recorded as not auditable.
33
recorded findings
11 HIGH and 22 MEDIUM. No CRITICAL finding was recorded.
32 · 1
fixed · criteria revision
32 findings recorded as fixed; one settled through an owner-ratified revision of the criterion.
Three final-round findings were recorded as defects introduced by earlier corrective work, a useful reminder that a fix is still a new change and must earn its own confidence.
How the four metrics are qualified
Each figure is drawn from the retained record rather than from an independent replay. Dispositions describe what the record states about a finding, not proof about the state that changed. The committed completion record also reports 1,111 tests green in two tiers; the sealed private evidence set does not contain the exact final raw test log, so that result is reported rather than independently reproduced.
Full qualifications, provenance notes, and the artifact catalogue are in the Technical Record.
The difficult part was not generating more. It was knowing what deserved trust.
Tempting shortcut
Working principle
Tempting shortcut: Treat a corrective change as evidence that the issue is closed.
Working principle: A fix is a new change, not proof.
Corrective work can introduce new defects. A closed finding is a disposition; confidence still depends on evidence about the state that actually changed.
Tempting shortcut: Collect evidence without making any action depend on it.
Working principle: Evidence collection is not enforcement.
A system can retain excellent evidence and still permit the wrong action. A control becomes meaningful when missing or invalid evidence blocks the side effect it is meant to govern.
Tempting shortcut: Check a condition only after publication or release has begun.
Working principle: Fail closed before the side effect.
Detecting a control failure after an artifact has been published, a release has moved, or an external state has changed is not equivalent to preventing it.
Public record
Do not take the story on trust. Inspect the record.
Four public anchors, in the order the evidence was produced: record, release, archive, and the boundary of what any of it establishes.
- Public RecordPUBLIC
Public project record
The overview, public evidence index, and repository history.
- Signed ReleaseSIGNED
Signed immutable release
The v1.0.0 release, annotated tag, checksums, and release notes.
- DOI ArchiveARCHIVED
Citable DOI archive
A version DOI and an all-versions concept DOI for citation.
- Review StatusREVIEW NOT YET PERFORMED
Evidence boundary and review status
Independent-review package prepared; independent review has not yet been performed.
What this record does and does not claim
Credibility includes the edge of the evidence.
What the public record supports
- A defined governance model
- Evidence-qualified assurance activity
- Recorded finding dispositions
- A signed and archived release
What it does not establish
- External certification
- Institutional audit independence
- Defect-free or fully secure operation
- Regulatory compliance
- Production deployment
- Universal fitness for other organizations
Independent-review package prepared; the independent review has not yet been performed.
Transferable discipline
The context changes. The need for clear authority does not.
In financial infrastructure, consumer credit, product transformation, and AI-native development, important outcomes rarely belong to one function. When the connections between decisions, systems, controls, and people are implicit, risk accumulates in the gaps.
AEAS demonstrates disciplines that travel across those environments: explicit decision rights, evidence-bearing delivery, controlled change, separated review, explicit residual-risk decisions, and a named human owner.
Useful to product leaders, leaders of consequential AI-assisted systems, founders, engineering leaders, and risk and assurance professionals designing accountability around agentic work.
Working on a consequential product where the path is unclear?
I am interested in work where product intent, risk, technology, and human accountability have to be designed together. Let us start with the problem before pretending the solution is obvious.
What are you trying to make clearer?
Technical Record
Complete evidence set: full metric qualifications, all lessons, handoff and release-integrity diagrams, boundary notes, provenance, and the artifact catalogue.
Found the record useful?
Star the GitHub repository to help relevant practitioners discover it. A star is a discovery signal, not assurance evidence.