Comparing contract text against system behaviour

In technology projects, legal risk usually arises not from a badly drafted clause but from the text not matching the system. When the commitment written in the contract diverges from what the software actually does, the contract is what gets examined in a dispute — whatever the system may be doing.

Note: Skytek is a technology company. It does not practise law and does not provide legal advice or compliance guarantees. This page describes the technical approach we follow when comparing contract text against what a system actually does. Anything requiring legal assessment is handled by the party's own lawyer.

Where it shows up

• Contracts — software development, maintenance and support, SaaS subscription, confidentiality and subcontractor agreements
• Data protection — processing inventories, privacy notices and consent texts, retention periods, cross-border transfers
• Intellectual property — ownership of code and content, assignments, open source license compliance
• E-commerce regulation — distance selling, pre-contractual information, right of withdrawal and interface compliance

Comparing the text against the system

Implementing a privacy notice is not a matter of putting the text on the site; it is auditing whether the processing the text describes is what actually happens.

Differences that surface often in practice:

• A service provider listed in the text but not actually used
• Fields the text says are processed but which are not in fact stored
• Data the system genuinely collects but the text never mentions
• Texts with no transfer section despite servers sitting abroad

Each of these is a real risk, and each is only visible when both sides are examined together.

Where law and engineering conflict

Sometimes regulation and technical requirement genuinely conflict. If a record is to be deleted but that same record constitutes a financial document, tax and commercial legislation may require a longer retention period.

In such cases the answer is usually not the binary of "delete" or "do not delete" but a third path: keeping the record while severing it from identity. Solutions like that can only be built when the legal requirement and the system's actual behaviour are examined together.

The places most often left blank in contracts

In software contracts the most expensive ambiguities cluster around:

• Acceptance criteria — what "delivered" means, which tests measure it, what silence signifies
• Change procedure — how a new request's effect on time and price is calculated
• Assignment of rights — economic rights transferred in writing and enumerated separately; separate assignments with freelancers
• Liability cap — why "liable for no damages whatsoever" fails where a reasonable cap would hold
• Exit plan — who ends up with the source code, infrastructure access and accounts

We opened these up in our article on technology contracts.

How we work

We read your existing contracts and texts, and set what the system actually does alongside them. We report each divergence individually, with reasoning. Then we order the fixes by risk — they do not all have to be solved at once.

If a new project is starting, we set the legal framework at the beginning of development. A clause added later forces changes to a system already built; a framework set upfront does not.

This page describes the scope of the service; it does not constitute legal advice on any specific matter.