amber.systems software development schedule

Version 2026-08-18 - last updated 18 August 2026

1. When this schedule applies

1.1 This Software Development Schedule applies where an Order Form or Statement of Work incorporates it for the design, development, configuration, integration, migration, testing, deployment or documentation of bespoke software (Development Services).

1.2 This schedule forms part of the Contract together with the General Terms of Business. Hosted operation, installed-software licensing, ongoing support and security testing apply only where their respective schedules are incorporated.

2. Definitions

In this schedule:

• Acceptance Criteria means the objective criteria stated in the SOW for accepting a Deliverable.
• Bespoke Code means source code created specifically for the Customer under the SOW, excluding Provider Materials and Third-Party Materials.
• Defect means a reproducible material failure of a Deliverable to meet the Specification or Acceptance Criteria.
• Development Environment means a repository, pipeline, system, account or tool used to perform the Development Services.
• Specification means the agreed functional, technical, security and interface requirements in the SOW.
• Third-Party Materials means open-source software, proprietary libraries, APIs, models, platforms, content or other materials owned or controlled by a third party.

3. Statement of Work and discovery

3.1 The SOW should identify:

• objectives, scope and out-of-scope items;
• the Specification and Acceptance Criteria;
• Deliverables, milestones and estimated dates;
• supported environments, platforms and versions;
• Customer Dependencies and assumptions;
• project method, governance and review process;
• Fees and payment stages;
• deployment, migration and handover responsibilities;
• intellectual-property treatment;
• security, testing and data requirements; and
• any warranty, support or maintenance period.

3.2 A discovery, prototype or proof-of-concept phase may intentionally produce uncertain or non-production output. Unless the SOW says otherwise, it is evaluated for learning and feasibility rather than production acceptance.

3.3 We may refine implementation details that do not materially change the agreed requirements. A material change to requirements, architecture, interfaces, supported environment or Acceptance Criteria requires change control.

4. Project governance

4.1 Each party will appoint a project contact with authority to coordinate work and make ordinary project decisions.

4.2 Decisions, assumptions and actions may be recorded in an issue tracker, project board, repository, meeting note or other agreed system. A record becomes contractually binding only where it clearly approves a change, Deliverable or instruction and is made by an authorised representative.

4.3 We will provide progress information at the cadence stated in the SOW or, if none, at reasonable intervals for the project size.

4.4 The Customer must review questions and proposed decisions promptly. We may proceed on a documented reasonable assumption where a decision is overdue and delay would materially affect the project, after giving notice.

5. Customer Dependencies

5.1 The Customer must provide, as applicable:

• timely requirements, content, data, test cases and decisions;
• access to systems, repositories, APIs, environments and personnel;
• licences and authority for Customer-selected Third-Party Materials;
• representative test data that may lawfully be used;
• security, compliance, accessibility and performance requirements;
• acceptance testers with appropriate authority and knowledge; and
• backups, maintenance windows and rollback approval for deployment.

5.2 The Customer is responsible for the accuracy and completeness of requirements and Customer Materials. We are not responsible for a hidden requirement or incompatibility that could not reasonably have been identified from the information provided.

5.3 Production data should not be used in development or testing unless necessary, lawful and expressly agreed. The parties should use synthetic or minimised data where reasonably practicable.

6. Development standards and security

6.1 We will perform the Development Services with reasonable care and skill and follow engineering practices reasonably appropriate to the project, including version control and proportionate review and testing.

6.2 A specific language, framework, coding standard, security standard, accessibility target, platform policy or compliance framework applies only where stated in the SOW.

6.3 We may use reusable Provider Materials, open-source components, automated tooling and artificial-intelligence assistance where appropriate. We remain responsible for the Development Services and will apply the Contract’s confidentiality and data-handling controls.

6.4 We will not knowingly introduce malicious code, undisclosed persistence or a credential intended to give unauthorised access.

6.5 No software can be guaranteed free from defects or vulnerabilities. Any security review, penetration test, formal verification or independent audit must be expressly included.

7. Repositories, builds and environments

7.1 The SOW should state whether source code is developed in a Customer-controlled or amber.systems-controlled repository.

7.2 Where we control the repository during development, we will maintain reasonable access controls and backups and provide the agreed source and history at handover.

7.3 Unless expressly included, we are not required to transfer internal CI runners, secrets, internal prompts, licences, test infrastructure or Provider Materials that are not needed to build or use the Deliverable.

7.4 Reproducible builds, software bills of materials, signed releases, provenance attestations and source escrow apply only where stated in the SOW.

7.5 The Customer must not place live production secrets in an issue tracker, source repository or test fixture where a safer mechanism is available.

8. Third-Party Materials and open source

8.1 We may use Third-Party Materials where reasonably appropriate and compatible with the Specification.

8.2 The applicable third-party or open-source licence governs those materials. Nothing in the Contract reduces rights granted under an open-source licence.

8.3 We will identify material Third-Party Materials in the Deliverable, dependency record or repository where reasonably practicable.

8.4 The Customer is responsible for recurring fees, account terms and licences for a Third-Party Service it selects or contracts for directly.

8.5 We will not knowingly include a copyleft component in a manner that requires disclosure of the Customer’s proprietary source code unless the SOW permits it or the Customer approves the relevant architecture or licence effect.

8.6 A Third-Party Service may change, withdraw or deprecate an interface. Adaptation after acceptance is support, maintenance or change work unless caused by our failure to conform to a requirement existing at acceptance.

9. Changes

9.1 A Change Request should describe the requested change and its effect on scope, architecture, Deliverables, Acceptance Criteria, timetable, Fees, data processing and risk.

9.2 We are not required to begin changed work until the change is agreed.

9.3 Time spent assessing a substantial proposed change may be chargeable where the Order Form permits or the Customer approves it.

9.4 Where an urgent security or compatibility issue requires a protective deviation, we may implement the minimum reasonable change and notify the Customer promptly. Any lasting scope or fee effect will be documented.

10. Testing

10.1 We will perform the tests expressly stated in the SOW. The Customer remains responsible for testing suitability in its real business, regulatory and operational context.

10.2 The Customer must provide representative environments, accounts, test data and dependencies in time for testing.

10.3 A test failure caused by a Customer environment, unsupported third-party change, inaccurate test data or requirement outside the Specification is not a Defect, but we may assist under change control.

10.4 Performance, load, security, accessibility, compatibility and disaster-recovery testing are included only where expressly stated.

11. Delivery and acceptance

11.1 We will deliver each Deliverable in the form and channel stated in the SOW.

11.2 Unless another period is stated, the Customer has 10 Business Days after delivery to test the Deliverable against the Acceptance Criteria.

11.3 A rejection notice must be given within the review period and must identify each material failure, the affected Acceptance Criterion and reasonable reproduction details.

11.4 We will use reasonable efforts to correct a valid Defect and resubmit the affected Deliverable. The review process then repeats for the corrected part.

11.5 A Deliverable is accepted when the Customer:

• confirms acceptance;
• uses it in production or for its intended operational purpose, other than solely for acceptance testing;
• fails to give a valid rejection notice within the review period; or
• accepts a later Deliverable materially dependent on it.

11.6 A minor defect that does not materially prevent the agreed use is not grounds for rejection. It may be recorded for correction during the warranty or support period.

11.7 If no objective Acceptance Criteria are stated, acceptance is based on material conformity with the Specification and the description of the Deliverable.

12. Deployment and migration

12.1 Deployment, cutover, migration, rollback, training and operational handover are included only where stated in the SOW.

12.2 Before a production change, the Customer must approve the maintenance window, confirm current backups, identify an authorised decision-maker and provide a reasonable rollback path.

12.3 We may stop or reverse a deployment where continuing creates a material security, integrity or availability risk.

12.4 Unless the SOW says otherwise, the Customer is responsible for production operation after acceptance.

13. Intellectual property

13.1 The Customer retains Customer Materials. We retain Provider Materials. Third-Party Materials remain governed by their licences.

13.2 Unless the SOW expressly states otherwise, each completed and fully paid Deliverable that consists of Bespoke Code, bespoke documentation, bespoke designs or other material created specifically for the Customer is an Assigned Deliverable under section 15.6 of the General Terms.

13.3 The assignment does not include:

• Provider Materials;
• general-purpose libraries, frameworks, templates, tools, methods and know-how;
• pre-existing or independently developed material;
• Third-Party Materials; or
• general improvements that do not disclose Customer Confidential Information or copy Customer-specific protected expression.

13.4 We grant the Customer a perpetual, worldwide, royalty-free, transferable and sublicensable licence to use, copy, modify and distribute Provider Materials embedded in an Assigned Deliverable, but only as part of or for the use, maintenance, support and development of that Deliverable.

13.5 The Customer may appoint another supplier to maintain or develop an Assigned Deliverable. We are not responsible for changes made by that supplier.

13.6 Intellectual-property rights transfer only after full payment of the relevant Fees. Before payment, the Customer may use the Deliverable solely for review and acceptance testing.

13.7 We will execute reasonable further documents needed to record an agreed assignment, at the Customer’s reasonable cost.

14. Documentation and handover

14.1 We will provide the documentation, source, build artefacts, configuration and deployment material expressly stated in the SOW.

14.2 Unless the SOW says otherwise, handover does not include internal notes, commercial licences that cannot be transferred, internal infrastructure, unrelated reusable tooling or material that would disclose another customer’s information.

14.3 We may remove or rotate amber.systems credentials and access during handover. The Customer must promptly establish its own operational credentials.

15. Defect warranty

15.1 Unless another period is stated, for 30 days after acceptance we will correct, without additional professional-service Fees, a reproducible material Defect reported with reasonable detail.

15.2 The warranty does not cover an issue caused by:

• use outside the Specification or Documentation;
• a Customer or third-party modification;
• unsupported infrastructure, dependency or data;
• a third-party change after acceptance;
• failure to apply an update or follow a documented requirement; or
• ordinary enhancement, new feature or changed requirement.

15.3 Our obligation is to correct or reperform the affected item within a reasonable period. If that is not reasonably possible, the remedy in section 16.3 of the General Terms applies.

15.4 Ongoing support, maintenance, security updates and compatibility work require an incorporated Support and Maintenance Schedule or another Order Form.

16. Open issues and residual items

16.1 Acceptance does not prevent the parties from recording minor defects, technical debt, future improvements or known limitations. They are chargeable unless included in the warranty or SOW.

16.2 A roadmap, backlog item or feature discussion is not a commitment unless recorded in the SOW or Change Request.

17. Contact

Development and project enquiries may be sent to hello@amber.systems.