150 parts, and what each one is for.

Booking & Scheduling

The scheduling engine underneath everything else — calendars, availability, rooms and the rules that decide which slots a client is actually allowed to see.

• An availability engine that resolves weekly hours, dated exceptions and existing bookings into free slots
• Schedulers, hosts, locations and rooms, with capacity and clash detection
• Slot rules, waitlists and automatic slot offers when a booking is freed

Paid Meeting Booking

Sells one-to-one sessions as credits. This is the module that makes buying and booking two separate steps, which is what allows a package to be sold today and scheduled over months.

• Sessions sold as credits against a product, singly or as a package
• Package service agreements accepted at purchase and kept at the version accepted
• Tiered cancellation policies with notice windows, penalties and a grace period

Clinic Platform

The application layer: professionals and their public profiles, the mobile API, content and community, notifications, and the client-facing account.

• Expert profiles with a verification workflow, credentials, services and calendars
• Reviews, ratings, public questions and the expert dashboard behind them
• REST endpoints for the mobile app, JWT authentication, and WebSocket sessions

Clinic

Clinic Reports

The seventeen management reports. Twelve ask whether the clinic’s record matches what happened; four compare how professionals are doing; one sits above them all.

• Alignment lists: stuck sessions, unbooked credits, coverage vs demand, money chain, fee ledger
• Payout readiness, cancellation conduct, compliance file, client continuity and the moderation queue
• Sessions without a report, and cancelled sessions read alongside conduct

Session Reports

The clinical note a professional files after a held session — stored as a secure document about the client rather than as an attachment on a meeting.

• A report filed against the session and recorded as being about the client
• Encrypted at rest on the secure document service, with a key per version
• Access decided only by the care team resolution, never by a role or by seniority

Memberships

A standing arrangement rather than a purchase each time: a plan sold in the shop, and one client’s membership against it.

• Plans are shop products with an image and a description; the public catalogue is at /memberships
• A membership carries session credits, chat access and offline consultation minutes
• Credits stay ordinary session credits, so booking never learns a second rulebook

Metered Chat Consultations

Expert time bought as minutes rather than as an appointment, spent in chat and accounted for to the minute.

• A service can sell a budget of expert minutes, with an optional validity window
• Rate card on the company, overridable per service
• A ledger entry per charge, and a statement both the client and the expert can open

Intake Forms

The questionnaire a client fills before the first session, stored as clinical content rather than as survey answers.

• A service names the questionnaire that goes with it
• The client fills it before the session, from their own pages
• Answers are written straight to an encrypted document — never left in the survey’s own storage

Offline Payment Review

Bank transfer as a payment route, for clinics that want a person to look at every order before and after the money moves.

• Approve the order, invoice it, take the proof of transfer, approve the proof, then mint the credits
• Credits appear only once the proof is approved, so an unpaid order cannot book a session
• A rejection carries its reason, and the order goes back to the person who can fix it

Offline Payment — client pages

The client-facing half of the offline route: where they pay, what they upload, and what the order is waiting for.

• Each state has its own colour and mark on My orders, so waiting is visibly different from rejected
• Pay and upload the proof in one dialog, without leaving the order
• The rejection reason is shown where the person who has to act on it will read it

Accountant Dashboard

The books, on a dashboard of their own: what came in, what is owed, what delivery cost and what is still to come. Separate from the administrator's by design — chasing an unpaid invoice on the floor is one job, and keeping the ledger is another.

• A landing page of four money tiles, six health ratios, six charts and a flag list
• Twenty-one reports: cash, revenue, delivery cost, forecast, leakage and two control checklists
• Accrual or cash, five periods and a custom range, carried through every drill-down

Team Dashboards

What needs doing, for the four teams around the clinic. Sales, people, marketing and delivery each get a page, and every page opens with the same question: what is late, what is now, what is coming, and what has nobody promised to act on.

• Four dashboards, each a record rather than code, so a pack can add one
• The activity strip on every page: late · today · planned · nothing scheduled · needs attention
• "Nothing scheduled" is the band Odoo has no state for — an open record nobody has promised to do anything about, which appears on no other screen

Dashboards — CRM, Sales, Delivery, People

How we are doing, in the app managers already open. Four pages in Odoo's own Dashboards, in a Clinic Teams section of their own, built the way its Sales and Expenses pages are built.

• Four pages — CRM, Sales, Delivery, People — beside Odoo's own
• Four KPI tiles a page, each with the previous period beside it
• Two charts and two to four top-N tables a page, every one opening the records behind it

Dashboards — Attendance, Time off, Staff payments

Three more pages in the same section, kept apart because each one needs an app the clinic may not run.

• Attendance: currently checked in, records, hours worked, extra hours, by employee and by department
• Time off: requests awaiting an answer, days approved, refusals, and where leave falls by month, type and department
• Staff payments: to report, to validate, to reimburse, and what was claimed in the period

Support Tickets

A public form that turns a question into a task somebody owns.

• A form at /support/ticket that anyone can use, signed in or not
• Each submission opens a task, assigned to the store administrator
• The submitter follows their own ticket, and the administrator is notified in Discuss

Episodes of Care

A course of care with a start, an end and a plan — the spine everything else in the clinical record hangs from. Care is not a stream of appointments, and the record says so.

• An episode opens on the first held session, and a client has one open at a time
• A treatment plan per episode: problem → goal → objective, three levels and no more
• A goal carries a title, a target date and a result — what was worked towards, and how it went

Clinical Notes

Note templates as an ordered list of typed fields, so a note is answers rather than prose nobody can search.

• A template is a versioned, published list of typed fields — text, number, scale, choice, date
• A completed note is the answers plus a rendered secure document
• Answers are readable exactly when their document is: one access rule, not two that drift apart

Note Template Library

The starting content for the template engine: a thousand named note formats, so a clinic does not begin with an empty library.

• Over a thousand named templates — SOAP, DAP, BIRP, intake, review — grouped by discipline
• Installed as data, editable afterwards like any template the clinic writes itself

Goals Monitoring

What a client records between sessions, attached to the goal it measures. A programme that reports against nothing is how monitoring turns into homework.

• A programme library with six item kinds: questionnaire, measurement, choice, journal, upload, task
• A programme is sent to a goal, so every entry reports against something the plan actually asked for
• The client records on their own plan: what is due today first, then each goal and what is open against it

Scored Questionnaires

Clinic-owned scored instruments. No instrument content is shipped and no licence is claimed: the clinic enters what it is entitled to use.

• A score is stored with the instrument version that produced it, and is never recomputed
• Bands and thresholds per instrument, with a risk band raising a flag somebody has to acknowledge
• Filled by the client on the portal or in session, and the channel recorded either way

Group Sessions

One note written once and filed to each attendee as their own document.

• One authored source, one filed document per attending client
• A private field is absent from another attendee’s document, not hidden inside it
• Filed to the people who attended, not to everybody who was booked

Recall & Follow-up

A due date a clinician sets when a session ends, acted on when it arrives.

• A recall is a date and a reason, created at the end of a session
• It invites; it never books
• Due recalls appear on the clinic digest before any message is sent automatically

ICD-10-CM Coding

Diagnostic codes where the billing needs them, searchable rather than typed from memory.

• Searchable ICD-10-CM chapters and codes
• A code recorded on the client and carried onto orders and invoices

One Form Builder

One question list in the product, and the three things it does not carry on its own: a stable answer key, per-question visibility, and a flag for the one number that may leave the ciphertext.

• The product had grown four builders — the note template’s typed fields, the scheduler’s own questions, monitoring items, and the survey behind the intake form
• Four builders is four places to add a question type, four renderers, and four answers to “where did that answer go”
• A question list is authored in survey.survey and nowhere else

Booking Questions in Survey

A schedule’s questions designed in Survey and filed encrypted, so the booking scheduler can stay a scheduler.

• A scheduler names a survey, and the public booking page renders it with the one renderer
• Answers are filed into an encrypted document against the booking
• The scheduler’s own question model stays, and should: a phone number, a reference, a consent tick, and the ones that write straight onto the contact record where a receptionist has to read them

Psychology Forms Library

The scanned psychology form pack as searchable records, with an optional live form once a scan is turned into one.

• The scanned pack loaded as records carrying their OCR text, so a form can be found by what is written on it
• A taxonomy by the system each form targets
• An optional survey, created when a scan is turned into a live form

Expert Pay

Session pay terms on the employee contract, and the payment cycle that settles them. Nothing is recomputed at payout time — each session froze its own split when it was booked.

• Four pay types: monthly salary, hourly rate, fixed fee per session, or a percentage of each session
• Terms held on the contract version, so the history is dated and one is in force at a time
• Payment cycles — weekly, fortnightly, monthly or quarterly — anchored on the calendar or the contract start

Expert Pay — E-Sign

Sends engagement contracts for signature from the record they belong to, and keeps the signed history on that record.

• Send a contract for signature from the contract itself
• Every request kept against that record as its history
• Session pay can be withheld under a contract nobody has signed yet

Expert Plans

Independent experts rent the platform on a plan we build. This module holds the plans, the subscriptions, and the rules that say what a subscription’s state lets an expert do.

• Plans carry a channel — practice, marketplace or both — monthly and yearly prices, and rate lines written as sentences
• A plan’s feature switches are read from the installed modules rather than typed in
• A subscription copies the plan’s rates and features when the expert signs and never reads them back, so a price change tomorrow leaves today’s subscriptions alone

Expert Attribution

Who brought each client to each expert — the one fact every fee an independent expert pays depends on, and the one the platform did not record.

• One row per expert-and-client pair, carrying the source and the owner: the expert’s client, or a platform client
• Ownership is set at first contact and changed by nothing except a staff transfer, with a reason
• The expert’s short link, /e/<the expert’s code>: a person following it registers and becomes that expert’s client

Expert Collection

When the expert takes the client’s money, the expert owes the company its share. A monthly run that invoices them for it and follows it to paid.

• With experts approving orders and sending payment links, the quotation, the invoice and the pay page carry the expert’s own business name, address and VAT as the seller
• Whether the expert collected is frozen on the session at booking, beside the share split, so changing the setting tomorrow does not reach back into last month
• No new formula: the company share already says what the company keeps, and if the expert is holding the cash that is the number they owe

Platform Feature Catalogue

The list of things the installed modules can do, declared by each module itself, for plans to switch on and off.

• Nobody types the catalogue in: a module with something worth selling ships one feature record per capability
• Odoo creates those records when the module is installed and deletes them when it is uninstalled, so the catalogue always describes what this database can actually do
• No scan, no sync job, and no second list beside the module list to fall out of step with it

Secure Documents

The service itself. A model adopts it in one line and gains its documents, a count, and a filing dialog that says in plain language who will be able to open the result before it is stored.

• Encrypted at rest with a key of its own, stored outside the Odoo filestore and never served through /web/content
• Access by explicit rules, default deny: a matching allow rule and no matching deny rule, every time
• Being an administrator, a manager, or the person who filed it grants nothing by itself

Secure Documents: Encryption

The cryptographic layer, kept as a module of its own so key management can be reviewed and audited without reading the rest of the application.

• AES-256-GCM envelope encryption: a random data key per document version, wrapped under a deployment key
• The key encryption key is never stored in the database
• Ciphertext in a directory of its own, outside the filestore

Secure Documents: Portal

Where a person reads the documents that have been shared with them about themselves, at /my/documents — and only those.

• A subject sees a document when a subject access rule grants it and nothing denies it — never merely because it is about them
• Psychotherapy notes, sealed documents and documents under a current withholding decision are never shown, whatever their rules say
• One filter used by every route, so there is only ever one definition of who may see what

Secure Documents: Contacts

Files secure documents against contacts — the commonest subject, since the person a document is about is usually the person it is filed against.

• Adds the secure document service to res.partner
• Installs itself once both sides are present, and uninstalls without touching either
• A bridge per application, so adopting the service on a contact does not pull in unrelated apps

Secure Documents: CRM

Files secure documents against opportunities — a due-diligence pack is nothing clinical, and has exactly the same requirements.

• Adds the secure document service to crm.lead
• Encrypted, rule-gated and logged on every read, like any other secure document
• Installs and uninstalls cleanly and independently of the other bridges

Secure Documents: Employees

Files secure documents against employee records — a disciplinary file or an occupational health report is something a manager files and most of HR must not be able to open.

• Adds the secure document service to hr.employee
• Default-deny access, so an HR role does not open a file by virtue of being an HR role
• Installs and uninstalls cleanly and independently of the other bridges

Secure Documents: Project

Files secure documents against tasks — a confidential contract or a signed deliverable held where the work is tracked.

• Adds the secure document service to project.task
• Installs itself once both sides are present, and uninstalls without touching either

Secure Documents: Sales

Files secure documents against orders — a signed agreement, or a customer’s identity documents, held against the sale they belong to.

• Adds the secure document service to sale.order
• Installs itself once both sides are present, and uninstalls without touching either

Remote Key Authority

Optional: move the key-encryption key off the Odoo host, so a copy of the database is not a copy of the documents.

• Document keys wrapped and unwrapped through a remote authority rather than locally
• The key-encryption key never sits on the machine serving the application
• Switched on per deployment; the local backend stays available and unchanged

Clinical Records

Resolves the care team. A therapist reaches the records of the people on their own caseload, not the clinic’s — which is what makes the minimum-necessary standard enforceable rather than aspirational.

• Care relationships — clinician to client, with a kind, a start and an end
• Access ends when the relationship does, after a grace period long enough to finish outstanding notes
• Clinical roles that decide what part of the application someone reaches, never what they can open

Clinical Records: European Union (GDPR)

The GDPR layer: the rights and governance machinery HIPAA has no equivalent for, which is why a US-standard build does not cover the EU.

• Lawful basis recorded per document type — Art. 9(2)(h) for treatment records, not consent
• Erasure (Art. 17) carried out by destroying the key, so the right is honoured without erasing the evidence of what was held
• An erasure assessment, and nothing destroyed while a legal hold or retention period stands

Clinical Records: Notice acknowledgement by e-signature

A bridge, not a build — joins a signed privacy notice to the acknowledgement record, so the file can answer which version they actually saw.

• A completed signature writes the acknowledgement, once — a webhook delivered twice must not make the count of who is outstanding wrong
• The signature request names the notice version, because that is the only question an acknowledgement gets asked
• A pen on a form at reception is still a written acknowledgement; the bridge adds a path rather than replacing the ordinary one

Clinical Records: United Kingdom

UK GDPR and the Data Protection Act 2018 on the same technical core — with the serious harm test built as a workflow rather than as a flag.

• The serious harm test (DPA 2018 Sch. 3 Pt. 2) recorded with who decided, when, over which documents and why
• Only takeable by someone holding a current care relationship, which the system checks rather than assumes
• Appears in a review queue before it expires, and lapses on its own at six months

Clinical Records: Governance

The administrative safeguards — the half of HIPAA that is not about encryption, and the half enforcement cites most.

• The risk analysis as an exercise with a period, a scope and a method, separate from the register of what it found — so next year can be compared with this one
• Each risk carried into the next assessment with a link back, because a register that starts blank every year loses the record of what was decided
• The inherent rating computed and the residual rating deliberately not — a residual worked out by subtracting a control score is a fiction that says the same thing about a control tested last week and one written in a policy

Clinical Records: United States (HIPAA)

The HIPAA layer. The separation of psychotherapy notes holds in the storage rather than resting on the access rules being right.

• The designated record set (45 CFR 164.501) marked per document type, so a subject access response cannot include what is out of it
• Psychotherapy notes in their own key namespace — the key that opens the ordinary record does not open them
• A subject grant on notes refused at every path, including a direct write to the rule table

Clinical Records: Germany

The German retention period, as a rule the document service counts rather than a line in a policy nobody applies.

• § 630f BGB: ten years after last contact, seeded as a retention rule
• Scoped to this module rather than to the whole EU pack, because the period is national

Clinic: Norway

The Norwegian rules the GDPR layer does not cover, each one sitting where the action happens rather than in a policy: publishing a profile, confirming a payout run, disclosing something to a parent.

• Pasientjournalforskriften § 14: the patient reads every access to every record about them, including the records they are not shown — by type, never by title
• A retention kind with no disposal date at all, because Norway keeps records while they are needed; the years are a review interval and a person decides, with a reason
• A journal hand-over to a successor, Norsk helsearkiv or Nasjonalarkivet, built at the moment of download, recorded as a disclosure per document, and downloadable once

Clinic: Finland

The roles Finnish law makes a provider name, and the duties hanging off each one. Independent of the Norwegian pack — both switch on from the company country, so one database can hold both.

• Licensed and protected-title professionals kept apart, because they are different rights: psykoterapeutti is a protected title in Finland and a free word in Norway
• Terhikki number, the date of the employer check and whether it was a register lookup or the decision document; a typed number counts as declared, not checked
• A service unit with its own registration, and the vastuuhenkilö as a designation per unit, so a fortnight with nobody answering for it is reported

Clinic: Switzerland

Switzerland splits the qualification from the permission to practise, counts insured sessions against a doctor's order, and binds the supplier to the same criminal secret as the practitioner. Three things the core cannot express, and nothing else.

• The federal title is not the licence: a practice permit is cantonal, one per canton, each with its own expiry, so a practitioner may hold the name in Switzerland and the right to work in only one place
• A profile using a protected title is refused publication without both a checked PsyReg number and a current, checked cantonal licence — and the refusal says which of the two is missing
• Where a title is checked and no licence is, the public status says so rather than implying one; an unverified market is not served by a listing that reads like a verified one

Compliance Health Check

A fixed list of questions asked of the deployment itself. Most of the checking already existed and was scattered; this is the page that reads it in one place.

• A registry of checks, a runner on a schedule, and a report over both
• Only what is wrong is reported: a check that passes says nothing, so the page is empty when the deployment is sound
• Each finding names the rule it came from and the record it was found on

E-Sign — Core

The signature service itself: a portal signing ceremony, jurisdiction policies, and a hash-chained audit trail. Self-hosted, so no document leaves the estate to be signed.

• A portal signing ceremony with identity and intent captured at the moment of signing
• A hash-chained audit trail nobody can edit or delete
• Jurisdiction policies governing what a valid signature requires

E-Sign — Contracts

Who was empowered to sign for a counterparty, and whether their credential is still valid — checked rather than assumed.

• Authority to bind tracked per counterparty signatory
• Signed agreements kept as records with a term
• Practitioner credentials chased before they lapse

E-Sign — Health

What a clinical signature needs beyond a name: capacity, authority to sign on somebody’s behalf, supervision, and consent that can be withdrawn.

• Capacity attestation recorded at the point of signing
• Signing on behalf of a client, with the authority recorded
• Supervisor co-signature where the service requires it

E-Sign — Health (United States)

The elements HIPAA requires of an authorization, validated rather than trusted to a template.

• Validation of the required elements of a HIPAA authorization
• 42 CFR Part 2 material segregated from the rest
• The accounting of disclosures a covered entity must produce on request

E-Sign — HR

A Request Signature action on applicants and employees, so an offer or a policy is signed where the person already is.

• Request Signature on an applicant record
• Request Signature on an employee record
• Requests kept against the record as its history

E-Sign — Sales

A Request Signature action on quotations and purchase orders.

• Request Signature on a sale order
• Request Signature on a purchase order
• The signed document kept against the order

E-Sign Agreements

Puts signature templates where the clinic sells: pinned to a professional or a service, sent automatically on purchase, and visible as a status.

• E-sign templates pinned to an expert or to a service
• Sent on purchase, without anybody remembering to send it
• Signed status shown to professionals in the portal and in the mobile app

Secure Sessions

Ends a session nobody is using. 45 CFR 164.312(a)(2)(iii) asks for termination after a predetermined period of inactivity, and leaves the period to you — so it is a setting, with the enforcement on the server rather than in the browser.

• Idle period, warning period and an absolute ceiling, set per company
• Checked on the server on every authenticated request, so switching off the browser timer buys nothing
• A warning before the session ends, so nobody loses a half-written note to a control meant to protect them

AI Bridge

Connects Odoo Community to any large language model, behind an interface — so the vendor can change without the business logic knowing.

• Providers configured per deployment, with the credential held outside the application code
• Agents defined as prompts with the tools they are allowed to call
• Tool calling, so a model can act rather than only answer

User Extension

Converting a user between internal and portal by hand means editing access rights in the right order and remembering the side effects. This makes it a button.

• A User Type field on the user form, the list and the search filters
• Convert to Internal and Convert to Portal buttons on the user form
• A Convert User Type action on the Users list, for several users at once

Public Site Shell

Header, footer and the sign-in page on one layout, named after the company on this database.

• One layout for the header, the footer and the sign-in page
• The name shown is the company on this database, not a value typed into a template
• Logo address and a custom copyright line are system parameters, also editable under Settings → Website → Public brand

Contracts — Core

The agreement, its parties, its structured terms with provenance, its versions, and a workflow of configurable stages mapped to five fixed phases.

• Agreements with parties, structured terms and term provenance
• Versions, so "what did it say in March?" stays answerable
• Configurable stages mapped to five fixed phases

Contracts — Negotiation

Built so that review is directed at what changed and what deviates, and never at unchanged boilerplate — which is where contract systems are usually abandoned.

• A clause library linked to structured terms, so accepting a fallback sets the term it carries
• Playbooks, rounds, issues and recorded deviations
• Meetings as negotiation rounds in their own right, keeping the reasoning and the positions

Contracts — Approvals

Approval decided on more than one axis. Treating it as seniority alone is the common design error: a standard NDA at any value needs nobody senior.

• Approval on value, deviation, contract type and risk
• Deviation as an axis in its own right rather than a modifier on value
• Approval by a delegate always recorded as such — "on behalf of" is a different fact

Contracts — Amendments

Records what an amendment changed, not merely that it exists.

• Executing an amendment closes the term rows it varies and opens new ones at the effective date
• Anything derived from a changed term recalculates, and the movement is shown before execution
• Conflicting amendments detected at execution

Contracts — Obligations and dates

Signature is the beginning of the obligation, not the end of a workflow. This carries what happens afterwards.

• Obligations in both directions, with evidence where evidence is required
• Derived dates calculated from terms rather than typed, and moved when their driver terms move
• An escalation ladder that does not rely on reminding the person who has already not acted

Contracts — Projects, time and cost

Two costs, kept apart: what a contract cost to win, and what it costs to deliver. Combining them produces a number that answers neither question.

• Negotiation effort recorded as overhead, whether or not the contract signs
• Delivery cost recovered against the contract value
• Contracts linked to projects many-to-many with a role, because one project field breaks on the first framework agreement

Contracts — Billable time and fee bases

What an hour is worth, what the fee allows, and the four figures that need both.

• Charge rates, a billable flag and a billed state on recorded time
• Fee bases stated on the contract
• Recovery — billed against the value of time recorded

Contracts — Counterparty portal

The fourth exchange channel: the counterparty reads the current version here, comments, and uploads their markup as an inbound round.

• The counterparty opens the current version, comments on it and returns their markup
• Markup arrives as an inbound round with the file attached, not as an email somebody must remember to file
• Nothing internal is visible — not positions, deviations, approvals, the playbook or internal notes

Contracts — E-signature bridge

How a contract uses the signature service. Completion is the event that starts everything else.

• Approvals must be complete before a version can be sent
• The signatory’s authority to bind checked against their credential
• The version locked when it goes out, so every later claim about what was signed is provable

Contracts — Secure storage bridge

Encrypting every contract makes the system unusable; encrypting none makes it unsafe. So confidentiality is a level on the agreement.

• Only agreements marked secure route their documents into the secure document service
• Per-version encryption under a key held outside the database
• Default-deny access, and every read logged before content is returned

Contracts — Reports

Flag lists that should be empty, and the management views worth arguing over.

• A flag list holds only what is out of line — an empty list is the good outcome
• A flag whose model is not installed reports as not applicable rather than failing
• Uncapped liability shown as a list, never as a number added into a total

Legal Reports — clients, lawyers and management

Three readers, one arithmetic. The same numbers computed once and rendered three ways, rather than re-derived per screen where they would drift apart.

• A single deadline view: derived contract dates, obligations both ways, actions agreed at meetings and delivery deadlines
• Project control: revenue, labour, committed cost, margin and estimate variance, as a stored view so it can be grouped
• A client-facing view of where the work has got to and what is owed

Contracts — IP rules

Two rules, and only two — the ones that compare records and therefore cannot be expressed as configuration.

• A sublicence’s territory must sit inside its parent’s
• Two exclusive licences must not overlap
• Kept separate from the IP pack, so a business can install the contract types without the checks

Contracts — Legal rules

Conflict checking at contract intake, the same as matter opening. It gates the stage transition; it does not warn.

• A counterparty checked against existing clients, opposing parties on live matters, and known affiliates
• Gates the stage transition rather than raising a warning that can be dismissed
• The check itself immutable once recorded — who ran it, over what scope, and what they found

Contracts — General pack

The starting pack. Install the core and this, and a business can run contracts on day one without configuring anything.

• NDAs, master agreements, statements of work, services, consultancy, supply and purchase
• The terms each type carries and the workflow it moves through
• Gates that stop a contract reaching signature half-formed

Contracts — HR pack

Employment, contractor engagement, consultancy and settlement.

• Agreement types, term types, clause library and playbook for employment contracting
• Obligation templates for notice, probation and post-termination terms
• Settlements default to secure — every word matters, and a regulator later asks about them

Contracts — Legal pack

Law firms — contracts for clients and with them — and in-house legal departments. The same system serves both jobs with sharply different defaults.

• Engagement letters, retainers and counsel instructions
• A clause library with the regulated wording marked mandatory
• A firm’s engagement letter defaults to confidential and itemised

Contracts — IP pack

Licensors, patent and trademark holders, technology transfer offices, universities and brand owners.

• Licences, assignments and options as agreement types, with licence term types
• Clause library, playbook and obligation templates
• No asset register, deliberately — a patent’s prosecution history belongs to the portfolio system that already holds it

Contracts — Property pack

Leases, agreements for lease, licences to occupy, sales, easements and the deeds that hang off a lease.

• Break dates as date-driving terms, because a break right expires in silence
• The notice window as an obligation derived from the break date, and both escalate
• Rent review, service charge and reinstatement terms

Contracts — Finance pack

Debt documents: facility agreements, guarantees, security, intercreditor and subordination deeds.

• Financial covenants as structured terms, with derived test dates
• The compliance certificate as an obligation with evidence required
• "Which facilities are tested this quarter, and on what numbers?" becomes a question with an answer

Contracts — Construction pack

Main contracts, subcontracts, professional appointments, collateral warranties and the instruments around them.

• Built around the chain: a main contract promises a date only the subcontracts can deliver
• Back-to-back terms held as structured terms so they can be compared down the chain
• Liability that the subcontracts and the professional indemnity cover have to carry

Contracts — Data protection pack

Data processing agreements, business associate agreements and sub-processor terms.

• DPA, BAA and sub-processor agreement types with the terms they carry
• The breach-notification window as its own term, because it is measured in hours
• Audit response and sub-processor notice as derived dates

Sign in and sign up

Getting into the app, and the age gate that decides whether an account may be used at all.

• Splash and first-run routing, so a returning user lands where they left off
• Registration and sign-in against the gateway, with tokens held in secure storage
• Password reset by email

Identity and age verification

The check that lets somebody transact, including the states a person sits in while a human reviews what the automatic step could not settle.

• Guided introduction explaining what is being asked for and why
• Face scan capture, and document check as the alternative path
• Borderline result and under-review states, so the person is never left guessing

Home — content feed

The first tab. A ranked feed of articles, videos and updates, plus the publishers behind them.

• A ranked content feed served by the gateway
• Content detail with images and rich text
• Publisher profiles, so a reader can follow a source

Discovery and assessments

Self-guided tools: assessments a person takes themselves, their results, and the partner features built around them.

• Take an assessment, and read the results
• The delights map — a personal view, and a shared one
• Add, join, invite and compare partners

Finding a professional

The directory as a client meets it: browsing, comparing, saving, asking, and the chat that follows.

• Browse and filter the directory of professionals
• A profile with qualifications, languages, services and reviews
• Saved professionals — My Experts

Services

What can actually be booked, with the price, the duration and whether it is online or on the premises.

• Browse services offered across the clinic
• Service detail with price, duration and delivery mode
• Straight into booking or purchase from the service

Shop and checkout

Buying — a single session, a package, or a product. This is where the credit a client later spends comes from.

• Product catalogue and product detail
• Cart, checkout and the service agreement accepted at purchase
• Order confirmation, and the order history behind it

Booking a session

Spending a credit on a specific time in a specific diary — and everything the client sees about it afterwards.

• Create a booking against real availability, in the client’s own timezone
• The bookings list, with every status a session can have
• Booking detail: join link, location and room, reschedule and cancel

Questions, tickets and partners

Asking in public, asking in private, and the people a client chooses to share progress with.

• A public question feed, and asking a question before committing to anything
• Question detail with the professional’s own answer
• Support tickets — raise one, track it, read the replies

Profile — the client hub

The third tab, and the answer to most support questions. Everything the app knows about the person, on one screen.

• Booked meetings and meeting history, with feedback and session reviews
• Credits, purchased sessions and favourites
• Billing address, invoices, invoice detail, payment methods

Profile — the expert practice

The same tab, seen by a practitioner. This is what makes a whole practice runnable from a phone rather than from a desk.

• Availability: weekly hours, and dated schedule exceptions
• Clients’ chats, and the client history behind each conversation
• Submit a session report from the session it belongs to

AI assistant

A conversational assistant in the app, streamed through the gateway so no model credential ever reaches the device.

• A chat screen with streamed responses
• Conversation history, so a thread can be picked up later
• Routed through the gateway’s AI interface, which resolves to a real provider or a mock

Settings, privacy and legal

The controls a person expects to find, including the ones a regulator expects them to be able to find.

• App settings and language selection across 23 locales
• Privacy settings, and which notifications arrive on which channel
• Security settings, including device sessions

App core

What every feature above is built on. Not a screen, but the reason the screens behave consistently.

• Networking against the gateway, with token refresh and error handling in one place
• Secure storage for tokens and secure device state
• Routing, so a notification can open the exact screen it refers to

Identity and account

Brokers login against the business core and issues short-lived tokens of its own. The app never holds a core credential.

• Sign in, sign up, refresh and sign out, with JWT issued by the gateway
• The current user and their profile
• Device registration, so push notifications reach the right handset

Directory and catalogue

Everything a client browses before they spend anything, served fast and cached where it is expensive.

• Professionals, their profiles, availability and services
• Service categories and bookable products
• Reviews and ratings, with moderation state respected

Booking and money

The transactional half. Purchase, credit, booking, invoice and payment, each mapped onto the business core rather than reimplemented.

• Create, reschedule and cancel a booking, with the policy applied by the core
• Orders and the credits they produce
• Invoices and invoice documents

Content and community

The read-heavy half: what a person browses when they are not booking.

• The ranked content feed and content detail
• Public questions and answers
• Discovery, assessments and their results

Messaging and realtime

The WebSocket hub. Chat, presence, AI streaming and signalling for voice and video, on one connection.

• WebSocket connection management and presence
• Chat between client and professional, and group channels
• Signalling for voice and video calls

Documents and media

Files, held so that the app never talks to storage directly and nothing is served from a guessable URL.

• Secure document access, honouring the core’s access rules rather than re-deciding them
• Media upload and retrieval, proxied through the gateway
• Images resized and cached, so a directory listing is cheap on a phone

Support, configuration and AI

The remainder: raising a ticket, asking for a consultation, telling the app what this deployment has switched on, and talking to a model.

• Support tickets and their replies
• Consultation requests
• Runtime configuration, so the app shows only the features this business enabled

Provider interfaces (mock-first)

Four feature flags, each resolving to a real provider or a mock. It is why the estate can be demonstrated, developed and tested with no external account at all.

• DATA_SOURCE — the Odoo business core, or a mock dataset
• PAYMENTS — a real provider, or a mock that behaves like one
• NOTIFICATIONS — Firebase Cloud Messaging, or a mock