Platform

A reusable foundation reduces repeated decisions.

Shared standards, boundaries and assets keep every DoricDev product coherent, secure and portable, so each product's own delivery stays focused on the problem it solves.

See the architectureExplore products

Platform intent

Build once where it creates leverage. Extend only where evidence proves the need.

Platform v1 reduces repeated decisions, keeps products coherent and makes future delivery faster without turning the Platform into a speculative framework.

Platform architecture

Human direction, GitHub evidence, shared foundations, then current delivery profiles.

Cloudflare delivery profiles are selected by each product's own architecture, not mandatory shared Platform layers. GitHub remains the authoritative, provider-independent engineering source.

  1. 01

    Studio

    Human-led Studio and product direction

    Human judgement directs DoricDev: setting objectives, accepting architecture, deciding risk and retaining merge, operationalisation and release authority.

    • Product directionObjectives, priorities and accepted architecture
    • AuthorityMerge, risk, release and operationalisation decisions remain human
  2. 02

    GitHub

    Source, decisions, validation and evidence

    GitHub is the shared engineering source of truth for every DoricDev repository, decision and evidence record.

    • Issues and pull requestsAccepted objectives, implementation and review
    • CI evidenceValidation and outcome recorded alongside the change
  3. 03

    Shared Platform

    Standards, boundaries and design foundations

    Platform v1 owns the standards, boundaries and assets that should not be recreated product by product. It does not mandate a runtime provider.

    • Design SystemTokens, layout and UI patterns
    • Brand EngineeringCertified identity assets
    • Documentation/Evidence-as-CodeDecisions and evidence recorded in GitHub
    • Provider-Independent Runtime PatternsSecurity, data and delivery principles products apply within their own architecture
  4. 04

    Delivery profiles

    Current product delivery profiles

    Cloudflare services selected by product architecture — current delivery options, not mandatory shared Platform layers.

    • Cloudflare PagesStatic/public product delivery
    • Cloudflare AccessDeliberately protected product contexts
    • Pages Functions / WorkersAn authorised application/API boundary
    • D1An authorised structured operational-data profile
  5. 05

    Products

    DoricDev products and public experiences

    Each product solves a specific problem while inheriting shared, provider-independent foundations.

    • DoricDev Platform PortalPublic reference implementation
    • Community Venue Operating System (CVOS)Access Preview product

Shared capability

The platform is more than code.

Platform v1 combines engineering standards, design foundations, certified brand assets, repository guidance and product-consumption patterns.

Capability Wayfinder

Find capabilities by where they contribute.

DoricDev capability families remain canonical. This wayfinder adds a lifecycle-informed navigation lens across Plan, Code, Build, Test, Release, Deploy, Operate and Monitor, with Security shown separately as a cross-cutting concern rather than a final stage.

This is a representative mapping of eight accepted capabilities, not a complete catalogue of DoricDev engineering. Stage placement records an evidenced contribution, not ownership or complete coverage of that stage, and does not claim DevSecOps compliance, certification or maturity.

Plan

Code

Build

Test

Release

Deploy

Operate

Monitor

Security — a cross-cutting lens

Security is not a ninth sequential stage. The capabilities below have an explicit, evidenced security contribution across the stages listed, not every stage they appear in.

Capability profiles

Each capability renders once here, whichever stage or the Security lens links to it.

ProtectAccepted Platform position

Secure by Design

Builds proportionate security into product architecture, implementation, release and operation rather than treating it as a final review step.

Outcome

Products expose only what they intend, apply controls proportionate to risk and retain explicit evidence and accepted risk.

Delivery detail and non-claims

Supporting families

  • Design
  • Assure
  • Operate
  • Improve

Security contribution

Security, privacy, identity, access, resilience, safe defaults, recovery and audit across every mapped stage.

  • Security
  • Privacy
  • Identity
  • Access
  • Resilience
  • Safe defaults
  • Recovery
  • Audit

Made repeatable through

  • Security operating modelPracticeHuman-guided

    Scales product-security decisions to exposure, data sensitivity and operational risk.

  • Threat and accepted-risk templatesTemplateHuman-guided

    Makes risk, controls, ownership and review triggers explicit without creating enterprise ceremony.

  • Proportionate security validationValidation contractHybrid

    Combines automated checks with human review of real product and deployment boundaries.

External alignment

No external alignment published. No named external framework alignment is published for this profile. The public position comes from the accepted DoricDev capability and its product evidence.

Public product examples

Explicit non-claims

  • DoricDev does not claim compliance with an external security framework through this capability.
  • Every product does not receive the same controls; assurance is proportionate to exposure and data risk.
  • Tool scores and automated checks do not replace human risk acceptance.
BuildReleased

Engineering Delivery Standard

Provides one shared delivery baseline for architecture, bounded implementation, validation, GitHub evidence and accountable acceptance.

Outcome

Change remains reviewable, traceable and appropriately validated from initial intent through maintenance and learning.

Delivery detail and non-claims

Supporting families

  • Assure
  • Operate
  • Improve

Security contribution

Protects Plan, Build, Test, Release and Deploy through explicit boundaries, trusted evidence and controlled privileged actions.

  • Security
  • Access
  • Audit

Made repeatable through

  • Engineering Delivery StandardStandardHuman-guided

    Defines the minimum assurance outcomes inherited across DoricDev repositories.

  • Work packet and pull-request templatesTemplateHuman-guided

    Keeps objectives, scope, exclusions, validation and authority explicit.

  • Canonical validation and deployment gateValidation contractHybrid

    Automates repeatable checks while retaining human merge, risk and release authority.

External alignment

No external alignment published. The capability is derived from repeated DoricDev product evidence. No external method or framework alignment is claimed.

Public product examples

Explicit non-claims

  • The standard does not require every repository to use identical tools or workflow files.
  • Engineering completion does not automatically authorise merge, deployment, release or activation.
  • One successful product use does not automatically promote adjacent product architecture into the Platform.
BuildReleased

GitHub Actions Governance

Keeps continuous integration reliable and proportionate through one authoritative validation path, explicit deployment gates and evidence-led optimisation.

Outcome

Automation spends capacity where it provides real assurance while preserving secure, traceable delivery.

Delivery detail and non-claims

Supporting families

  • Assure
  • Protect
  • Improve

Security contribution

Protects Build, Test, Release and Deploy through untrusted-context boundaries, controlled secrets and validation-gated deployment.

  • Security
  • Access

Made repeatable through

  • GitHub Actions StandardStandardHuman-guided

    Defines reusable assurance, trigger, concurrency, deployment and capacity outcomes.

  • Authoritative repository validationWorkflow-as-CodeAutomated

    Executes the repository's accepted validation contract once for each normal change event.

  • Controlled diagnostics and deploymentWorkflow-as-CodeHybrid

    Keeps specialist or privileged actions intentional, gated and human-controlled.

External alignment

No external alignment published. The capability is based on measured DoricDev workflow evidence. No external CI/CD framework conformity is claimed.

Public product examples

Explicit non-claims

  • DoricDev does not prescribe one universal workflow file.
  • Similar jobs are not automatically duplicates; different assurance boundaries may justify them.
  • Wall-clock duration is not represented as billed-minute saving without billing evidence.
AssureMonitoring in operation

Documentation-as-Code

Keeps standards, architecture, decisions and guidance close to the engineering work they describe.

Outcome

Documentation changes through version control, review and traceable history instead of becoming a second unmanaged source of truth.

Delivery detail and non-claims

Supporting families

  • Discover
  • Operate
  • Improve

Made repeatable through

  • Documentation-as-Code decisionPracticeHuman-guided

    Establishes GitHub as the authoritative location for engineering documentation.

  • Documentation templatesTemplateHuman-guided

    Makes recurring decisions and evidence easier to record consistently.

  • Pull-request review historyEvidence-as-CodeHybrid

    Preserves why documentation changed and who accepted the result.

External alignment

No external alignment published. Documentation-as-Code is an accepted DoricDev practice. No external method conformity is claimed in this public profile.

Public product examples

Explicit non-claims

  • Documentation does not replace software behaviour, tests or runtime evidence.
  • Not every engineering document is suitable for public publication.
  • Documentation volume is not treated as a measure of capability maturity.
AssureReleased

Evidence-as-Code

Preserves what changed, what was validated, what value was delivered and what remains unproven alongside engineering work.

Outcome

Product and Platform claims can be traced to accepted delivery, decision, quality and learning evidence.

Delivery detail and non-claims

Supporting families

  • Discover
  • Operate
  • Improve

Security contribution

Supports audit across Test, Release, Deploy, Operate and Monitor by preserving sanitised decision and validation evidence.

  • Audit

Made repeatable through

  • Evidence-as-Code foundationPracticeHuman-guided

    Defines which delivery, decision, quality, value, learning and reuse outcomes should be retained.

  • GitHub delivery historyEvidence-as-CodeHybrid

    Combines automatically retained repository history with accountable human and AI decisions.

  • Initiative and release closeoutTemplateHuman-guided

    Records delivered value, evidence, limitations and future learning at meaningful boundaries.

External alignment

No external alignment published. Evidence-as-Code is an accepted DoricDev capability. No external assurance-framework compliance is inferred.

Public product examples

Explicit non-claims

  • The existence of evidence does not prove that a capability is complete, compliant or low risk.
  • Metrics are evidence indicators rather than maturity scores or vanity measures.
  • Protected identity, provider and operational values remain outside public profiles.
ProtectAccepted Platform position

Platform Identity Foundation

Defines purpose, ownership, lifecycle and evidence boundaries for human, functional, synthetic, workload, deployment and recovery identities.

Outcome

Identities are created only for an accepted purpose, receive exact access and can be reviewed and retired without making one provider the architecture.

Delivery detail and non-claims

Supporting families

  • Design
  • Operate
  • Assure

Security contribution

Identity, access, recovery, safe defaults and audit across every mapped stage.

  • Identity
  • Access
  • Recovery
  • Safe defaults
  • Audit

Made repeatable through

  • Provider-neutral identity foundationStandardHuman-guided

    Defines identity classes, ownership, purpose, least privilege and protected-evidence boundaries.

  • Identity lifecycle and sanitised evidenceRunbook-as-CodeHuman-guided

    Makes creation, verification, review, revocation and retirement intentional and reviewable.

  • Provider and product verificationValidation contractHybrid

    Combines provider controls with separate product authorisation and accountable acceptance.

External alignment

No external alignment published. The public profile represents the accepted DoricDev foundation. The separate JML-as-Code example remains Candidate and is not presented as an active Platform standard.

Explicit non-claims

  • The foundation is not a Platform-wide product authentication runtime.
  • Successful authentication does not itself grant a product role or resource authority.
  • The capability does not claim identity-framework compliance or promote JML-as-Code beyond Candidate / Discovery.
  • No exact identity, mailbox, allowlist, tenant or provider value belongs in the public profile.
DesignAccepted Platform position

Design System

Provides shared visual, interaction and documentation foundations so products feel related without becoming identical.

Outcome

Products inherit coherent colour, typography, spacing, layout and component patterns while retaining product-appropriate identity and function.

Delivery detail and non-claims

Supporting families

  • Build
  • Assure
  • Improve

Made repeatable through

  • Design standards and specificationsStandardHuman-guided

    Owns the rules for colour, typography, layout, logo use and experience foundations.

  • Tokens and reusable interface patternsComponent libraryHybrid

    Turns accepted design decisions into reusable product implementation inputs.

  • Accessibility and implementation reviewValidation contractHybrid

    Combines repeatable checks with human judgement of real product experience.

External alignment

No external alignment published. The profile is based on the accepted DoricDev design capability. No external design-system maturity or method claim is made.

Public product examples

Explicit non-claims

  • The Design System is not a general-purpose UI framework or CMS.
  • Consistency does not require every product to have identical personality or business functionality.
  • A design standard does not replace product-specific usability and accessibility validation.
BuildReleased

Brand Engineering

Treats DoricDev visual identity as a governed, reproducible engineering capability rather than a folder of manually recreated artwork.

Outcome

Products consume certified masters and deterministic exports from one controlled visual source.

Delivery detail and non-claims

Supporting families

  • Design
  • Assure
  • Improve

Made repeatable through

  • Certified master and variant libraryComponent libraryHybrid

    Preserves approved visual sources and mechanically derived variants under controlled ownership.

  • Automated export pipelineWorkflow-as-CodeAutomated

    Regenerates production-ready assets deterministically from certified sources.

  • Asset certificationValidation contractHybrid

    Combines technical validation with accountable visual acceptance.

External alignment

No external alignment published. The capability is grounded in DoricDev brand and engineering evidence. No external branding or design certification is claimed.

Public product examples

Explicit non-claims

  • Generated production exports are not the engineering source.
  • Brand Engineering does not define every product interaction or product identity decision.
  • Automation improves reproducibility but does not replace human visual approval.

Platform boundaries and capability reuse

Products own their implementation. Platform promotion is a separate decision.

The Platform owns shared foundations; products own their own product architecture and implementation. A pattern discovered in product delivery becomes a Platform Candidate, not an automatic standard. Promotion and product adoption remain separate decisions, made only after cross-product or genuinely independent evidence.

  1. 01
    Product Pattern

    A product delivers a reusable approach while solving its own problem.

  2. 02
    Platform Candidate

    The pattern is proposed as a Platform Candidate, not yet a shared standard.

  3. 03
    Cross-product or genuinely independent evidence

    The candidate must be repeated across products or independently evidenced before it is treated as proven.

  4. 04
    Separate Platform promotion decision

    Promotion is a distinct, explicit decision, not an automatic consequence of one product delivery.

  5. 05
    Later product-adoption packet

    Other products adopt the promoted capability through their own bounded engineering packet.

Next

Products consume Platform foundations. Promotion remains a separate decision.

Explore the products that inherit this foundation and the evidence they generate.

ProductsStudio