Enter the access password to view the site.
The FDLC describes how features get built. The work below is the platform that makes that workflow possible. Constitutions, companion files, tooling stack, governance cadences, and enablement infrastructure. These don't ship with a feature. They're what every feature is built against.
Agents operating without a defined set of rules produce plausible outputs that subtly violate constraints. The context layer is a three-stream infrastructure (design, platform, engineering) that converges at generation time. Companion files extend it with domain-specific context the team owns.
The rule set agents use at generation time for design output. Accessibility floors, design system coverage, UX standards, and visual contract enforcement. The first thing any design-generating agent loads.
Layout-sensitive and multi-domain composition rules. Used where features span product surfaces or where composition correctness matters beyond a single domain's design system.
Quality, security, architecture, and service contract rules. Loaded with every code-generating run. The reason AI-generated code can be reviewed against a stable target rather than judged in isolation.
Cross-domain API contracts, integration event standards, and shared service patterns. Held in the deferred register until pilot signal confirms what platform-level rules need to be enforced at generation time.
Constitutions are org-wide. Companion files are how each domain extends them with the specifics agents need to generate good output: the data shapes, the state list, the design intent, the spec sufficiency bar. Authored at the domain level, refreshed continuously.
Domain-specific design context, layered on top of the Textura design constitution. Maintained by the domain design lead. Stale companion files are a leading indicator of generation quality decline.
Domain-specific engineering context: data shapes, state machines, service hooks, recurring patterns. Authored by the domain engineering lead. Used in every per-unit-of-work generation in that domain.
Defines spec sufficiency standards by feature type. The minimum viable spec is different for a small UX refinement vs. a new service integration; the guide makes that explicit so PMs are not guessing the bar.
Staleness is monitored, not just authored once. The DS Team and per-domain leads watch for drift between companion files and shipping reality. Context quality is the generation quality ceiling.
Teams operate the same workflow against two different tool tracks. The choice depends on workload, context-loading depth, and cost-per-outcome signal. Track A is widely available today; Track B is the path we are licensing for.
Used with explicit context loading, constitution grounding, and the four mandatory human checkpoints. The lowest-friction track for teams already operating on the GitHub stack.
For deeper context loading, multi-step agentic work, and constitution-enforced generation across larger units of work. Requires CI/CD pipeline setup and a token budget governance model owned by EngOps.
The agent landscape is the set of horizontal agent capabilities the org maintains beyond per-feature work. Some are live, some are gated on pilot signal, some sit in the deferred register pending evidence that the work is real.
Continuous customer signal: call recordings, escalation patterns, behavioral telemetry, synthesized into briefs PM dispositions at Brief (G0).
Live component and token state at generation time. The bridge between the design constitution and what the agent can actually compose against.
Flags drift between shipped behavior and published documentation. Lets TC focus on drafting and judgment, not change detection.
Ten items are deliberately held until pilot signal proves the work is needed. Activation is gated on evidence, not enthusiasm. A sample of the register:
Constitution amendments, pattern compounding, and workflow calibration all need signal from deliberate practice. Four standing cadences turn what teams see into decisions that flow back down. Monthly during pilot and active rollout, quarterly at scale.
Pod-owned, per-domain review of in-flight capture: friction patterns, generation quality signals, gate exit data. Feeds the AI FDLC Review with domain-grounded evidence.
DS Team lead. Approves pattern promotions from feature-level candidates into the design system; ratifies constitution amendment candidates surfaced during Build.
Cross-domain contract issues, deferred register activations, engineering constitution amendments. Engages on triggers, not on a fixed schedule of every feature.
Central, cross-functional decision and ratification body. Advancement decisions, rollout calibration, constitution amendments, sequencing for new teams. The signal loop closes here.
Embedded in gate checklists, not a separate task. Cycle time, rework rate, handoff clarification burden, implementation fidelity, cost-per-outcome by track.
What the AI FDLC Review produces: advancement decision, team sequencing model (by readiness, not seniority), updated cost governance, ratified amendments.
If the workflow is the road, the enablement layer is what teams need so they can actually drive it: prompt libraries, onboarding paths, templates, and sequencing logic that treats readiness as the variable, not seniority or priority.
Role-based starting points: spec drafting, AC generation, variant generation, code review, test scaffolding. Curated, versioned, and shared across the org rather than re-invented per team.
Setup lift lands in teams (repo provisioning, tooling, system access). The guides exist so the lift is small and predictable, not an exploration project.
Templates for the artifacts that drive generation. PM spec template by feature type, design constitution scaffolding, engineering companion file shape.
Defines which teams onboard first, based on readiness criteria (companion files ready, spec sufficiency demonstrated, leadership support). Set by the calibration package, not pre-committed.
Practitioner-facing documentation of the workflow, co-authored by TC and the AI working group. This site is one entry point; the deeper reference lives alongside it.
Cross-org working group that surfaces friction, recommends adjustments, and feeds survey signal into the AI FDLC Review. Open contributor model.
The FDLC isn't a static document handed down from a working group. Teams running it daily see friction, gaps, and opportunities first. The contribution loop turns those local experiments into ratified amendments that ship to everyone.
Pods can pilot variations — a new prompt shape, an adjusted gate threshold, a companion file format, a different review cadence — inside their own domain. No central approval needed to try something for a sprint or two.
Document what changed, what it replaced, and what shifted: cycle time, rework rate, generation quality, gate exit data, friction patterns. Evidence is what separates a proposal from an opinion.
Route the proposal to the AI Ways of Working group for shaping, then to the AI FDLC Review for ratification. Constitution amendments, workflow changes, and new templates all flow through the same standing cadence.
Ratified amendments update the constitutions, companion templates, or workflow definitions. The change is versioned, dated, and announced — so every team picks it up the same way features ship to customers.
Companion references that go beyond what fits on this page. Each one is a focused deep-dive on a specific facet of the AI-enhanced workflow — the activity matrix, the agent inventory, cost discipline, a worked example, and the year-long rollout plan.
Per-phase activity matrix mapping who owns each task and which mode applies, plus structured prompt templates for the most common design tasks.
OpenThe full agent inventory across phases: what each agent does, what it doesn't, infrastructure requirements, escalation paths, and priority ranking.
OpenModel routing, context architecture, prompt caching, anomaly monitoring, and governance discipline for keeping AI tooling cost predictable at scale.
OpenAn end-to-end worked example: one feature traced from signal through release. Gate decisions, agent handoffs, RACI matrices, and the artefacts they produce.
OpenQuarter-by-quarter rollout, RACI shifts as the workflow matures, the spec-first → spec-anchored architecture transition, and the maturity model.
Open