Studio

Human-led. AI-augmented.

DoricDev is a personal software studio — not a consultancy, agency or multi-person team. Human judgement retains product direction, risk, merge, operationalisation and release authority. AI and engineering tools augment Product Authority, Repository Engineering and GitHub evidence; they do not own decisions.

See the Operating ModelSee Studio capabilities

DoricDev Operating Model v1.0 — current authority

How Platform, Studio, products, operationalisation and authority fit together.

This is the controlling explanation of DoricDev. It does not reproduce the full DoricDev Operating Model document; it makes the relationships that matter for a first-time visitor clear at a glance.

  1. DoricDev is a personal software studio.

    One studio uses a shared Platform to develop useful products.

  2. The Platform supplies shared foundations.

    Standards, boundaries, design tokens and certified assets are built once so products stay coherent.

  3. The Studio identifies problems, develops products and proves value.

    The Studio develops products and proves value. The Human Product Owner decides which remain prototypes and which are nominated for operationalisation.

  4. Products follow one reusable lifecycle.

    Development, Access Preview, General Availability, Maintenance and Archived — see the lifecycle below.

  5. Operationalisation is a separate branch, not a lifecycle stage.

    A deliberate Product Owner decision leads to an Operational Candidate, an accepted Operational Solution Architecture, bounded engineering and assurance, and separate Operational Release, Data Gate and activation decisions.

  6. Authority stays distinct by role.

    Human Product Owner authority remains separate from Product Authority, Repository Engineering and GitHub evidence ownership.

  7. GitHub is the durable engineering source and evidence record.

    Issues, branches, pull requests and CI evidence hold the accepted objective, the implementation and its outcome.

Product lifecycle

  1. Development
  2. Access Preview
  3. General Availability
  4. Maintenance
  5. Archived

Operationalisation — a separate branch, not a lifecycle stage

  1. Product Owner decision
  2. Operational Candidate
  3. Accepted Operational Solution Architecture
  4. Bounded engineering and assurance
  5. Separate Operational Release, Data Gate and activation decisions
  6. Operational Instance
Authority by role
RoleOwns
Human — Product OwnerDirection, operationalisation, risk, merge and release authority.
Product Authority and ArchitectArchitecture, planning, acceptance criteria and evidence-led review — AI-assisted challenge and review, not independently attributable external assurance.
Repository EngineerBounded implementation, targeted and canonical validation, and draft pull requests.
GitHubDurable source, decisions, issues, pull requests, CI and evidence.

Studio capabilities

Capabilities the personal Studio uses, not services it sells.

Each card shows the capability status, its evidence basis and where it is referenced.

ActiveOperations

Studio Operations

studio-operations

Run bounded, evidenced delivery across Platform, Portal and product repositories under one authority model.

Value created

Keeps delivery small, reviewable and traceable to an accepted objective.

Demonstrated through

  • DoricDev Operating Model v1.0
  • Platform Portal
  • CVOS
Inspect evidence and future leverage
Evidence
Work packets, issues, draft PRs and CI evidence in GitHub across the Studio repositories.
Future leverage
Provides the operating discipline every other Studio capability depends on.
Active / Platform standardDelivery

Conversational Engineering

conversational-engineering

Coordinate Product Owner direction, Product Authority architecture, bounded Repository Engineering and GitHub evidence through one defined engagement sequence.

Value created

Keeps authority, implementation and evidence roles distinct and durable in GitHub rather than in conversation alone.

Demonstrated through

  • Conversational Engineering v1.4
  • Platform Portal
Inspect evidence and future leverage
Evidence
Conversational Engineering v1.4, adopted as a Platform standard and applied across repository-engineering packets.
Future leverage
Extends to further repositories and packet types without changing the underlying authority boundaries.
MonitoringKnowledge

Documentation-as-Code

documentation-as-code

Keep engineering knowledge version-controlled alongside implementation.

Value created

Improves traceability, maintainability and reuse of engineering decisions.

Demonstrated through

  • Platform v1
  • Platform Portal
Inspect evidence and future leverage
Evidence
Standards, architecture and repository guidance are maintained in GitHub and reviewed as they change.
Future leverage
Provides structured source material for any future evidence-grounded review of the record.
ReleasedAssurance

Evidence-as-Code

evidence-as-code

Record what changed, why it matters and what happened next alongside the codebase.

Value created

Strengthens assurance and review without adding separate reporting ceremony.

Demonstrated through

  • Platform Portal v0.3.0 release evidence
Inspect evidence and future leverage
Evidence
Engineering evidence and release records are stored with the codebase and referenced from accepted PRs.
Future leverage
Keeps historical evidence available for future review without duplicating it into a register.
ActiveDelivery

Delivery-as-Code

delivery-as-code

Make delivery progress visible through repository activity rather than manual status reporting.

Value created

Reduces reporting overhead and keeps delivery status objective and inspectable.

Demonstrated through

  • Platform Portal
  • CVOS
Inspect evidence and future leverage
Evidence
Commits, releases, issues and PR history form the delivery timeline in GitHub.
Future leverage
Remains the evidence base any future delivery review would draw on.
ActiveValue

Value Engineering

value-engineering

Connect delivery to value claims using an explicit confidence vocabulary rather than overstated outcomes.

Value created

Keeps public and internal value claims accurate to their actual evidence basis.

Demonstrated through

  • Value Engineering v2.0
  • Platform Portal
Inspect evidence and future leverage
Evidence
Product and Portal records classify value as Measured, Modelled, Estimated or Assumed.
Future leverage
Supports comparable value review across products as evidence accumulates.

Explore next

See the Platform this Studio built, and the products it produced.

The Portal demonstrates the model. GitHub holds the engineering record.

PlatformProducts