Private Working Model | Mithaq Praxis | v0.1

Status: Pre-commercial research and product discovery
Founder position: Independent creator and developer
Proposed role: Digital architecture owner and provision orchestrator
Initial customers: Individuals and families, followed by suitable organisations
Initial offering: Low-risk, non-clinical digital continuity tools
Future scope: Approved assistive integrations, specialised partners, and task-specific hardware

1. Business thesis

Mithaq Praxis develops the software, specifications, and coordination infrastructure for Amanah Companions.

It does not need to manufacture or directly provide every underlying technology or professional service.

The proposed business separates four interests:

1. The person: the beneficiary and continuity subject, whose expression, rights, privacy, and legitimate authority must be respected.
2. The purchaser: an individual, family, institution, public agency, or other payer.
3. Mithaq Praxis: the software developer, platform operator where applicable, and provision coordinator.
4. The delivery partners: qualified suppliers or professionals with bounded operational responsibilities.

The purchaser is not automatically the person with authority over every aspect of the beneficiary’s life.

The founder’s company may own its software, brand, specifications, and other lawful intellectual property. Personal continuity remains subject to the person’s rights and the applicable data-governance arrangement.

2. First product hypothesis

Working name: Amanah Continuity Kit

A low-risk digital toolkit for preparing, reviewing, updating, and exporting practical support information.

Possible initial modules:

• My Voice / My Choices profile;
• communication passport;
• routines and accommodations;
• sensory preferences;
• accessible handoff summary;
• transition preparation;
• trusted people and scoped sharing;
• record review and expiry indicators;
• structured export.

Initial exclusions: No autonomous clinical decisions, no diagnosis, no inferred consent, no continuous monitoring, no medication interpretation, no emergency autonomy, no robotic control.

The first version should not require integration with hospitals, schools, disability registries, or external healthcare systems.

Where feasible, personally sensitive information should remain under the user’s control rather than being collected centrally by default.

The product can initially be evaluated using synthetic profiles and realistic task scenarios.

3. Proposed customer pathways

Individual pathway

A person or family discovers the tool through Mithaq Praxis publishing, demonstrations, or a product page.

They choose a suitable low-risk tool.

They enter or import only necessary information, review it, configure sharing, and obtain an accessible export.

A paid option might provide additional editing, formatting, maintenance convenience, or supported configuration.

It must not manufacture a false clinical authority.

Institutional pathway

A school, centre, disability organisation, or other service provider identifies a bounded continuity problem.

Mithaq Praxis conducts product discovery, checks the scope and risk, and establishes a responsible data and service arrangement.

The organisation may license a limited workflow, such as generating reviewed handoff summaries or communication passports.

Each supported person’s records and permissions remain separately governed.

An institutional licence must not create universal access, automatic surveillance, or ownership of personal continuity.

4. Business flow

Stage	Operational action	Required control
Discovery	Identify the person-facing need	No diagnosis-first assumption
Classification	Determine risk and intended use	Block high-risk functions without the required pathway
Selection	Choose the least intrusive useful tool	No unnecessary hardware or AI
Configuration	Enter information and establish permissions	Minimum data, source trace, human review
Payment or funding	Identify payer and commercial terms	Payment does not confer authority
Provision	Deliver software or approved partner service	Named responsibilities and accessible onboarding
Support	Handle corrections, accessibility and technical issues	Clear response, incident and escalation routes
Review	Check usefulness, expiry and emerging harms	Person participation; no automatic care-rule promotion
Exit or replacement	Export records and close permissions	Portability, revocation and documented deletion

The sequence should be comprehensible even when no generative AI is used.

5. Proposed commercial revenue

Revenue lane	Description	Status
Digital product sales	One-off templates, tools or downloadable kits	Candidate
Optional software services	Hosting, synchronisation, collaborative editing or advanced convenience features	Candidate
Institutional licensing	Bounded access to approved workflows	Candidate
Configuration and integration	Defined technical setup and interoperability work	Candidate
Training and onboarding	Paid support or coordination with qualified trainers	Candidate
Device provision coordination	Disclosed fees or margins for vetted hardware and services	Future hypothesis
Funded access	Sponsored, charitable, institutional or public-payment arrangements	Future hypothesis

No revenue figure, price point, gross margin, conversion rate, subscription retention rate, or customer acquisition cost has been validated.

Referral payments or device margins must not incentivise unnecessary provision, unsafe recommendations, or undisclosed conflicts of interest.

Personal care data, advertising profiles, behavioural scoring, and emotional dependency should not be monetisation channels.

6. Costs and unit economics to investigate

Initial cost categories:

• development and maintenance;
• hosting or local-delivery infrastructure;
• accessibility testing;
• security and privacy;
• user documentation;
• support and corrections;
• payment processing;
• professional legal or compliance advice;
• localisation;
• testing and evaluation.

Later cost categories:

• supplier qualification;
• partner onboarding;
• device certification review;
• shipping, returns and warranties;
• installation and training coordination;
• equipment repair and replacement;
• incident response;
• contractual and insurance obligations.

Unit-economics test:

Revenue per transaction or service period minus direct fulfilment, payment, support, hosting, and relevant partner costs must leave enough contribution to sustain the service and its obligations.

One-off revenue must not quietly create unfunded lifelong service promises.

Recurring revenue must not be justified by preventing data portability.

The initial financial model should compare a simple one-off product with an optional hosted-service model before adding a multi-supplier platform.

7. Proposed supplier and partner architecture

Potential partner classes:

Partner class	Possible role	Key responsibility
Software provider	Specialist accessibility or AAC-compatible capability	Compatibility, security and support terms
Device manufacturer	Approved physical product	Product conformity, warranty and documented limitations
Qualified practitioner	Assessment, fitting or specialist configuration	Competence, scope and professional accountability
Service provider	Installation, training or continuing support	Deliverables, safeguarding and incident process
Fulfilment partner	Shipment, returns and logistics	Delivery, damage handling and traceability
Maintenance partner	Repair and replacement	Service levels, safe downtime and escalation

These are partner categories, not contracted relationships.

Before onboarding, Mithaq Praxis should document who is responsible for failures, recalls, product defects, professional judgement, privacy incidents, and operational harm.

Coordination does not erase the legal duties that may attach to an importer, reseller, integrator, manufacturer, service provider, or platform operator under applicable law.

A provider should not be listed as approved merely because an integration works technically.

8. Governance rules carried from Series I and II

The following remain non-negotiable design conditions:

• The supported person is the continuity subject.
• Person expression is distinguished from caregiver interpretation and AI inference.
• Permission follows actor, capability, context, conditions, expiry and stop path.
• Low-risk support should be accessible without unnecessary professional gatekeeping.
• Clinical and physical functions require their own evidence and applicable authorisation.
• Source records remain distinguishable from summaries and machine hypotheses.
• Operational care records do not become training material by default.
• No surveillance, behavioural obedience scoring or manipulative attachment design.
• Providers access only the minimum authorised projection.
• The person must be able to refuse relevant functions and challenge records.
• Models, devices and partners must be replaceable.
• No embodied function is deployed without a separately demonstrated safety and provision case.

Commercial product decisions must not override these rules.

9. Access without commercial captivity

Proposed accessibility and affordability mechanisms:

Basic portability: Offer a practical export pathway that does not depend on keeping a paid subscription active. A separate policy must address hosted-data retention and deletion.

Simple entry product: Test an affordable, accessible self-directed toolkit before investing in expensive integrations.

Optional convenience services: Charge for genuine additional functionality rather than for permission to recover one’s own history.

Organisation-funded access: Explore whether centres or public bodies can fund a tool while preserving person-specific privacy and authority.

Sponsored access: Research financial sponsorship or subsidies only when an actual sustainable funding source exists.

No perpetual free-hosting commitment is assumed.

No public funder or charitable partner is presumed.

10. Phased commercial roadmap

Phase A — Publishing and discovery

Maintain the Amanah research corpus and publish clearly labelled propositions.

Build simple product concepts with synthetic examples.

Gather feedback from people with relevant disability and accessibility experience, without treating informal interest as clinical validation.

Exit criterion: A clearly defined problem, audience, first product and acceptable low-risk scope.

Phase B — Minimum digital product

Build and test one practical continuity tool.

Evaluate accessibility, privacy, comprehension, export, correction, task success, and support burden.

Avoid unnecessary central storage and external AI services.

Exit criterion: Evidence that the tool provides useful value without unacceptable privacy, authority or operational risk.

Phase C — Small paid pilot

Only after legal, consumer, privacy and product obligations are reviewed for the intended jurisdiction.

Test transparent pricing and support costs.

Measure real purchase or institutional commitment separately from expressions of enthusiasm.

Exit criterion: Demonstrated willingness to pay, adequate support capacity, sustainable direct costs and acceptable user outcomes.

Phase D — Institutional workflow

Test one bounded service workflow.

Document authority, procurement, data processing, onboarding, corrections, exit and operational responsibility.

Exit criterion: Repeatable provision without increasing unnecessary surveillance or administrative burden on the supported person.

Phase E — Partner provision

Qualify an external assistive-technology or specialist-service partner for one defined use case.

Test the commercial and operational handover.

Exit criterion: Verified supplier responsibility, service quality, maintenance capacity and incident processes.

Phase F — Device or embodied research

Only after the relevant Series II safety, consent, privacy, testing, maintenance and regulatory prerequisites can be demonstrated.

No automatic progression to this phase.

11. Assumptions requiring validation

Hypothesis	Evidence required
Individuals will value a structured continuity kit	Accessible user interviews and observed task trials
Some users will pay for it	Actual purchase or commitment evidence
Institutions will fund bounded continuity workflows	Procurement conversations and pilot commitments
Existing tools are insufficient	Competitor and alternative-workflow comparison
Interoperability is commercially valuable	Demonstrated migration or integration problem
Qualified partners will participate	Partner discovery and feasibility discussions
Optional recurring services can support maintenance	Cost modelling and paying-customer evidence
Cross-subsidy can make access equitable	Identified, reliable funding and eligibility rules
Modularity will reduce rather than increase total cost	End-to-end operational cost comparison

Do not convert a plausible proposition into an established market fact.

12. Failure and stop conditions

The commercial model must be reconsidered if:

• the first product cannot demonstrate person-facing usefulness;
• accessible participation or refusal is unreliable;
• a viable offering requires unnecessary collection of sensitive information;
• the institutional customer demands surveillance or unrestricted access;
• essential continuity becomes inaccessible when payment stops;
• supplier responsibilities cannot be established;
• support costs consistently exceed sustainable revenue without reliable subsidy;
• the product makes false clinical or safety claims;
• or commercially attractive features undermine the governance spine.

The project should be able to narrow its scope rather than expanding simply because a market exists.

13. Remaining strategic decisions

Three decisions remain open:

Initial jurisdiction: Where the first sale, hosting arrangement and any later provision would legally operate.

First commercial product: Which bounded user problem to solve first, tested against real alternatives.

Commercial vehicle: Whether Mithaq Praxis initially sells through a suitable small-business structure and later separates regulated or higher-liability Amanah activities into a distinct legal entity.

These should be resolved before building detailed financial forecasts or supplier contracts.

14. Governing business proposition

Mithaq Praxis would aim to earn revenue from building, maintaining, configuring and responsibly coordinating useful infrastructure.

It would not earn revenue from owning the person.

The company can grow through software, services and qualified partnerships without becoming the manufacturer of every device.

Growth is legitimate only when the continuity spine, person-facing value, accountability and right to leave remain intact.

Build the architecture. Coordinate the provision. Keep the continuity with the person.