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

One fictional case, step by step

The situation. In a fictional test case, a seller described an account restriction and clarified that the receipt had been uploaded afterwards. The participant also stated that receipt and review by the platform were unknown.

The clarification travels with the work. It was present in the later requests to the AI model and in its answers. The draft prepared after it kept both points: the receipt was uploaded after the restriction, and its handling is unknown.

The participant takes their own copy. A readable file holding the confirmed position, what remains unknown, the next step, and the status "not sent".

Someone else can continue from it. The participant manually copied the readable text into an external AI chat. In the later reading, the model distinguished the locally confirmed position, the remaining uncertainty and the unsent action, then prepared a draft for review.

How this was done, and what is not yet shown. This was a single fictional case. An operator carried out the actions in the interface; the participant reviewed and confirmed the position. The text was moved between the copy and the external chat by hand, not through an integration. The draft was not accepted, not sent, and not returned into the record. Repeatability, use without operator assistance and any comparison with an ordinary chat remain to be tested.

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: 13 October 2026