Safe Harbour Policy

We build in the open. We publish a roadmap, we demonstrate work in progress, we describe where we think Accord Lifecycle Intelligence is heading, and we discuss ideas candidly with customers, prospects, analysts, partners and procurement panels.

That openness is worth something only if everyone understands what a statement about the future is and is not. This Safe Harbour Policy draws that line. It tells you how to read a roadmap slide, a demonstration, a blog post, a bid response or a conversation with our team, and it tells you what to do if you need a future capability guaranteed.

This policy applies to every statement we make about Truce.ai in any medium — website, documentation, presentations, demonstrations, webinars, blogs, social posts, press releases, analyst briefings, tender and RFP responses, proposals, roadmap reviews, advisory-board sessions, support conversations and informal discussion — wherever that statement concerns functionality, capability, timing, performance or certification not yet generally available.

It applies equally to statements made by our employees, contractors, partners, resellers and implementation partners. None of them has authority to convert a forward-looking statement into a commitment; only a signed contract can do that, as clause 19 explains.

Read this policy alongside our Terms & Conditions, our Privacy Policy and our Data Protection, Security & Compliance Policy.

Truce.ai is a trademark of Virtuos Digital Limited, operated through its Futuristry Division. Futuristry is a Strategic Business Unit (SBU) at Virtuos, formed under the Virtuos Transformation Economy initiative — a programme dedicated to building AI-native products rather than adding intelligence to legacy software after the fact. Throughout our website and materials, Truce and Truce.ai are used interchangeably and refer to the same platform.

Truce is an Accord Lifecycle Intelligence (ALI) platform. It governs the entire life of an accord — intent, drafting, negotiation, execution, obligations, performance, variation, renewal and closure — with machine intelligence applied throughout.

ALI is a different category from traditional Contract Lifecycle Management, with genuine overlap. Both handle authoring, clause libraries, approvals, repositories, e-signature and renewals. Beyond that, CLM manages a document; ALI reasons about a living accord and the obligations it creates.

That distinction matters here more than anywhere else in our documentation. A new category attracts speculation about what it will eventually do, and a fast-moving one attracts more. This policy exists because the gap between what an emerging category could do and what our product does today is exactly where buyers get hurt.

We chose the .ai extension deliberately: the whole of ALI is built on frontier models, and Truce is AI-first and AI-born. That architecture is also a source of forward-looking risk, because the models underneath us are themselves changing. Clause 8 addresses this directly.

Before you sign, evaluate the platform as it exists. Ask for a demonstration on the current production release. Ask which of your requirements are met today, which are on the roadmap, and which are not planned at all. Ask us to state that in writing. We will answer honestly, including when the answer is that a capability does not exist.

If a capability is essential to your business case, do not buy on the expectation that it will arrive. Either wait until it is generally available, or commission it under clause 7 as an ordered module with a contract behind it.

We do not want a customer whose success depends on a feature that does not exist yet. That is bad for you and bad for us. A deal closed on a promise is a renewal lost eighteen months later, and we would rather have the harder conversation now.

If a member of our team, a partner or a reseller has led you to believe a future capability is guaranteed, tell us at legal@truce.ai before you sign. We will correct the record in writing.

A forward-looking statement is any statement that is not a statement of present fact about the generally available platform. It includes, without limitation:

• roadmap items, planned releases, product direction and vision;
• features described as "coming", "planned", "in development", "in design", "next", "on the roadmap", "in beta", "in preview", "in private preview" or "targeted for";
• release dates, timelines, sequencing, milestones and general-availability targets;
• planned integrations, connectors, APIs, marketplaces or partner ecosystems;
• anticipated AI capability — new agents, new reasoning behaviour, new model classes, expanded language or jurisdiction coverage;
• expected performance, accuracy, throughput, cost or efficiency improvements;
• anticipated certifications, attestations, empanelments, accreditations or regulatory approvals;
• planned data centre regions, residency options or sovereign deployment models;
• expected business outcomes, savings, cycle-time reduction, risk reduction or return on investment;
• pricing, packaging or licensing models not yet in force;
• statements about the future of the ALI category, the contracting market or the AI industry;
• concepts shown in a demonstration, mockup, prototype, sandbox, design or proof of concept that are not in the production release.

A statement is forward-looking regardless of who made it, how confident it sounded, how detailed it was, or whether it appeared in a formal document. A slide with a quarter marked against a feature is forward-looking. A confident answer in a discovery call is forward-looking. A line in a bid response describing a planned capability is forward-looking.

Some statements are not forward-looking: a description of functionality generally available today, a published specification of the current release, a security control we currently operate, and a commitment recorded in a signed Order Form, statement of work or contract. Those you may rely on.

Forward-looking statements are commonly signalled by words such as: will, would, could, should, may, might, plan, planned, intend, expect, anticipate, aim, target, believe, estimate, project, forecast, seek, strive, pursue, envision, roadmap, upcoming, forthcoming, future, next generation, soon, shortly, in due course, on track, designed to, built to, positioned to, and their negatives.

The absence of such a word does not make a statement present-tense fact. A demonstration narrated in the present tense — "Truce identifies every indemnity clause and flags deviation from your playbook" — is forward-looking if the capability shown is not in the production release. Judge by whether the capability is generally available, not by the grammar.

Where we know we are describing something future, we mark it. Roadmap material carries a safe harbour notice. Preview features are labelled in-product. Bid responses distinguish "available today" from "planned". If material is unmarked and you are unsure, ask — and take the answer in writing.

The definitive test is simple: if you cannot see it working in the current production release under your own login, treat it as forward-looking.

Our roadmap is a statement of current intent and current thinking. It reflects what we believe, at the moment of publication, to be the right direction for Accord Lifecycle Intelligence.

The roadmap is not a commitment, a delivery schedule, a specification, a warranty, or part of any contract. It is not an offer capable of acceptance, and referencing it in a purchase order does not incorporate it into an agreement.

Roadmap items change. Priorities are reordered as customer needs, market conditions, regulation, security requirements and technical feasibility change. Items are deferred, redesigned, merged, split or removed entirely. A capability may ship in a different form, under a different name, in a different module, or with a different commercial model than described.

Sequence is not entitlement. Appearing earlier on a roadmap does not mean a capability will ship earlier, and no customer acquires a priority claim over a roadmap item by asking for it first, by contract value, or by having influenced the thinking behind it.

Roadmap detail shared under a non-disclosure agreement, in an advisory board, or in a customer council session is confidential and is subject to this policy in full. Confidentiality does not convert it into a commitment.

We share the roadmap because customer input makes it better. Input is welcome, is genuinely considered, and is not an order. Feedback we act on is governed by clause 10 of the Terms & Conditions.

If you need a capability that does not exist, there is a way to get it — and it is not the roadmap. Additional modules, features and capabilities are built on specific order.

An ordered build is documented in a signed statement of work or an Order Form recording, at minimum: the functional scope and specification; acceptance criteria; the delivery timeline and milestones; the price and payment schedule; assumptions and dependencies, including what you must provide; and the consequences of a delivery failure.

Only that signed instrument creates an obligation to build. Until it is signed, no capability is committed, whatever has been discussed, presented or written in a bid.

Ordered builds are chargeable. Pricing reflects the engineering effort, and payment for a bespoke build does not reduce your subscription fees.

Ownership of an ordered build follows clause 10 of the Terms & Conditions: the platform capability we create remains ours, and your Configuration of it is yours. Ordering a module does not make it exclusive to you. Under clause 11 of the Terms & Conditions, no customer acquires exclusivity over any platform function — including one that your requirement prompted and your money funded. We may make the underlying capability generally available to other customers. If exclusivity is essential to your business case, say so before you order; we will explain the alternatives, which do not include locking a platform function to a single customer.

While an ordered build is in progress, statements about its expected behaviour beyond the signed specification remain forward-looking and are governed by this policy.

Truce is AI-first and AI-born, built on frontier models. That is the source of much of the platform's value and of a particular kind of forward-looking risk, which we state plainly.

We do not control the models underneath us. Frontier model providers change capabilities, behaviour, context limits, latency, availability, safety filters, terms and pricing on their own schedules. A capability that depends on a specific model behaviour may change when that model changes, and improvements we expect from a future model generation may not arrive, may arrive later, or may arrive in a form that does not suit our architecture.

Any statement that a future model release will enable a capability, improve accuracy, reduce cost or extend coverage is forward-looking in the strongest sense: it depends on a third party we do not direct.

AI capability is probabilistic and does not improve uniformly. Accuracy on one document type, language, jurisdiction or clause family does not predict accuracy on another. A demonstration on a well-formed accord does not establish behaviour on your corpus. Where accuracy matters to your business case, test on your own documents before you buy.

Regulation of AI is developing quickly. The EU AI Act and comparable regimes may require us to add controls, restrict a capability, change how a feature works, or delay a release. Compliance takes precedence over roadmap delivery, and we will not ship a capability we cannot ship responsibly.

We may substitute, upgrade or retire an underlying model to maintain security, quality, compliance, cost or continuity. Where a change would materially reduce a capability you rely on, clause 18 of the Terms & Conditions governs notice and your remedies.

Nothing in any statement about AI capability should be read as a warranty of accuracy, completeness or fitness. Clause 12 of the Terms & Conditions governs reliance on AI output, and requires qualified human review before you act on it.

A demonstration shows the product working in a prepared environment on prepared data. It is evidence of capability, not a specification of what your deployment will do. Your results depend on your data quality, document variety, configuration, integrations, volumes and users.

Prototypes, mockups, design concepts, wireframes, innovation-lab work, hackathon output and "art of the possible" sessions are explorations. They may never become product. Treat everything shown in them as forward-looking without exception.

Alpha, beta, preview, early access, sandbox and pilot features are made available for evaluation and feedback. They are not generally available, may be incomplete or unstable, carry no service level commitment, may change substantially or be withdrawn without notice, and may never reach general availability. Under clause 5 of the Terms & Conditions they are supplied "as is". Do not place production or sensitive data in them, and do not build a business process on them.

Availability of a preview feature to you creates no entitlement to it at general availability, and no commitment about the pricing or packaging it will eventually carry.

A proof of concept establishes technical feasibility within its defined scope. Its success does not commit us to productise what it demonstrated, and does not extend to capability outside the scope tested.

Statements about speed, accuracy, extraction rates, cycle-time reduction, cost savings, headcount avoidance, risk reduction or return on investment are estimates based on observed results in particular environments. They are not warranties and not commitments.

Results vary with document quality and format, the variety and complexity of your accords, language and jurisdiction, the maturity of your existing processes, how thoroughly you configure the platform, how well your users adopt it, the state of your data at migration, and the scope of the deployment.

Case studies and customer references describe what one organisation achieved in its circumstances. They are not predictions about yours.

Third-party benchmarks, analyst scores, awards and market positions reflect the methodology, criteria and time period of the body that produced them. We do not control them, we do not warrant their accuracy, and a favourable position may change.

Business cases we help you build are collaborative estimates using your assumptions and your inputs. Our contribution to a model does not make us responsible for the outcome, and does not create a guarantee of benefit.

Planned integrations with ERP, CRM, procurement, e-signature, identity, storage, communication and government e-procurement systems are forward-looking until generally available and documented.

Integration delivery depends on third parties: the availability, stability, terms and cost of their APIs, their certification or marketplace processes, and their willingness to support the connection. A third party may change or withdraw an API, alter its terms, or decline to permit an integration, and that may delay, change or prevent a planned connector.

Where a planned integration is essential to your deployment, treat it as an ordered deliverable under clause 7 and record it in a statement of work, so that the dependency and its consequences are contractually addressed.

Our support for a third-party system today does not commit us to support future versions of it, and our support for a version does not extend to that vendor's other products.

Statements about certifications, attestations, empanelments, accreditations or regulatory approvals we intend to obtain — or about new hosting regions, sovereign cloud options or residency configurations we intend to offer — are forward-looking.

Certification depends on independent auditors and certifying bodies on their timelines, not ours. Empanelment and accreditation depend on government processes and criteria that may change. A hosting region depends on our cloud providers making it available, and on the commercial and regulatory conditions attaching to it.

Do not treat a planned certification as an existing one. If your procurement, tender qualification or regulatory position depends on a certification, verify its current status in writing before you rely on it. Our Data Protection, Security & Compliance Policy states our current position, and we will confirm current certification status on request at security@truce.ai.

Our current residency commitments are firm and are set out in the Data Protection, Security & Compliance Policy and in your Order Form. We strictly observe local data residency requirements and the laws governing them, including the GDPR. What is forward-looking is any additional region or deployment model we describe as planned.

Where a tender requires a certification or a residency option we do not yet hold, we will say so in our bid rather than describe a plan as an accomplishment.

Websites, brochures, datasheets, blog posts, videos, webinars, social media, conference talks, podcasts and press releases describe Truce.ai in general terms and are subject to this policy in full. They are not specifications, and they are not incorporated into any agreement.

The current specification of what the platform does is the Documentation for the release you are subscribed to, together with your Order Form. Where marketing material and Documentation differ, the Documentation governs.

Analyst reports, industry commentary and press articles are the work of their authors. We do not control their content, we do not warrant their accuracy, and a statement in a third-party report is not a statement by us. Quoting one to us does not make it ours.

Category commentary about the future of contracting, of the ALI category or of enterprise AI is opinion offered in good faith. It is not a prediction we stand behind commercially.

Translations of our materials are provided for convenience. Where a translation differs from the English text, the English governs.

Safe harbour runs in both directions. Just as we do not commit to add a capability, we reserve the right to change or remove one — subject to the notice and remedy provisions in clause 18 of the Terms & Conditions.

We may modify or deprecate a feature where it is superseded, where security or compliance requires it, where a dependency is withdrawn, or where usage does not justify continued support. We will not materially degrade a core function you are subscribed to without at least 90 days' written notice.

Where a deprecation materially and adversely affects you and we cannot offer a reasonable alternative, the Terms & Conditions give you a right to terminate the affected module with a pro-rata refund. That is your remedy, and it is a real one.

Nothing in this policy allows us to reduce a commitment expressly recorded in a signed Order Form, statement of work, Master Services Agreement or government contract during its term. Safe harbour covers statements about the future; it does not dilute promises we have actually made.

You must not rely on any forward-looking statement in making a purchase decision. That includes deciding to buy, deciding what to buy, deciding how much to buy, deciding to renew or expand, deciding not to buy an alternative, and deciding what to tell your own stakeholders about what the platform will do.

Forward-looking statements create no contract, warranty, condition, representation, undertaking, collateral contract or duty of care. They are not incorporated into any agreement by reference, custom or course of dealing.

To the fullest extent permitted by law, we accept no liability for any loss arising from reliance on a forward-looking statement, including loss of profit, revenue, savings, opportunity or goodwill, and including the cost of alternative arrangements made necessary by a capability not arriving. Nothing in this clause limits liability for fraud or fraudulent misrepresentation, or any liability that cannot lawfully be limited.

This policy is a limitation on reliance, not a licence to mislead. We instruct our teams and partners to describe the product accurately, to distinguish current from planned functionality without being asked, and to say "that does not exist today" when it is true. If we fall short of that, tell us at legal@truce.ai and we will correct it.

Actual results may differ materially from any forward-looking statement because of factors including, without limitation:

• changes in the capability, behaviour, availability, terms or pricing of frontier and foundation models we depend on;
• technical feasibility discovered during development, and engineering complexity not apparent at planning;
• availability of specialist engineering, research and delivery talent;
• changes in customer requirements, market demand or competitive conditions in the ALI and contracting categories;
• new or amended law and regulation, including AI, data protection, data localisation, procurement and sectoral regulation;
• certification, empanelment, accreditation and audit outcomes and timelines controlled by third parties;
• availability, pricing, regional coverage and service changes at AWS, Microsoft Azure and Google Cloud;
• changes to third-party APIs, platforms, marketplaces and partner ecosystems;
• security threats, vulnerabilities and incidents requiring reprioritisation of engineering effort;
• intellectual property developments affecting AI-generated content or model training;
• the outcome of pilots, proofs of concept and early deployments;
• reprioritisation within the Futuristry SBU and the wider Virtuos Transformation Economy portfolio;
• corporate developments including reorganisation, investment, acquisition or divestment;
• macroeconomic, geopolitical, trade, sanctions and force majeure conditions.

This list is illustrative, not exhaustive. Factors we have not anticipated may have a greater effect than any listed here.

Forward-looking statements speak only as of the date they are made. Circumstances change, and a statement that was accurate when made may become inaccurate afterwards.

We undertake no obligation to update, revise or withdraw any forward-looking statement, whether because of new information, changed circumstances, a decision to change direction, or otherwise, except where law requires it.

Do not treat the continued presence of a roadmap slide, a webpage, a recording or a bid response as confirmation that its content remains current. Material may remain in circulation, in a customer's files or in a search index long after our thinking has moved on.

If a forward-looking statement matters to you, ask us to confirm its current status in writing before you act on it, and ask again if significant time has passed.

We work extensively with governments, ministries, statutory bodies, regulators and Public Sector Undertakings, where evaluation is formal, scored and subject to audit. This clause states how we behave in that setting.

In every bid, tender response, technical proposal, presentation and demonstration, we distinguish clearly between functionality generally available today and functionality that is planned or to be developed. Where a requirement is not met today, we say so and describe what it would take to meet it.

Statements in a bid about planned capability are forward-looking and governed by this policy. They should not be scored as though they were existing functionality, and we ask evaluators to treat them accordingly. Where an evaluation methodology requires a compliance response, our answer will state the current status honestly rather than claim a plan as an accomplishment.

Where our bid commits to develop a capability, that commitment becomes binding through the resulting contract and its statement of work under clause 7, with defined scope, milestones, acceptance criteria and remedies. It does not become an existing entitlement on award.

Certifications, empanelments and residency options stated as planned in a bid are governed by clause 12. Where a tender requires a certification we do not hold, we will disclose that rather than obscure it, even where disclosure costs us the bid.

Clause 11 of the Terms & Conditions applies without exception: no department, ministry, PSU or agency acquires exclusivity over any platform function, however the requirement arose, whoever specified it, and whoever paid for its development.

Where a public procurement contract prescribes its own treatment of forward-looking statements, warranties or liquidated damages for non-delivery, that contract governs to the extent of any conflict with this policy.

This policy prevails over any statement about future functionality, wherever it appears. That includes statements in our website, marketing material, documentation, presentations, demonstrations, proposals, bid responses, emails and conversations. A forward-looking statement in a document that would otherwise rank higher in the order of precedence is still governed by this policy.

There is exactly one way to convert a statement about the future into a binding obligation: record it in a signed contract — an Order Form, statement of work, Master Services Agreement or government contract — executed by an authorised signatory of Virtuos Digital Limited, with defined scope, acceptance criteria, timing and remedies.

No other route works. Not an email from a salesperson. Not a roadmap slide with your logo on it. Not a partner's assurance. Not a demonstration. Not a line in a proposal. Not silence in response to an assumption stated in your purchase order. Only signature.

If you need something guaranteed, ask us to put it in the contract. We will either agree and sign, or explain why we cannot — and either answer is more useful to you than an unrecorded promise.

We may amend this policy. The current version always appears at www.truce.ai with its version number and effective date, and the version in force when a statement was made governs that statement.

If anything in a proposal, demonstration or conversation is unclear about whether a capability exists today, ask before you sign. We would rather answer the question than have you discover the answer later.