Process
How we deliver.
An Agile approach with SAFe practices, run daily on our own platforms. This page is not a methodology slide: every practice below is how Edgent builds the software we operate in production, and the live systems linked at the bottom are the proof.
The path a feature travels
Every feature follows the same defined route from request to running software. Domain modeling happens early, so by the time work is planned, the domain events are already fixed.
Intake
A feature arrives as a tracked item before any work starts. Nothing is built from a hallway conversation.
Architecture triage
The feature is triaged against the current architecture for gaps: what it touches, what it strains, what must exist first.
Analysis plan
A written analysis plan, versioned beside the code it governs and reviewed like code. The plan is the record, not a slide.
Detailed requirements, tests included
Acceptance criteria are written as human-readable Gherkin scenarios. The requirement and its test are one artifact — the scenarios later execute byte-for-byte in the pipeline.
Program-increment planning
Work is broken into the smallest independently shippable units, one tracked item per unit, sequenced on a dependency graph. Completion is a recorded state transition, never a reported percentage.
Built into the domain
Event Storming has already fixed the domain events by this point, so each behavior a requirement defines carries a single responsibility and is built into the aggregate that owns it. Requirement, test, and domain model stay one chain.
Domain-first engineering
Event Storming
Discovery includes Event Storming — Alberto Brandolini's group-modeling method for domain-driven design. Domain experts and engineers model the business as a timeline of domain events. Because we build event-sourced systems, a session's output of events, commands, and aggregates carries into the delivered architecture without an intermediate translation.
Strategic design
Bounded contexts are defined up front; behaviors and the domain events their outcomes raise are modeled explicitly; event interaction is mapped inside the domain and across domain boundaries; the estate is classified into core, supporting, and generic domains and their subdomains, so investment follows the domain that differentiates.
Gates: full automation, humans at the decisions
The pipeline is fully automated end to end, with human-in-the-loop gates at the points where judgment belongs. Machines block on evidence; people decide direction and release. Every automated gate is written so it can actually fail — no step is allowed to swallow its own errors.
Automated gates — blocking
- Build and the full test suites — more than 16,000 named automated tests across our platforms
- Acceptance scenarios executed byte-for-byte from the Gherkin feature files, in strict mode
- Static analysis against a reviewed baseline — a new finding fails, the accepted set stays quiet
- Dependency and supply-chain scanning across the whole dependency tree
- Secret scanning on the working tree and on every pull-request diff, with push protection
- Container scanning of both the base image and the built payload
- A software bill of materials, generated twice in the same run and diffed to prove it is reproducible
- A blocking accessibility gate: an axe scan with no tag filter, no disabled rules, and no suppression list
- Deployment accepts only a content digest — the tested artifact is the deployed artifact, never a tag
Human-in-the-loop gates — blocking
- The analysis plan is reviewed and approved before construction begins
- Every change is a pull request reviewed by an engineer who did not write it
- Promotion toward production requires two approvals, with stale reviews dismissed when the code changes
- The release itself is the product owner's decision — the automation prepares everything and then waits for a human
Between the gates there is no manual step: build, test, scan, package, and deploy run without a human touching them, and increments travel the same pipeline that carries the final release. Releases are blue/green with the prior version retained, so rollback is a decision, not a project.
Roadmaps and timelines
The roadmap is a dependency graph
- Work is planned as dependency-ordered lanes, not a date list — the graph is the capacity plan
- A lane does not start before its predecessor completes, so a slip is visible at the lane boundary
- Shared repair work is pulled forward once rather than repeated in every lane that reads the same seam
- Reallocation moves named units of work, never percentages
Timelines you can hold us to
Lane durations are committed at standard engineering rates rather than at our own measured cadence, which runs faster. The difference is held as schedule margin — the timeline an agency signs is one we expect to beat, not one we hope to meet.
Practiced, not proposed
The team carries PMP and PMI-ACP certification, SAFe practice, and Scrum and Kanban delivery experience — and works in the agency's own toolchain, whether that is Jira, Azure DevOps Boards, or something else. A vendor that can only report progress in its own system is a vendor whose status must be transcribed.
See it running
This process builds the systems you can open right now: the live platform demo, a public transparency dashboard built for a real solicitation, and runnable examples of how we build — including the accessibility-gated CI — at github.com/edgentx/code-examples.
If you want this process on your program, see the capability statement or get in touch.