Practitioner

The methodology was originated and is operated by Accion Labs. This section is the only part of the site where Accion Labs is the subject rather than the operator behind the methodology.

The relationship between the methodology and its primary practitioner matters. Semantic Engineering is proprietary to Accion Labs. The framework, principles, and concepts are public. The methodology mark is reserved. Accion Labs holds the copyright. We operate the methodology across more than two hundred enterprise clients.

Our claim to operate the methodology rests on three things. The firm originated the framework that became the methodology’s role-governance backbone (the 2017 Breeze framework) and the discovery that made the methodology viable at AI scale (the 2022 drug discovery hallucination problem and the knowledge-graph constraint response). We have spent years operationalizing the methodology across enterprise SDLC engagements. We have built the platforms that implement the methodology in production, with the principal platform (Breeze.AI) carrying the name of its 2017 ancestor.

What This Section Contains

The Two-Day Deep-Dive Workshop

The standard entry point into a commercial engagement with us.

The workshop requires no infrastructure change, no system access beyond what is already in place, and no commitment beyond the workshop itself.

Why Accion Labs as the Enabler

The Enablement Partnership frames our role over multi-year engagements as enabling partner rather than vendor or custodian. The client’s four custodians own the knowledge asset; we provide customization, setup, and managed support under codified engagement principles. The enablement relationship operates under explicit firewalls when we enable the same methodology for competing clients. The offboarding doctrine makes the exit real, which is what makes the entry decision easy.

This is the relational frame we propose for engagements that exceed the workshop or the initial twelve-week foundation.

What This Section Does Not Cover

This section is about Accion Labs as the methodology’s operator. It does not advocate for the methodology. The methodology advocacy is in The Manual Translation Tax, Zones of AI-Assisted SDLC, and The Methodology. Readers who want the case for the methodology should start there. Readers who have decided the methodology is what they need, and are evaluating Accion Labs as the partner to operate it, will find what they need in this section.

About Accion Labs

Accion Labs is the AI-first, platform-led innovation engineering company that originated and operates the Semantic Engineering methodology.

Company at a Glance

AI Evolution Timeline

The methodology has two roots that converged. The 2017 Breeze framework codified the minimal governance structure that good product owners, architects, and UX designers needed to produce. The first GenAI project in 2022 (drug discovery for a pharma leader, started Q1 and deployed Q3) produced the structural insight that constraining a transformer model with a knowledge graph turns confident hallucination into precise, traceable output. In 2023 that insight was productized as KAPS, our Knowledge and Analytics Platform, and the KG-grounded approach moved into commercial use across customer engagements while the discipline was still unnamed. By 2024 the 2017 Breeze guidelines had been converted into the four-layer ontologies, the agent fleets that operate on them had been built, and the SDLC platform took the name of its 2017 ancestor: Breeze.AI. The discipline took the name Semantic Engineering in 2025. The full origin narrative is in Origins.

Core Capabilities

Our six core capabilities together support the full Semantic Engineering engagement.

The AI Operating Model

Our internal operating model for AI engagements has six elements that align to the Semantic Engineering methodology.

The full platform descriptions are in Platforms below.

What Accion Labs Brings to a Semantic Engineering Engagement

Why Accion Labs Is the Methodology’s Home

Three things give us the credible claim to operate the methodology as its primary practitioner.

Origination. The methodology came out of our work. The 2017 Breeze framework that codified the role-level governance discipline, the 2022 drug discovery moment that produced the knowledge graph constraint pattern, the formalization of the four-layer ontology, the development of the agent fleet patterns, the codification of the enablement partnership, all happened inside the firm. The Breeze.AI platform that now operationalizes the methodology carries the name of its 2017 ancestor.

Operational depth. Hundreds of engagements have refined the methodology against real client conditions. The patterns that survived are the ones that worked. The patterns that failed have been removed. The result is hardened against the actual failure modes of enterprise software delivery.

Continuous investment. The methodology is not frozen. The platforms (Breeze.AI, ASIMOV, ECL, KAPS, SPEX, Semantic KG) are under active development. The custodianship discipline is being formalized into legal templates and operational playbooks. The Forward-Deployed Engineer program is being built into a named offering. The methodology evolves with the practice.

Platforms

The technical implementations we bring to a Semantic Engineering engagement. Each platform operationalizes a specific element of the methodology. The platforms are listed in the order they typically engage on a client project.

Other Accion Labs Platforms Referenced in the Methodology

Beyond the two SDLC-focused platforms above, several other platforms appear in the broader context. They are not the focus of this site but are referenced where relevant.

How the Platforms Map to the Methodology

The Breeze.AI platform is the canonical implementation of the methodology. A client adopting Semantic Engineering for an SDLC engagement is adopting Breeze.AI as the foundation. ASIMOV is a specialized extension for engagements where the trigger is migration from a legacy stack.

Deployment Options

The deployment model is decided during the Advise phase of the engagement. The Five-Year TCO reduction of approximately 81% for the on-premises model is one of the methodology’s stronger AI Economics arguments.

Detailed Treatment

The depth coverage of each platform lives on its own page.

• Breeze.AI covers heritage of the name, what Breeze.AI implements per methodology element, deployment architecture, integration surface, operational maturity, and engagement lifecycle.
• ASIMOV covers what ASIMOV does end-to-end, supported migration paths, operational track record, how it relates to Breeze.AI, when it is the right platform, and the engagement pattern.

Engagement Models

We offer two distinct engagement models, one per use case. Continuous software engineering engagements run on a four-phase model (Advise, Launch, Scale, Optimize) shaped for ongoing custodianship over years. Legacy modernization engagements run on a five-mode model shaped for a bounded project with a defined target.

The two engagement models do not overlap during an engagement. A client engagement that includes both modernization and ongoing SDLC governance uses the modernization model for the bounded migration project and then transitions to the continuous SDLC model once the modernized system is in live operation, at the hand-over from the Maintain mode.

The full treatment of each model is on its own page:

• SDLC Engagement Model: four phases with activities, participants, deliverables, managed-support-tier mappings, and pricing per phase.
• Modernization Engagement Model: five engagement modes with deliverables, durations, pricing per mode, and the comparison to the SDLC phases.

Continuous SDLC Engagement Model

The continuous SDLC engagement model has four phases. The full treatment is on the SDLC Engagement Model page. A short reminder follows.

Legacy Modernization Engagement Model

The legacy modernization engagement model has five entry modes. The full treatment is on the Modernization Engagement Model page. A short reminder follows.

Three-Phase Rollout

The Advise / Launch / Scale / Optimize engagement model above describes the commercial shape of the engagement. The Three-Phase Rollout describes the methodology phases inside it. The two are aligned: Advise runs alongside Phase 1, Launch covers Phase 2, Scale covers Phase 3.

The methodology is rolled out in weeks. The operating model that delivers the full value is a change-management exercise that runs across quarters. Both are real, both worth doing, and the two are not the same effort.

Phase 1: SDD Adoption

Duration. Four to six sprints.

Objective. Establish Spec-Driven Development as the team’s operating standard. Make the spec a hard gate before sprint planning. Instrument traceability in the ticket system. Add CI-based drift detection. Reach a sustainable Zone 2 operating model.

Deliverables. Spec template adopted across the team, spec authorship cadence integrated into sprint planning, CI configuration for drift detection in place, ticket-system traceability instrumented, first sprint operating fully under the new discipline.

Phase-gate criteria. Every change of meaningful size has a written spec before implementation begins; defect rate improvement against the pre-adoption baseline is measurable; team has stopped resisting the discipline and has incorporated it into normal workflow.

Team composition. Existing implementation team, Product Owner with sharpened spec-authorship discipline, Tech Lead overseeing CI integration.

No infrastructure change required. No platform investment required. The phase is primarily a discipline change.

Phase 2: SE Foundation

Duration. About twelve weeks.

Objective. Build the four-layer knowledge graph for the highest-priority product or workstream. Deploy the Impact Analysis Agent. Establish the validation gate at PR merge. Reach a sustainable Zone 3 operating model for the first workstream.

Deliverables. Functional Ontology built from the ratified feature matrix, or extracted from existing code in brownfield scenarios; Architecture Ontology built from the bounded-context decomposition; Code Ontology extracted, with auto-update on every PR merge; Design Ontology built from the existing component library, and from Figma if applicable; cross-layer relationships established; Impact Analysis Agent deployed in pre-implementation mode; PR Validation Agent deployed; KG Sync Agent deployed; verification suite running on every merge.

Phase-gate criteria. All four ontologies pass the P0 verification suite; the Impact Analysis Agent runs successfully against real specs; the PR Validation Agent has caught at least one cross-team conflict before integration; the team uses the impact report routinely as part of spec review.

Team composition. The implementation team plus the first Forward-Deployed Engineer or substitute pattern; supporting specialists engage on the schedule the workstream needs them (Semantic Engineer heavily loaded during this phase, Agent Developer, Data Architect); the Enablement Layer begins to form (Chief Architect role identified, Ontology Maintainer role identified).

For brownfield scenarios, the full reverse-engineering extraction on the existing code base captures actual behavior before the team starts modifying. Brownfield extraction at 2M+ LOC typically completes in two to three weeks. The remaining nine to ten weeks of Phase 2 are spent on validation, agent deployment, and operating-model integration.

For greenfield scenarios, the team can begin building the Functional Ontology from Day 1, and the Code Ontology accumulates as the team writes code.

Phase 3: SE at Scale

Duration. Quarters to years, depending on product count and custodial maturity.

Objective. Extend the methodology across the portfolio. Deploy progressive autonomy on pattern-based work. Establish the enablement partnership as the operating mode. Reach Zone 4 across the engagement.

Deliverables. The four-layer graph extended to additional products; Cross-Product Impact Extension agents deployed; Portfolio Rationalization Agent running on a quarterly cadence; progressive autonomy levels assigned per agent class; enablement engagement in place with named owners for each ontology category; Engagement Council established for cross-engagement governance when Accion Labs is operating multiple competing-client engagements; offboarding doctrine documented and contractually binding; BDD scenarios auto-generated from the Functional Ontology at production scale.

Phase-gate criteria. The methodology is operating across the products that matter to the enterprise; the enablement partnership is producing measurable health metrics on a continuous basis; the enablement contract is in place with the client; the team can sustainably operate the methodology without continuous Accion Labs presence.

Team composition. Layered team structure in full operation (Enablement Layer plus Forward-Deployed Engineers plus Implementation Teams); spec sprints running on the cadence appropriate to each workstream; fractional allocation engaged at trigger points across the portfolio.

This phase has no fixed end. It is an operating mode. The enablement engagement continues as long as the client wants Accion Labs to enable the custodianship of the knowledge asset.

Two Paths Through Phase 2

Phase 2 takes different shapes depending on whether the engagement is brownfield or greenfield.

Brownfield path: Foundation, Evolution, Semantic First

Greenfield path: Spec Sprints From Day 1

For greenfield engagements, the team can replace the conventional MVP with Spec Sprints as the entry point. Instead of building an MVP where the deliverable is working code, the team runs Spec Sprints where the deliverable is a stable semantic model. Any code produced during Spec Sprints exists solely to validate the model.

After four Spec Sprints, the team enters the Evolution sub-phase with a validated semantic model in place. The remaining eight weeks of Phase 2 unfold as in the brownfield path.

The Spec Sprint pattern is most valuable when there is no existing dev team to retrain, no existing codebase to extract from, and the organization wants to reach Zone 3 productivity as quickly as possible.

The Migration First Path

For engagements where the trigger is legacy modernization (replacing a legacy system entirely rather than evolving an existing one), the Migration First pattern uses the migration itself as the on-ramp.

The extraction process runs against the legacy system. The four-layer graph captures the legacy system’s actual behavior. The graph then becomes the specification for the modern system. The implementation team builds against the graph. The methodology is in place from Day 1 of the modern system.

This is the pattern we use for ASIMOV-based legacy modernization engagements.

Expected Outcomes

Validated outcomes from active and completed engagements operating under the three-phase rollout.

• 93.4% test coverage with zero manual BDD overhead (Functional Ontology generates the scenarios)
• 23% defect rate reduction against pre-SE baseline on the same code base
• 53% design component reuse in the first sprint of SE-governed development
• 40% reduction in technical debt in portfolio rationalization engagements
• 40% to 60% cost reduction versus manual approaches for legacy modernization at scale
• 80% to 85%+ automated test coverage achieved on migrated code bases

Phase 3 Adoption Considerations

Phase 3 takes quarters to years. Most teams that complete Phase 2 successfully do not move into Phase 3 immediately. They run at Zone 3, with a single product operating under SE, for several quarters before extending to additional products. This is the right pace. Premature extension to additional products without the enablement partnership in place produces graphs that degrade and a team that loses confidence in the methodology.

Engineering leaders should expect Phase 3 to be a multi-year arc, with each additional product or workstream taking three to six months to bring under SE governance, and the enablement partnership maturing in parallel.

Services

The catalogue of named offers we bring to a Semantic Engineering engagement. Each service maps to a phase of the engagement model and a tier of the enablement partnership.

Workshops

Two-Day Semantic Engineering Deep Dive. The standard entry point. The workshop produces a diagnostic of the team’s current zone, an initial Functional Ontology draft for the highest-priority capability domain, and a scoped twelve-week SE Foundation roadmap.

The workshop requires no infrastructure change, no system access beyond what is already in place, and no commitment beyond the workshop itself.

One-Day Architecture Briefing. For client leadership teams that want to understand the methodology without the depth of the two-day workshop.

Assessments

Maturity Diagnostic. A more detailed version of the workshop’s zone diagnostic, run as a four-week engagement.

The Maturity Diagnostic is the right offering for clients who want a deeper analysis than the workshop produces before committing to a Launch phase.

Brownfield Extraction Assessment. For clients considering Semantic Engineering for an existing large code base. Six-week engagement.

The output is the answer to “what would Semantic Engineering find in our code base, and what would the engagement look like?”

Enablement Tiers

See The Enablement Partnership for the full treatment.

The Enablement Layer and the Wider Specialist Pool

The Enablement Layer (the bottom layer of the layered team structure) is staffed by named roles that support the client’s custodians. Additional deep specialists engage at trigger points to support the workstream. Both sets share the same staffing pattern: specialists are engaged at the moments their judgment creates value, sized to the deliverable rather than to a calendar quarter. See Fractional Allocation.

We field the specialist pool from across active client engagements. The pool model means a single specialist can support several engagements while maintaining depth on each, so each engagement gets focused expertise at the moments it needs them.

Forward-Deployed Engineer Program

A named offering distinct from the specialist pool. The FDE program backfills missing coverage in the custodianship layer of the layered team structure at the client. When the client cannot staff all four ontology custodian roles fluently, FDEs play one or more of the roles for that workstream alongside the client’s existing custodians.

The FDE program is the structural answer to the scaling question. A client adopting the methodology across a portfolio needs roughly one FDE per ten to fifteen million dollars of account revenue, or one per top-fifteen account.

How to Engage

The standard sequence is the two-day workshop, then (if the client wants deeper analysis before committing) a Maturity Diagnostic or Brownfield Extraction Assessment, then the Launch phase (Phase 2 of the three-phase rollout), then the managed support tier choice that determines the ongoing engagement shape.

See Contact to request a workshop or assessment.