AEDF v1.0.0 — From Governance Framework to Production Baseline

I — The engineering problem

Engineering work rarely fails because one artifact is missing. It fails when artifacts stop agreeing. Requirements can drift from architecture; implementation can outrun its work order; automation can report success without validating the intended source; evidence can lose its provenance; security constraints can disappear between design and release; and a technically correct change can still lack human acceptance.

AEDF treats those relationships as one controlled lifecycle rather than a pile of adjacent documents:

1. 01IntentDefine the outcome and authority.
2. 02Work OrderBound scope, risk, and acceptance.
3. 03Controlled ChangeImplement against repository truth.
4. 04ValidationTest framework and adopter contracts.
5. 05EvidencePreserve reproducible results.
6. 06ReviewKeep technical and product gates explicit.
7. 07ReleaseDeliver only under recorded authority.

The sequence is not paperwork wrapped around engineering. Each transition answers a different question: what is authorized, what changed, what was tested, what the evidence supports, who accepted it, and which exact state was released.

II — Governance as executable infrastructure

AEDF supplies the shared governance contract: authority roles, risk classes, lifecycle gates, work-order expectations, evidence requirements, exception handling, and validation semantics. An adopter supplies the repository-specific reality: architecture, controlled source scope, project policy, build and test commands, runtime model, and release mechanism.

AEDF

Defines how an engineering change becomes reviewable, validated, authorized, and traceable.

Adopter

Defines what the product is, which source is controlled, how it is built, and what correct behavior means.

This separation is the portability boundary. AEDF does not prescribe Astro, Python, TypeScript, desktop packaging, APIs, static hosting, or an agent runtime. It requires the adopter to declare those facts and then evaluates delivery against that declared contract.

Source scope became a release-candidate issue

Early qualification exposed that “the repository source” was too ambiguous for a reusable validator. Different products place authored runtime inputs in different roots, and scanning either too little or an inferred directory could produce evidence about the wrong surface.

The stable contract therefore makes controlled source roots explicit. Validation fails when a required root is missing, malformed, overlapping in an invalid way, or resolves outside the adopter through path traversal. Repository-wide controls—such as governance files and change-range whitespace checks—remain repository-wide rather than disappearing merely because application source is scoped.

This is a validation boundary, not a claim that source-root checks replace a complete security review or secret-scanning program.

III — Stable framework delivery

The stable delivery model is GitHub-native. Each adopter pins an immutable AEDF version reference and invokes the framework-owned validation at that protected version. The running framework can therefore identify its own provenance while validating the adopter's repository policy and declared source roots.

The adopter does not maintain a repository-specific validator fork, perform a second private framework checkout during validation, or retain a long-lived cross-repository credential. The workflow needs only the permissions required to read the adopting repository and execute the pinned validation path. That reduces credential and supply-chain surface without pretending that an immutable reference alone solves every provenance concern.

IV — Two qualified adopters

The release evidence came from systems whose architecture, toolchain, and delivery concerns are materially different.

Avantlord Website

An Astro, static-first, content-oriented, localization-aware website with typed collections, web build validation, and Cloudflare Workers Static Assets delivery.

ProjectOS

A Python and TypeScript local-first product with application and API boundaries, a Windows desktop package, PyInstaller executable and installer build, plus an evolving agentic execution architecture.

One adopter emphasized content graphs, paired language surfaces, metadata, static routes, and web packaging. The other emphasized application boundaries, local state, cross-language implementation, executable packaging, installer construction, and human-controlled agent orchestration. Both retained their own architecture while satisfying the same framework semantics.

AEDF v1.0.0 demonstrated portability across two materially different engineering architectures without requiring framework forks, repository-specific validators, or semantic workarounds.

That is evidence of bounded portability, not universal compatibility. A new adopter may expose a new assumption and require the framework to evolve through the same controlled process.

V — Release decisions follow evidence

RC4 corrected framework provenance and then passed qualification in both adopters. The release-readiness question was not whether another candidate number was available; it was whether a material unresolved defect or untested release claim remained.

1. RC4
   Qualification

   The website and ProjectOS passed the same framework-owned semantics across different architectures.

2. Review
   Release readiness

   The evidence and remaining boundaries were evaluated explicitly.

3. 1.0
   Stable release

   The qualified candidate was promoted without an evidence-free RC5 ceremony.

4. Use
   Consumer validation

   Both adopters validated the immutable stable reference and transitioned to it.

The sequence was: RC4 qualification → two successful adopters → release-readiness review → v1.0.0 → stable consumer validation → adopter transitions. RC5 was not created because no further candidate change was needed to establish the approved release claim.

Release decisions should follow evidence, not ceremony.

VI — Production governance baseline

AEDF v1.0.0 is now the production governance baseline for applicable Avantlord engineering projects. It standardizes the delivery contract while leaving technical architecture with each adopter.

Work-order delivery

Consequential work begins with bounded intent, scope, risk, and acceptance.

Explicit authority

Architecture review, product acceptance, merge, and release remain distinct decisions.

Repository policy

Each adopter records its architecture, validation, and runtime obligations.

Source-scope validation

Controlled roots are explicit, validated, and resistant to traversal outside the adopter.

Immutable provenance

Adopters bind validation to a protected stable framework reference.

Evidence-backed delivery

Tests, builds, packaging, and post-merge results remain connected to the released state.

Exception handling

Departures require visible authority instead of silent weakening.

Human release gates

Automation informs approval; it does not assume it.

Bounded future direction

Signed tags, release attestations, and stronger required-check enforcement where platform capabilities permit are reasonable hardening paths. They are additive opportunities, not evidence that the current stable contract is incomplete for its approved scope.

1. 01Human intentOutcome, priority, and acceptance
2. 02AEDF v1.0.0Authority, lifecycle, evidence, and release contract
3. 03Adopter policyArchitecture, source scope, tests, and runtime
4. 04Controlled deliveryReviewed change and immutable evidence
5. 05ProductionThe exact authorized adopter state