Pilot Agreement

Mealward — Opal HealthCare

Schedule to the Master Services Agreement

Version: 1.0 — DRAFT (lawyer review required) Effective date: {{PILOT_START_DATE}}

1. Parties and basis

1.1 Provider. Luke Ferguson trading as Mealward, ABN 17 977 307 913, of 2 Northumberland Court, Carrum Downs VIC 3201, Victoria, Australia ("Mealward").

1.2 Customer. {{CUSTOMER_LEGAL_ENTITY}}, ABN {{CUSTOMER_ABN}} ("Customer").

1.3 Relationship to the MSA. This Pilot Agreement and Statement of Work (this "Pilot Agreement") is a Schedule to, and is incorporated into and governed by, the Master Services Agreement between the parties dated on or about the Effective Date (the "MSA", at docs/legal/MASTER-SERVICES-AGREEMENT.md). Capitalised terms not defined here have the meanings given in the MSA. This Pilot Agreement does not duplicate MSA clauses — it deviates from the MSA only where expressly stated (particularly the pilot liability cap in clause 10 and the pilot service levels in clause 7). In all other respects the MSA governs. In the event of inconsistency, the order of precedence is: (i) this Pilot Agreement (for express deviations only); (ii) the MSA and its incorporated schedules.

1.4 Effective date. This Pilot Agreement takes effect on {{PILOT_START_DATE}}.

2. Pilot scope

2.1 Facility and wing. The pilot covers one facility: {{PILOT_FACILITY_NAME}}, one wing: {{PILOT_WING_NAME}}, for approximately {{PILOT_RESIDENT_COUNT}} residents.

2.2 Duration. The pilot runs for 30 calendar days from the go-live date (Day 1), plus a 5-day setup grace period (Days −5 to −1). The total pilot window is 35 days.

2.3 Services in scope. The full Mealward platform for the pilot wing, including:

Meal ordering at point of service on phones, tablets, iPads, laptops, or kitchen PCs (anything with a modern browser);
kitchen production view;
PCA delivery view;
IDDSI and dietary-requirement management;
HEDL (Hospitality Extra Daily Living) revenue module; and
Reports tab, including the HEDL what-if simulator.

2.4 Services out of scope. The following are expressly excluded from this pilot:

Salesforce integration (scoped as Phase 2 — see Section 9);
bespoke reporting outside the standard Reports tab;
hardware procurement (iPads remain Customer-owned or Customer-arranged); and
any facility or wing beyond {{PILOT_WING_NAME}} at {{PILOT_FACILITY_NAME}}.

3. Implementation plan

Days −5 to −1 — setup. Mealward provisions Customer's tenant on the production environment; seeds the menu cycle from Customer's existing meal plan; imports the resident roster from a Customer-supplied CSV (see Appendix B); and creates admin and PCA accounts for the pilot wing.
Day 1 — go-live. Mealward's founder attends on-site for the first breakfast, lunch, and dinner service. Mealward provides real-time support throughout all three meals.
Days 2–7 — early stabilisation. Daily check-in calls (30 minutes). Mealward triages any UX or workflow defects and targets same-day fixes for confirmed defects.
Days 8–30 — steady state. Weekly check-in calls (60 minutes). Mealward responds to any P1 incident within 4 business hours (clause 7.2).
Day 31 — pilot review. A formal pilot-review meeting assesses KPIs (Section 4) and the parties decide on conversion to paid subscription (Section 5).

4. Success metrics (KPIs)

The parties agree to measure pilot success against the following KPIs. If the quantitative KPIs in clauses 4.1–4.3 are not met at the Day 31 review, Customer has the unilateral right to decline conversion to a paid subscription with no fee, penalty, or further obligation.

4.1 Time saved per resident per day on dietary administration. Target: ≥ 8 minutes saved per resident per day compared with the paper-based baseline. Measurement: PCA self-report time-and-motion study at Day −1 (baseline), Day 15, and Day 30.

4.2 IDDSI and dietary error rate. Target: ≥ 70% reduction in IDDSI and dietary errors compared with the paper-based baseline. Measurement: Manual audit of meal-tray composition against each resident's dietary profile, sampling 50 trays at Day −1 (baseline), Day 15, and Day 30.

4.3 HEDL revenue captured per resident per day. Target: An absolute dollar figure agreed in writing by the parties at the pilot kick-off meeting with {{PILOT_FACILITY_NAME}}'s management. Measurement: Average HEDL revenue per resident per day at {{PILOT_WING_NAME}}, across the final 14 days of the pilot.

4.4 Carer satisfaction (qualitative). Target: Net positive — more PCAs and GSOs in the pilot wing respond "would recommend" than "would not recommend" on a closing survey. Measurement: Survey of all PCAs and GSOs in {{PILOT_WING_NAME}} conducted at Day 30.

5. Pricing and conversion

5.1 Pilot fee. The pilot fee is $0 (zero) for the 30-day pilot period. There is no setup fee and no implementation fee. The on-site go-live support described in Section 3 is included.

5.2 Automatic conversion to paid subscription. If Customer does not give Mealward written notice of non-conversion by the end of Day 30, this Pilot Agreement automatically converts to a paid Subscription Schedule on Day 31. Customer chooses one of the following fee models in writing at conversion:

Fee model A — per-bed monthly fee: {{PER_BED_MONTHLY_AUD}} AUD per bed per month (pilot wing only at launch; expanded on each subsequent Order Form), billed monthly in arrears, minimum 12-month initial term; or
Fee model B — HEDL revenue share: {{HEDL_REVENUE_SHARE_PCT}}% of all HEDL line items billed through Mealward, in lieu of the per-bed fee.

The two models cannot run concurrently. Price escalation and invoicing terms on conversion are governed by MSA clauses 4.2 and 4.6.

5.3 Notice of non-conversion. Customer may elect not to convert by giving written notice to luke@mealward.com no later than the end of Day 30. No fee is due on non-conversion.

6. Data handling

6.1 Primary data handling. All Customer data collected under this Pilot Agreement is hosted in AWS ap-southeast-2 (Sydney). The Data Processing Agreement (docs/legal/DATA-PROCESSING-AGREEMENT.md) applies in full, including the Technical and Organisational Measures in Schedule 2 of the DPA and the sub-processor list in Schedule 3.

6.2 Privacy Act and Australian Privacy Principles. Resident personal information — including health information such as IDDSI levels, allergies, dietary requirements, and consumption records — is handled in accordance with the Privacy Act 1988 (Cth) and the Australian Privacy Principles. Customer remains the APP entity primarily responsible for that information. The parties' respective obligations are set out in the DPA.

6.3 Data at end of pilot.

On conversion to paid subscription: Customer data remains on the platform and transitions to the Subscription Schedule.
On non-conversion or termination: All Customer data (including resident personal information) is deleted from active systems within 30 days of the pilot end date. Backup copies roll off within a further 90 days in accordance with DPA clause 10. Mealward provides a signed deletion certificate within 5 business days of completing deletion.

6.4 No use of pilot data for AI training. Mealward will not use Customer pilot data to train any third-party AI model. Mealward may use anonymised, aggregated metrics derived from the pilot (for example, average time-saving statistics across pilots) for product improvement, but will never process or disclose identifiable resident data or identifiable operational data for that purpose.

6.5 Security and compliance cross-references. The Information Security Policy (docs/legal/INFORMATION-SECURITY-POLICY.md) and the Aged Care Compliance Mapping (docs/legal/AGED-CARE-COMPLIANCE.md) describe how Mealward's controls support Customer's obligations under the Aged Care Act 2024 / NACA (commenced 2025) (Cth) and the Strengthened Aged Care Quality Standards, including Standard 4 (care delivery) and Standard 6 (governance and information management).

7. Service levels during the pilot

7.1 Uptime target. The uptime target during the pilot is 99.5% Monthly Uptime Percentage, measured in accordance with the SLA (docs/legal/SERVICE-LEVEL-AGREEMENT.md). This reflects the pilot nature of the engagement. The standard production SLA terms apply in full on conversion to a paid Subscription.

7.2 Incident response. The following response targets apply during the pilot:

Priority	Definition	First-response target	Mitigation target
P1 — Critical	Full outage during a meal service; or any patient-safety bug in allergy or IDDSI display	4 business hours	Same business day
P2 — Partial impairment	Major feature broken with no workaround; core ordering still functions	Next business day	Best effort
P3 — Cosmetic	Minor or cosmetic issue	Tracked; no SLA	Next available release

"Business hours" means 09:00–17:00 AEST, Monday to Friday, excluding Victorian public holidays. The patient-safety override in SLA clause 6.3 applies during the pilot without modification: any incident Mealward reasonably believes may result in an unsafe meal being served is treated as P1 immediately and triggers notification to Customer's nominated clinical contact.

7.3 Founder on-call. Mealward's founder is personally on-call during all meal services for the first 14 days of the pilot.

8. Governance

8.1 Pilot Steering Group. A Pilot Steering Group comprising one representative from Mealward (the founder) and two from Customer (one operations, one IT) meets weekly during the pilot. All material changes to pilot scope require written agreement through the Steering Group and are of no effect unless so agreed.

8.2 Customer pilot contact. Customer designates a single day-to-day pilot contact ({{CUSTOMER_PILOT_CONTACT}}), who is the primary point of contact for daily coordination, issue escalation, and PCA feedback consolidation.

8.3 Notices. Notices under this Pilot Agreement are given by email in accordance with MSA clause 16.

9. Phase 2 — Salesforce integration (post-pilot)

9.1 Commencement. Phase 2 commences only upon conversion to a paid Subscription Schedule under clause 5.2. It is not in scope for the pilot.

9.2 Scope. Phase 2 delivers integration in two stages:

Stage A — one-way sync: resident profile fields, meal-complaint events, and admission/discharge triggers flowing from Mealward to Salesforce; and
Stage B — two-way sync: incoming case routing and admission triggers flowing from Salesforce to Mealward.

9.3 Effort. Estimated development effort is 80–120 hours. Scope is refined after a one-hour technical session with Customer's Salesforce administrator at pilot Day 14.

9.4 Cost. The Phase 2 integration cost is absorbed into the first 6 months of the paid Subscription. There is no separate integration fee.

9.5 Timeline. Delivery in 4–6 weeks from Subscription start, subject to Customer providing sandbox access and timely participation in the Day 14 technical session.

9.6 Technical approach. The integration uses Mealward's public REST API and webhooks. The technical approach is documented in docs/outreach/salesforce-integration-positioning.md.

10. Liability and indemnities

10.1 Pilot liability cap. For the duration of the pilot period only, each party's aggregate liability arising under or in connection with this Pilot Agreement is capped at AUD 1,000 (one thousand Australian dollars). This reduced cap reflects the zero-fee nature of the pilot. The carve-outs in MSA clause 12.3 (wilful misconduct, fraud, confidentiality breaches, and liability that cannot be limited by Australian law) continue to apply.

10.2 Post-conversion cap. On conversion to a paid Subscription under clause 5.2, the liability cap reverts to the MSA cap (MSA clause 12.2 — typically the fees paid in the 12 months preceding the claim).

10.3 IP indemnity. Mealward indemnifies Customer against third-party claims that the Mealward platform, when used as permitted by this Pilot Agreement, infringes Australian intellectual property rights, on the terms in MSA clause 13.1.

10.4 Customer indemnity. Customer indemnifies Mealward for losses arising from: (a) the accuracy and completeness of resident data provided by Customer; and (b) the lawful basis for Customer processing and disclosing resident personal information to Mealward under the Privacy Act 1988 (Cth), on the terms in MSA clause 13.2.

10.5 Australian Consumer Law. Nothing in this clause limits rights under the Australian Consumer Law that cannot lawfully be excluded (MSA clause 11).

11. Termination

11.1 Termination for material breach. Either party may terminate this Pilot Agreement on 5 business days' written notice if the other party commits a material breach and fails to cure within that notice period.

11.2 Termination for convenience by Customer. Customer may terminate for convenience at any time during the pilot by giving Mealward 5 business days' written notice. No fee is due on termination during the free pilot period.

11.3 Termination by Mealward for obstruction. Mealward may terminate this Pilot Agreement on 5 business days' written notice if Customer materially obstructs the pilot — for example, by withdrawing system or WiFi access needed to run the Service, or by preventing all PCA participation — after written notice and a reasonable opportunity for Customer to remedy.

11.4 Effect of termination. On termination for any reason: Customer's right to access the Service ends on the effective date of termination; and Section 6 (data handling) governs data return and deletion.

12. Signatures

This Pilot Agreement is entered into as of the Effective Date stated on the cover page.

For Luke Ferguson trading as Mealward:

Name: _________________________________ Title: Founder Signature: ____________________________ Date: _________________________________

For {{CUSTOMER_LEGAL_ENTITY}}:

Name: _________________________________ Title: ________________________________ Signature: ____________________________ Date: _________________________________

Appendix A — Pre-flight checklist (Mealward internal — not for Customer)

Complete all items before pilot Day 1.

Tenant provisioning: Customer's tenant provisioned on the production environment; row-level security confirmed for {{PILOT_FACILITY_NAME}} only. Verify no bleed to other tenants.
Menu cycle import: Customer's existing meal plan imported and reviewed for IDDSI-tag completeness and allergen matrix coverage. Confirm all menu items have at least a base IDDSI tag before go-live.
Resident roster import: CSV import completed and validated; privacy review of transferred fields confirmed against DPA Schedule 1; data-sharing instrument signed by Customer before transfer of any personal information.
Admin and PCA accounts: All accounts created; temporary credentials issued and staff notified; MFA enrolment confirmed for all admin accounts.
iPad arrangement: Confirm at kick-off whether iPads are Customer-supplied or Mealward-supplied; ensure sufficient devices are available for the dining room and all service points in {{PILOT_WING_NAME}}.
Network access: Wing-level WiFi tested from iPad; confirm signal in the dining room and all service areas; arrange a mobile-hotspot fallback if WiFi is unreliable.
Day 1 on-site logistics: Parking confirmed; visitor sign-in procedure known; PPE or infection-control requirements checked with the facility manager in advance; facility induction booked.
IT whitelisting: Customer's IT team notified of any Mealward webhook IP addresses or domain endpoints that need whitelisting on the facility network, if applicable.
Paper backup plan: Printed paper run-sheets prepared and physically at {{PILOT_WING_NAME}} before Day 1. If Mealward is unavailable during Day 1, staff revert to paper. Do not remove paper sheets until at least Day 8.
Emergency contact confirmed and shared with Customer: luke@mealward.com / 0418 739 437. Luke Ferguson is the single escalation point for P1 incidents during the pilot.

Appendix B — What Customer must provide

Resident roster CSV. Supplied before Day −5. The data-sharing instrument (required under the DPA before any personal information is transferred) must be signed before transfer. Minimum fields: resident name, preferred name, room number, wing, date of birth, IDDSI level (0–7), allergens and intolerances, dietary requirements, and any cultural or religious notes.
Existing meal cycle and menu plan. The current week-cycle menu in any available format (Excel, PDF, or paper scan), supplied before Day −5 so Mealward can import and tag it.
Wing-level WiFi access. Network name and credentials for {{PILOT_WING_NAME}}, confirmed to support the number of iPads in service; provided at least 3 days before go-live so Mealward can test connectivity.
PCA champion. One named personal carer in {{PILOT_WING_NAME}} who will provide daily feedback, participate in the time-and-motion study (Section 4.1), and act as the on-the-ground link between Mealward and the care team.
Designated pilot contact. As per Section 8.2 — one named Customer representative for day-to-day coordination, issue escalation, and sign-off on the Day 31 KPI review.