AI-Assisted Design Engineering Operating System

AI sessions are temporary. Product work isn’t.

I created an operating framework to connect Product Design, Design Systems and Engineering in AI-assisted workflows — with evidence, continuity and human accountability.

I’m Nelson Secco, a Senior Product Designer and UX Consultant. I turned recurring challenges in my practice into a reusable, versioned method for collaboration between professionals and AI agents.

I now use the framework as an operational baseline in real professional work, adapted to each engagement. This case presents the public method; client context and evidence remain private.

The cost of starting over in every conversation

Product work spans days, decisions and tools. When context lives only in a chat, the professional has to reconstruct previous agreements before continuing.

Repeated instructions and decisions lost between sessions.
Conflicting sources and assumptions that begin to pass as facts.
Changes that drift from approved behavior or duplicate the Design System.
Unclear responsibilities and uncertainty about what is complete and what still needs review.

From experiments to a reusable method

Progress meant designing how work continues, who decides and which sources support each action. Three design decisions underpin that transition.

Separate rules, context and state
Keep stable principles in the framework, context within the project and a record of where to resume. Each new session encounters distinct responsibilities rather than one overloaded prompt.
Design for continuity
Organize workstreams, sessions and decisions in persistent records. The next agent must reconcile those records with primary sources and the current artifact before acting.
Evolve against explicit criteria
Version the method, define permissions and establish validation and closure criteria. Framework improvements require a separate assessment before adoption in each project.

Read the design rationale in the public repository

One method, three responsibilities

The framework governs the work. The runtime preserves each project’s state. The session executes a bounded task. People remain accountable for decisions.

Operating framework: Generic collaboration rules covering evidence, scope, permissions, quality and continuity. This is the public, reusable layer.
Project runtime: Persistent records of objectives, decisions, references and next steps. Workstreams organize ongoing work; sessions record each period of execution. Real context stays within the project’s authorized environment.
AI session: Agents inspect, propose and execute within permitted scope. At session end, they record what changed, what was verified and how to continue.

Primary sources: Requirements and approvals retain their provenance. The runtime preserves references and context without replacing the evidence.
Canonical Design System: Approved components, tokens and patterns guide composition. Shared changes require impact assessment and explicit ownership.
Current artifact: The interface, design file or code shows the actual state. Earlier reports must be reconciled with that state.

Generic example: before changing a component, check the approved reference, inspect the current instance, establish who may modify it and record validation where the change belongs.

Explore the public runtime structure

Autonomy with human accountability

AI extends the capacity for analysis and execution. Product direction, interpretation of approvals and final accountability remain human responsibilities.

Human accountability: People define objectives, assess consequences and approve product decisions.
Evidence before inference: Verifiable primary evidence takes precedence over a convenient interpretation.
FACT ≠ INFERENCE ≠ ASSUMPTION: Separate observations, interpretations and what still needs confirmation.
PARITY BEFORE UX EVOLUTION: Preserve approved behavior before proposing changes to the experience.
REUSE → COMPOSE → EVOLVE → CREATE: Inspect and reuse the canonical foundation before creating new patterns.
Change ownership: The owner of the changed file or artifact also maintains its change record.
Persistent continuity: Objectives, decisions and next steps must outlast the conversation’s temporary memory.
Risk-proportionate validation: Run necessary checks and reuse still-valid evidence while preserving mandatory acceptance criteria.
Explicit completion criteria: Define acceptance before testing and distinguish execution, evidence and human approval.

Explore the path from source to completion

A transcript helps recover a conversation. Progressing to requirements, implementation and completion requires review and evidence at each transition.

Recording
recording ≠ transcript
Transcript
transcript ≠ approved requirement
Approved requirement
approved requirement ≠ implementation
Implementation
implementation ≠ validated completion
Validated completion

From methodology to professional practice

I use the framework as an operational baseline in professional practice, adapting governance, tools and confidentiality safeguards to each engagement.

The public method provides reusable principles and contracts.
Project configuration defines authorized sources, the Design System, responsibilities and execution boundaries.
Professional execution applies these criteria to concrete tasks through inspection, review and validation.

Professional use is reported by the author. This case does not present client data, interfaces or results as public evidence.

Explore a generic workflow

This sequence is a generic demonstration derived from public documentation, rather than a depiction of a client engagement.

Context

Define the objective
Bound the scope
Locate sources

Evidence and decisions

Review evidence
Record decisions
Analyze Product and UX

Design and execution

Inspect the artifact
Compose with the Design System
Execute within authorized scope

Validation and continuity

Validate acceptance criteria
Review with accountable people
Record the next step

What has been built — and what still needs evidence

The public outcome is a versioned framework that makes collaboration rules, continuity structures and execution boundaries explicit.

Publicly inspectable: The method, runtime architecture, contracts and release history can be examined in the public repository.
Reported by the author: Use as an operational baseline in real professional work, adapted to each context. Public documentation does not independently establish private operations.
Benefits to measure: Reducing rework, restart effort and inconsistency is an objective of the method. This case presents no comparative measurement of productivity or general agent effectiveness.

Limitations that guide further development

Recovered context can be incomplete or outdated. Resuming work requires checking applicable sources and reconciling state before changing an artifact.
Conversation, documentation and artifacts can diverge. Records preserve intent; inspection establishes the current implementation.
Rechecking everything at every step adds cost without necessarily changing a decision. Prior criteria and still-valid evidence help define when to stop.
Unbounded autonomy leaves responsibilities unclear. Scope, permissions and ownership must precede execution.
Passing tests support only what was checked. They do not constitute human approval or, on their own, demonstrate agent effectiveness.

Read the public validation and closure contract

A public framework that continues to evolve

The method remains experimental and evolving. Documentation, decisions and releases show what has been published and what is still under development.

Published release: v3.9.0, dated October 24, 2026. It adds three optional read-only helpers for source delivery, action-report consistency and supervised work cycles.

Read the v3.9.0 release

After that release, main received additional source-admission and risk-proportionate validation changes. This case references a snapshot inspected on October 26, 2026; those changes are outside the v3.9.0 tag and do not automatically update adopting projects.

View the later source snapshot

The v3.9.0 record reports maintainer-executed local QA. Hosted CI was not verified. This does not establish independent authentication of tool actions, general agent effectiveness or acceptance of optional pilots.

Next steps: refine the rules against verifiable limitations and broaden independent evaluation. New hypotheses need evidence before they can be presented as outcomes.

Follow the release history

The captures below are historical records. They establish the existence of documentation at the captured revisions; they do not independently prove private operations or indicate the current version.

View historical captures of the public framework

Public evidence-ingestion document distinguishing recording, transcript, requirement, implementation, and validated completion. — Evidence ingestion in the public framework

What this evidence establishes: The public framework documents distinct evidence states and requires provenance to be preserved at every transition.
What it does not establish: It does not prove ingestion or approval in private client projects, or turn machine transcription into truth.

Public runtime tree with directories for evidence, sessions, workstreams, and operational records. — Persistent Project Runtime structure

What this evidence establishes: The repository documents a persistent runtime structure with evidence, sessions, workstreams, reports, and operators beyond a README or prompt.
What it does not establish: It neither exposes nor proves the contents, configurations, or operations of private client runtimes.

Public framework README showing its version and central question about continuity in AI-assisted product work. — Public repository README

What this evidence establishes: Nelson’s public repository presents the framework proposition, the version recorded in the capture, and the central question about preserving intent, context, evidence, ownership, quality, and continuity across temporary sessions.
What it does not establish: It does not independently prove adoption or confidential client operations; the displayed version is a capture record, not a statement about the current version.

Public commit 291015 showing changes to the README and evidence-ingestion and local-transcription documentation. — Versioned evolution — commit 291015

What this evidence establishes: Commit 2910154799ed28416475a359a9ea536599f38451 records real, versioned changes to the framework and its documentation.
What it does not establish: It does not prove hosted CI PASS, productivity gains, or execution of private client operations.

Let’s structure your next product challenge

Discuss Product Design, Design Systems and AI-assisted Design Engineering around your team’s context, quality criteria and accountability.

Discuss AI consulting Explore the framework on GitHub

AI-Assisted Design Engineering Operating System

AI sessions are temporary. Product work isn’t.

I created an operating framework to connect Product Design, Design Systems and Engineering in AI-assisted workflows — with evidence, continuity and human accountability.

I’m Nelson Secco, a Senior Product Designer and UX Consultant. I turned recurring challenges in my practice into a reusable, versioned method for collaboration between professionals and AI agents.

I now use the framework as an operational baseline in real professional work, adapted to each engagement. This case presents the public method; client context and evidence remain private.

The cost of starting over in every conversation

Product work spans days, decisions and tools. When context lives only in a chat, the professional has to reconstruct previous agreements before continuing.

Repeated instructions and decisions lost between sessions.
Conflicting sources and assumptions that begin to pass as facts.
Changes that drift from approved behavior or duplicate the Design System.
Unclear responsibilities and uncertainty about what is complete and what still needs review.

From experiments to a reusable method

Progress meant designing how work continues, who decides and which sources support each action. Three design decisions underpin that transition.

Separate rules, context and state
Keep stable principles in the framework, context within the project and a record of where to resume. Each new session encounters distinct responsibilities rather than one overloaded prompt.
Design for continuity
Organize workstreams, sessions and decisions in persistent records. The next agent must reconcile those records with primary sources and the current artifact before acting.
Evolve against explicit criteria
Version the method, define permissions and establish validation and closure criteria. Framework improvements require a separate assessment before adoption in each project.

Read the design rationale in the public repository

One method, three responsibilities

The framework governs the work. The runtime preserves each project’s state. The session executes a bounded task. People remain accountable for decisions.

Operating framework: Generic collaboration rules covering evidence, scope, permissions, quality and continuity. This is the public, reusable layer.
Project runtime: Persistent records of objectives, decisions, references and next steps. Workstreams organize ongoing work; sessions record each period of execution. Real context stays within the project’s authorized environment.
AI session: Agents inspect, propose and execute within permitted scope. At session end, they record what changed, what was verified and how to continue.

Primary sources: Requirements and approvals retain their provenance. The runtime preserves references and context without replacing the evidence.
Canonical Design System: Approved components, tokens and patterns guide composition. Shared changes require impact assessment and explicit ownership.
Current artifact: The interface, design file or code shows the actual state. Earlier reports must be reconciled with that state.

Generic example: before changing a component, check the approved reference, inspect the current instance, establish who may modify it and record validation where the change belongs.

Explore the public runtime structure

Autonomy with human accountability

AI extends the capacity for analysis and execution. Product direction, interpretation of approvals and final accountability remain human responsibilities.

Human accountability: People define objectives, assess consequences and approve product decisions.
Evidence before inference: Verifiable primary evidence takes precedence over a convenient interpretation.
FACT ≠ INFERENCE ≠ ASSUMPTION: Separate observations, interpretations and what still needs confirmation.
PARITY BEFORE UX EVOLUTION: Preserve approved behavior before proposing changes to the experience.
REUSE → COMPOSE → EVOLVE → CREATE: Inspect and reuse the canonical foundation before creating new patterns.
Change ownership: The owner of the changed file or artifact also maintains its change record.
Persistent continuity: Objectives, decisions and next steps must outlast the conversation’s temporary memory.
Risk-proportionate validation: Run necessary checks and reuse still-valid evidence while preserving mandatory acceptance criteria.
Explicit completion criteria: Define acceptance before testing and distinguish execution, evidence and human approval.

Explore the path from source to completion

A transcript helps recover a conversation. Progressing to requirements, implementation and completion requires review and evidence at each transition.

Recording
recording ≠ transcript
Transcript
transcript ≠ approved requirement
Approved requirement
approved requirement ≠ implementation
Implementation
implementation ≠ validated completion
Validated completion

From methodology to professional practice

I use the framework as an operational baseline in professional practice, adapting governance, tools and confidentiality safeguards to each engagement.

The public method provides reusable principles and contracts.
Project configuration defines authorized sources, the Design System, responsibilities and execution boundaries.
Professional execution applies these criteria to concrete tasks through inspection, review and validation.

Professional use is reported by the author. This case does not present client data, interfaces or results as public evidence.

Explore a generic workflow

This sequence is a generic demonstration derived from public documentation, rather than a depiction of a client engagement.

Context

Define the objective
Bound the scope
Locate sources

Evidence and decisions

Review evidence
Record decisions
Analyze Product and UX

Design and execution

Inspect the artifact
Compose with the Design System
Execute within authorized scope

Validation and continuity

Validate acceptance criteria
Review with accountable people
Record the next step

What has been built — and what still needs evidence

The public outcome is a versioned framework that makes collaboration rules, continuity structures and execution boundaries explicit.

Publicly inspectable: The method, runtime architecture, contracts and release history can be examined in the public repository.
Reported by the author: Use as an operational baseline in real professional work, adapted to each context. Public documentation does not independently establish private operations.
Benefits to measure: Reducing rework, restart effort and inconsistency is an objective of the method. This case presents no comparative measurement of productivity or general agent effectiveness.

Limitations that guide further development

Recovered context can be incomplete or outdated. Resuming work requires checking applicable sources and reconciling state before changing an artifact.
Conversation, documentation and artifacts can diverge. Records preserve intent; inspection establishes the current implementation.
Rechecking everything at every step adds cost without necessarily changing a decision. Prior criteria and still-valid evidence help define when to stop.
Unbounded autonomy leaves responsibilities unclear. Scope, permissions and ownership must precede execution.
Passing tests support only what was checked. They do not constitute human approval or, on their own, demonstrate agent effectiveness.

Read the public validation and closure contract

A public framework that continues to evolve

The method remains experimental and evolving. Documentation, decisions and releases show what has been published and what is still under development.

Published release: v3.9.0, dated October 24, 2026. It adds three optional read-only helpers for source delivery, action-report consistency and supervised work cycles.

Read the v3.9.0 release

View the later source snapshot

Next steps: refine the rules against verifiable limitations and broaden independent evaluation. New hypotheses need evidence before they can be presented as outcomes.

Follow the release history

The captures below are historical records. They establish the existence of documentation at the captured revisions; they do not independently prove private operations or indicate the current version.

View historical captures of the public framework

What this evidence establishes: The public framework documents distinct evidence states and requires provenance to be preserved at every transition.
What it does not establish: It does not prove ingestion or approval in private client projects, or turn machine transcription into truth.

What this evidence establishes: The repository documents a persistent runtime structure with evidence, sessions, workstreams, reports, and operators beyond a README or prompt.
What it does not establish: It neither exposes nor proves the contents, configurations, or operations of private client runtimes.

What this evidence establishes: Nelson’s public repository presents the framework proposition, the version recorded in the capture, and the central question about preserving intent, context, evidence, ownership, quality, and continuity across temporary sessions.
What it does not establish: It does not independently prove adoption or confidential client operations; the displayed version is a capture record, not a statement about the current version.

What this evidence establishes: Commit 2910154799ed28416475a359a9ea536599f38451 records real, versioned changes to the framework and its documentation.
What it does not establish: It does not prove hosted CI PASS, productivity gains, or execution of private client operations.

Let’s structure your next product challenge

Discuss Product Design, Design Systems and AI-assisted Design Engineering around your team’s context, quality criteria and accountability.

Discuss AI consulting Explore the framework on GitHub

Separate rules, context and state

Design for continuity

Evolve against explicit criteria

Limitations that guide further development

Separate rules, context and state

Design for continuity

Evolve against explicit criteria

Limitations that guide further development