Roadmap

Where Dokimos is going.

What is built, what is being built, and in which order. Quarters are checkpoints, not promises: a theme moves when the work before it is accepted, never because a date arrived.

Available on the product's main line and verified In development being built or awaiting review Planned designed, not started

Available today

What runs today.

Every item below is on the product's main line, exercised on a fictional worked example. Available means it exists and works as described; it does not mean a product is secure or an organisation compliant.

  • Assurance calendarRecurring activities with owners, due dates, expected evidence and a state: scheduled, due, overdue, done or skipped.
  • Evidence intake by uploadEach artefact stored with its source, time, scope and SHA-256 hash, and checked again before it is relied on.
  • Validation and human reviewSchema checks, evidence verification and four-eyes approval before anything is published.
  • Findings and remediationHuman-adjudicated severity beside the raw tool rating; owners, deadlines and SLA on every finding.
  • Release gateGO, GO WITH CONDITIONS, NO-GO or NO VERDICT against criteria agreed before testing.
  • Reports and exportsTechnical remediation report, release gate decision and audit evidence pack, in HTML and PDF with JSON, CSV and Markdown alongside.
  • Management reviewA quarterly review over the same record: key figures, a four-quarter trend, decisions and actions by a named decision-maker.
  • Provenance and exportEvery published version traced to its inputs, digests and build environment; the whole workspace exportable and verifiable.

The plan

Quarter by quarter.

Each quarter has one theme. A theme is finished when its work is on the main line, verified on one exact build and accepted by a named person. The order is fixed; the quarter is the current estimate.

  1. · now

    Release 1, hardened and accepted on synthetic data

    The internal platform runs on its own host with backups, isolation and a verified build before any real assessment data enters it.

    • Security review repairsFixes from the threat model and security review, each with a named disposition.In development
    • Backups and restore drillNightly database backup to object storage; a restore rehearsed on a separate host, never over production.In development
    • Report generation on the hostThe worker runs in its pinned image on the production host, isolated from the web application.In development
    • One verified candidateOne exact commit verified on CI and reviewed before acceptance; a successor commit starts over.In development
    • Go-live gates before real dataRetention periods, object lock for published artefacts and a second human reviewer.Planned
  2. Framework readiness and the executive summary

    Views of the same record for each framework, and one page for management. Counts, states and dates; never a percentage, a score or a compliant label.

    • Framework readiness reportsPer-program views of the record: ISO/IEC 27001, PCI DSS and EU CRA, with the requirements nothing cites shown as gaps.In development
    • Executive summaryOverdue obligations, framework readiness, material risks as defined counts, remediation trends, decisions and actions.In development
    • Published packsReadiness and executive packs generated by the engine, reviewed four-eyes and published with grants. A published report is never evidence.In development
    • ISO/IEC 42001 in the catalogFramework and requirement summaries written in our own words, reviewed by a named content owner.Planned
    • Findings in the viewsOpen findings past SLA and four-quarter remediation trends, once a findings register is ingested.Planned
  3. Remediation verification and assessment history

    A second assessment shows what was fixed, what was verified, what is still open and what is new.

    • Remediation verification reportRemediated, unresolved, not verified and new. A fix counts as remediated only with retest evidence and a named retester.Planned
    • Assessment historyWhat changed between cycles, by exact identifier; renamed, split or merged findings mapped by a person, never guessed.Planned
    • Follow-up actions with their basisEach action names the findings and the rule that produced it. Nothing is labelled mandatory without a cited requirement.Planned
  4. Later

    Integrations and external delivery

    Evidence arrives without manual upload, and a controlled view leaves the record for people outside it. No quarter yet: these depend on systems we do not control.

    • Upload API and CI stepScoped, expiring, revocable tokens; re-submitting the same run is a no-op; a token can never read or publish.Planned
    • Scanner results as candidatesSAST, dependency, container and secret-scanning output lands as candidates for human triage. Tool severity is never accepted automatically.Planned
    • Tracker links and chat notificationsTickets referenced from findings; due and overdue notices in the team's channel.Planned
    • Due-diligence packA controlled external view for customers, partners and acquirers, with named recipients and an expiry.Planned

Status tags are updated when the product changes, not when the quarter ends. Nothing on this page is a commitment to a feature or a date.

How the order is decided

Three rules the roadmap never breaks.

  • Fail closed, then ship.Hardening and the verified build come before new features. A feature that would weaken a check, a schema or a verdict rule is not on the list.
  • Named humans decide.Every theme moves on a recorded decision by a named person. Scanner and AI output stays candidate evidence until someone adjudicates it.
  • A report is a view.Every report type, present or planned, reads the same record. No report is a separate source of truth, and no report is evidence of itself.

Dokimos helps you operationalise requirements, collect and validate evidence, assess readiness and report. It does not certify organisations, replace auditors, guarantee compliance or provide legal advice. A gate verdict is a decision about recorded criteria, not proof that a product is secure.

Missing something?

Tell us which report, framework or integration would change your work. The order above is set by what early-access teams need to prove, and Dokimos is developed by CyberTwierdza.