Public planA public roadmap, built the way we build records.
This page will show what we are building now, what comes next and what we are considering later, across every suite and every part of the platform. No items are published yet. Everything else is here already: the lanes, the areas, the rules for how items move and the principles that decide them.
- lanes, from now to shipped
- 4
- areas: suite groups and platform
- 12
- items published so far
- 0
- release in the changelog
- 0
The board
Four lanes, from the work in progress to the work released. Each item will sit in exactly one lane and carry the area it belongs to, so you can follow one suite or one part of the platform. The board is empty until the founder publishes the first items.
Showing items in all areas: none published yet.
Now
Items: 0Being built. Work has started and the item is on its way to the changelog.
Items appear here when the roadmap opens
No items have been published in this lane yet.
Join the waitlist →Next
Items: 0Decided and queued. It is the next work to start once the current items ship.
Items appear here when the roadmap opens
No items have been published in this lane yet.
Join the waitlist →Later
Items: 0Worth doing and kept in view, but not yet scheduled. The scope can still change.
Items appear here when the roadmap opens
No items have been published in this lane yet.
Join the waitlist →Shipped
Items: 0Released. Each shipped item links to its changelog entry and its documentation.
Items appear here when the roadmap opens
No items have been published in this lane yet.
Read the changelog →What each item will show
Every card on the board will carry the same six parts, so an item says what it is, where it stands and where to read more, and nothing more than that.
- 1Area: the suite group or platform area it belongs to.
- 2Title: what the item is, in plain words.
- 3Outcome: what it will let you do or verify once it ships.
- 4Lane and last move: where it stands, and when it last changed lane.
- 5Links: the documentation it affects and, once shipped, its changelog entry.
- 6Votes: how many people asked for it, once voting opens.
The areas it is organised by.
The roadmap follows the shape of the product. Suite areas are the five groups of Trustvice 360; platform areas are the parts every suite shares. Each area links to what exists in it today.
Suite groups
One area per suite group. New suites and changes to existing ones land here; features marked Coming Soon belong here too.
Agents
Watch, test and rehearse what agents do.
Items: 0Suites today: 4Governance
Rules, drift and behaviour checks.
Items: 0Suites today: 3Commerce and disclosure
Price provenance and AI disclosure.
Items: 0Suites today: 4Interfaces
How people and agents reach the platform.
Items: 0Suites today: 3Capabilities
Built into Trustvice 360: signed, chained, publicly verifiable records for the systems you connect.
Items: 0Platform
The surfaces and guarantees that every suite relies on.
REST API and MCP
The versioned REST API, the MCP server and the actions an agent can call.
Verification
The record format, the published key set and every way to verify a record without us.
Data regions
Where records are stored and signed. 7 regions today, one chosen per workspace.
/regionsDashboard
Workspaces, records, monitors, exports, team, keys, alerts and billing.
/docs/platform-modelSDKs and integrations
Verifier libraries, the command line and the integrations Trustvice works with.
/integrationsSecurity
Signing keys, authentication, tenancy isolation, outbound request controls and abuse controls.
How items will move.
An item enters the board when we decide it is worth doing, and moves one lane at a time. Lanes describe the stage of the work. They are not dates, and the roadmap does not promise when an item ships.
/changelogThe rules
- An item is in one lane at a time and moves one lane at a time: from Later to Next, from Next to Now, from Now to Shipped.
- Lanes give order, not dates. A date appears only when something has shipped.
- When an item moves back or is dropped, the card says so and why, instead of quietly disappearing.
- An item reaches Shipped only when its changelog entry is published, so Shipped and the changelog always agree.
When we say no
Some requests will not fit the product: for example a feature that would make a record claim more than it can show. We will say so plainly, with the reason, rather than leave the request open.
What a receipt cannot prove →How we decide what goes on it.
The same rules that shape the product decide its roadmap. A request that breaks one of them does not ship in that form, however often it is asked for. Each rule links to where the product already keeps it.
Receipts state no more than they prove
A new feature or field has to say exactly what it shows and what it does not. If a receipt would imply a fact we did not observe, the design changes until it does not.
Where it holds todayWhat a receipt cannot prove →02Neutral
We take no side in the record. We sign what we observe or what you report, label which is which, and never add a verdict.
Where it holds todayObserved and reported facts →03Verifiable without us
Anything new must stay checkable offline with a published key, with no account and no call to our servers.
Where it holds todayVerify in your own code →04Old receipts keep verifying
Changes within a version are additive. Key rotation is additive by policy, so a receipt signed today still verifies after a new key arrives.
Where it holds todayRotation and old receipts →05Hash first
We prefer designs that need a hash over designs that need your content. A feature that would make us store more data has to earn it.
Where it holds todayData and privacy →06Honest about limits
Every release states its known limits next to what it adds. The roadmap will do the same for what is planned.
Where it holds todayKnown limits today →What has already shipped.
The changelog is the record of what is real today. These are its latest entries, taken from the changelog itself. Once the roadmap opens, every item in Shipped will point to one of them.
Latest entries
Until the roadmap opens, the changelog's list of known limits is the most direct statement of what is not finished yet. Read the known limits →
Request a feature.
You can ask for a suite feature, a field, an integration or a change today. Requests sent now will be the first input to the roadmap when it opens.
Write to us
The general contact form, for a new feature, a missing field or a change to an existing one.
Open/contact?topic=general →Ask support
If you already use Trustvice and something is missing in your work, support can record it with the details.
Open/support →Ask for an integration
For a platform, framework or service you want Trustvice to work with.
Open/contact?topic=integration →Not for security issues
A vulnerability is not a feature request. Report it privately through the security page instead.
Open/security/report →Voting opens with the roadmap
There is no voting yet. When the roadmap opens, you will be able to add your vote to an item instead of writing a new request. Until then, a message to us counts.
What makes a request easy to act on
- The event you need evidence of, in one sentence.
- Who has to check the receipt: a customer, an auditor, a court, your own team.
- What the receipt should state, and what it must not claim.
- What you use today instead, and where it falls short.
Be told when the roadmap opens.
Join the roadmap list and we will email you when the first items are published, and when the roadmap changes after that. It is one list with one topic, and you can leave it at any time.
- Double opt-in: nothing is sent until you confirm from the first email.
- Only roadmap news on this list. Other newsletters are separate.
- Leave the list at any time from your email preferences.