ClariDroits private Alpha in France

Understand the ClariDroits Alpha journey without confusing it with a stable public version.

Any displayed access is technical Alpha access that must be confirmed, not a public offer or a qualified release. Before use, the version, file fingerprint, date, distribution authorisation and access conditions must be checked. Results may contain errors and must be reviewed.

Non-public French Alpha — access to be confirmed — ClariDroits is currently a project led by Patrick François Kahouadji, before the legal structure is created.

This page is in English (locale en-GB). The reference country is France. The procedures described fall under French jurisdiction; the language does not select a jurisdiction.

Review status: Human English clarity was reviewed on 30 July 2026. Patrick approved this informational English web release. Native British English review and human accessibility validation are not claimed; no accessibility-conformance claim is made.

A straightforward tester journey

One short introduction, one focused test and feedback that can be acted upon.

The intended journey seeks to reduce installation effort. Its actual effect on starting and understanding a test remains a benefit to be measured through documented feedback.

Before installing anything, the tester should be able to understand the problem addressed, the expected result and the safeguards.

Android and Desktop access follow different arrangements. The exact build and its capabilities must be confirmed for each identified tester.

Fictitious or anonymised material should be used whenever possible.

  • Understand the test before installing.
  • Use only the build and instructions supplied for the test.
  • Prefer fictitious or anonymised material.
  • Report both helpful and blocking experiences.

1. Understand before installing

Start with a short explanation of the problem, intended benefit and limits of the Alpha. The introductory scenario aims to take about five minutes, but actual time varies.

  • short orientation
  • visible safeguards
  • no promise of an outcome

2. Use the supplied test build

Use an Android or Desktop Alpha build only after its access, version, fingerprint, date and distribution authorisation have been confirmed.

  • platform-specific instructions
  • identified testers
  • capabilities checked against the supplied version

3. Test with safe material

Use a fictitious or properly anonymised letter and observe whether the explanation and next steps are understandable. Any analysis may contain errors and requires review.

  • no unnecessary personal data
  • review the analysis
  • check what still needs human verification

4. Share useful feedback

Describe what helped, what caused difficulty and what should be made clearer or more accessible.

  • what worked
  • what was missing
  • what should be simplified

Concrete scenarios

Three intended scenarios for assessing whether the project may be useful.

These scenarios describe test objectives, not proven capability, availability or measured benefit.

A scenario should make it possible to judge clarity, accessibility and caution.

The purpose is to identify improvements, not to demonstrate that the Alpha is complete.

  • Clarity of explanations
  • Accessibility of the journey
  • Usefulness of the proposed next steps
  • Visibility of limitations

Understand a letter

Identify important information, dates and possible next actions without presenting the output as an official decision.

  • important information
  • deadlines
  • points to verify

Prepare a child's case file

Bring together school information, needs, documents, appointments and explanations in a clearer structure.

  • school context
  • document organisation
  • human review

Explain an invisible difficulty

Turn pain, fatigue or isolation into careful, understandable facts without inventing a diagnosis.

  • lived experience
  • factual wording
  • explicit uncertainty

Test method

Test without unnecessary risk and without promises.

A short test should examine understanding, outputs and safeguards before feedback is submitted.

Choose a scenario such as a letter, case file, appointment, supporting document or refusal.

Observe whether the explanations are clear, cautious and useful.

Check any available outputs against the capabilities of the supplied build.

Report what helped, what is missing and what should be simplified.

  • Choose one scenario.
  • Assess comprehension.
  • Review the outputs and their limits.
  • Provide concise feedback.

Publication safeguards

Limits that remain visible in every language

  • ClariDroits aims to help people understand, prepare and organise; it must not make administrative, medical or legal decisions.
  • It does not replace a doctor, lawyer, public authority, French MDPH or other competent professional or institution.
  • The declared design principle is no automated diagnosis, signature, transmission or submission; its implementation must be checked for the exact version.
  • Use fictitious or anonymised test material whenever possible.
  • An Alpha result may contain errors or invented information and must be checked by the person or relevant professional.
  • Access, capabilities and qualification must be confirmed for the exact build being considered.
  • The purpose of Alpha testing is to improve clarity, accessibility and caution, not to claim that the product is complete.

Key facts

Clear answers about this page

What is the current status of ClariDroits?
ClariDroits is currently a project led by Patrick François Kahouadji, before the legal structure is created. It remains a non-public Alpha, with access and qualification to be confirmed.
How long is the introductory test intended to take?
The intended introductory scenario aims to take about five minutes, but actual time varies by person and version.
Is the English page an offer of access in the United Kingdom?
No. It explains the French private-Alpha testing approach and does not claim UK availability.

Frequently asked questions

Questions about this page

Should real personal documents be used during the test?

Fictitious or anonymised material should be preferred whenever possible.

Do Android and Desktop always provide the same functions?

No. Access, capabilities and qualification depend on the build supplied to the tester.

Does Alpha testing validate a right or an administrative outcome?

No. Testing assesses clarity, accessibility and usefulness; competent professionals and institutions retain their responsibilities and decisions.