Caneni· Evidence· Applications· About
Applications · public map

One subject-side architecture. Different domain conversations.

The composition of the record, authorship, signature, reading, and rules for opening access stay the same. A domain changes the questions and the moments worth recording, not the record itself.

What remains the same

The shared layer

The same record structure carries the person's words, authorship, signature, readable history, and their choice about who may see it. A specialist needs to learn that format once.

The domain shell

The shell supplies the questions and identifies the moments that matter in a particular practice. Hospitality and marketplace selling do not ask the same questions, but they do not require different record logic.

Test the claim: build a shell in a new domain. If the core has to change, the claim of domain independence is false.

How status is stated

ProposedBrought by a participant or community; not yet agreed for work.
Agreed workA concrete task and route have been accepted for development.
Tested scenarioPeople have walked through the scenario end to end.
Real applicationUsed by an external participant in their actual practice.

No Caneni application is currently presented here as a real application.

Application map

The core has been tested in hospitality, seller and steward prototype workflows. Three people took part in external walkthroughs; steward testing was internal.

Application

Hospitality

ProblemA promise made at the desk can be lost between shifts, while each side remembers a different moment.
Whose recordEach participant keeps their own stated side of the promise.
TestedSingle-sided and two-sided routes were walked through.
Tested scenario
Application

Marketplace seller

ProblemA seller makes a consequential stock or fulfilment decision before a platform restriction or review may occur.
Whose recordThe seller keeps the position they formed before the later platform event.
TestedThe route was walked from orientation through the final subject-held copy.
Tested scenario
Application

Legal

ProblemA decision restricts an account, listing, access or payments; review, if any, comes afterwards.
Whose recordThe affected person or company, and separately the organisation that made the decision.
Current workThe application picture and five recurring moments are described.
Described
Read the legal application
Application

Employment and algorithmic management

ProblemTask allocation, assessment and loss of access are executed automatically between a worker and an employer or platform.
Whose recordThe worker; and the organisation for its own oversight of significant automated decisions.
Current workNo end-to-end application shell has been tested.
Described
Application

Consumer and private individual

ProblemRefusals, blocks and unilateral changes of terms faced by one person against an organisation.
Whose recordThe individual.
Current workNo end-to-end application shell has been tested.
Described
Application

Sport and sporting institutions

ProblemEligibility, disqualification and status decisions where an institution holds the procedure and the athlete holds only its outcome.
Whose recordThe athlete; and the institution for its own decision record.
Current workNo end-to-end application shell has been tested.
Described
Application

Creative and research work

ProblemProvenance of work: who made, changed or used material, when, and on what basis, including use in model training.
Whose recordThe author or research team.
Current workNo end-to-end application shell has been tested.
Described

Listing order is not a roadmap. A described application is not presented as tested, deployed in practice, or scheduled.

Working with a specialist

The subject opens the history; the specialist does not take it over.

A person can open a chosen part of their history to someone helping to protect or represent them. The person chooses the scope and level. The specialist cannot widen that access. Their work is recorded separately and does not rewrite the person's record.

Opening access, reading, specialist work, and closing access are distinct events. The current prototype records those events without turning the specialist into the owner of the history.

Tested in live prototype passes. Access was opened by the subject, chronology was read, specialist work was added as a separate step, and the specialist closed their access.
Deployed, acceptance still pending. Passing selected record content through the same relationship.
Not yet tested. The participant closing the specialist's access from their own side.

Ways to participate

Build

Implement

Developers and technical partners build a domain shell or an integration beside an existing system.

Support

Bring domain knowledge

Practitioners define the task, roles, questions, boundaries, and the result worth testing.

Protect

Check the boundaries

Counsel and domain experts examine professional, jurisdictional, and practical fit.

Invest

Examine the early system

Investors can review the tested scenarios, the repeatable build process, and what still remains untested.

The participation route

Start with a public example.No confidentiality agreement is required to understand the public proposition.
Bring one concrete task.Name the subject, what you can contribute, and the result you want to test.
Agree participation and confidentiality.Confidentiality begins before access to closed materials, not before the first conversation.
Open only the internal material needed.The scope follows the agreed task.
Walk through the application together.The first joint cycle becomes a reviewable example for improving the next one.

First participants enter as testers. The surface is working, but roughness may still appear. Finding it is a contribution to the application, not evidence that a finished service was promised.

Bring one concrete task

A useful first message is specific enough to test and small enough to walk through together.

Nothing is stored on this page. Your own mail client opens the message for review. Do not include privileged, confidential, medical, or unnecessary personal data.

Last updated: 11 October 2026