Structured documents, Ricardian contracts, and smart contracts

Legal documents can be produced through automation, associated with structured data, and used in workflows that perform tasks. Designing these solutions requires distinguishing three aspects: the content expressed, its computational representation, and the operations performed using it.

These aspects can coexist in an application. An agreement may have a version readable by its parties, data about its obligations, and a workflow that tracks due dates. Each component has a role and needs an identifiable relationship with the others.

Text, data, and execution

Aspect	Function	Example
Text and presentation	Communicate content to people.	A clause describing a payment obligation.
Structured data	Represent elements in a format systems can use.	Creditor, debtor, amount, currency, and due date.
Rules and execution	Evaluate conditions and perform operations.	Calculate an amount or route an obligation for verification.

A computer-readable file may contain only text. Semantic structuring adds the identification of concepts and relationships needed by an application. Execution depends on rules, services, or programs that use this information.

The representation should preserve the information’s origin and status. An amount extracted from a draft, an accepted proposal, and an obligation recorded after signing are not interchangeable.

Automated and structured documents

An automated document is produced, wholly or partly, by a generation process. That process may fill fields, select clauses, apply rules, or use AI to develop content.

A structured document, as the term is used in this guide, maintains content or associated elements organized under a schema. The structure may reside in the file itself or in related records. The Legal Common Data Model provides a reference for representing concepts shared across applications.

Automated generation and structuring are different properties. A document received from a third party can be structured through extraction and verification. An automatically generated document can be delivered as a file without exposing the data used to assemble it to its recipient.

The expression smart document can describe a combination of content, data, and automation. A specification using that term should identify which capabilities are actually present and where they run.

The Ricardian contract concept

In Ian Grigg’s formulation, a Ricardian contract links a contractual description readable by people and programs to the identification of an instrument and its transactions. The model includes a digital signature, key and server information, and a secure identifier associated with the document.¹

This proposal helps explain the link between content, document identity, and computational records. Being readable by programs does not mean that a document executes every obligation it describes.

An application that associates text and data can draw on this idea without implementing the original Ricardian model in full. Its documentation should make that adaptation explicit. Using a template, JSON, or an electronic signature alone does not establish equivalence with the model.

Smart contracts and computational execution

In Ethereum, a smart contract is a program comprising code and state, deployed on the network and executed according to calls and the rules of its environment.²

This program can participate in performing a contractual relationship, but its computational function needs to be distinguished from the agreement’s content and legal effects. External information, permissions, errors, and conditions not represented in the code also need to be considered in the design.

The term Turing-complete describes computational capacity: the ability to express general computations under theoretical resource assumptions. It does not mean that a program represents every obligation in a transaction or removes the need for human decisions. Real environments impose execution limits; in Ethereum, resource consumption is controlled through gas.³

Legal validity and automation

A transaction’s legal validity does not follow from its technological label. In Brazil, the assessment must consider, among other applicable requirements, capacity, subject matter, and form under Article 104 of the Civil Code; Article 107 addresses freedom of form where the law does not require a particular form.⁴

Executing code does not, by itself, resolve questions of interpretation, consent, performance, or liability. A solution needs to define the relationship between approved text, recorded data, and authorized operations.

Application to Looplex architecture

In Looplex, these distinctions help explain how different capabilities contribute to work:

• Analyzer identifies documents and structures information from incoming materials.
• Builder generates documents using templates, data, and rules.
• Content organizes files, versions, and access.
• Cases relates documents, information, activities, and history.
• The Assistant, workflows, and integrations can use these elements in configured work.

For example, information in an incoming agreement can be extracted and verified, linked to a case, and used to initiate tracking activities. Operations take place in enabled services and workflows under the required permissions and approvals. Files, data, and activities can be connected without execution on a blockchain.

These capabilities do not automatically make every document produced by the platform a Ricardian contract. An integration with a smart contract environment would require its own specification of data, code, identity, authorization, and execution conditions.

What a project needs to define

To make the relationship between content and execution verifiable, a specification should identify:

1. Which document and version express the approved content.
2. Which data was extracted, supplied, or calculated, and its origins.
3. Which rules and services use that data.
4. Which operations require review or approval.
5. How changes, discrepancies, and failures will be handled.
6. How results and their relationship to the case will be recorded.

Legal automation: models, rules, and artificial intelligence explores how these mechanisms can be combined.

Footnotes

1. Ian Grigg, The Ricardian Contract, 2004. This is a conceptual reference; cryptographic choices for current implementations require their own assessment. ↩

2. Ethereum, Introduction to smart contracts. ↩

3. Ethereum, Whitepaper — Turing-Completeness. Reference for the computational concept and execution limits through gas. ↩

4. Brazil, Civil Code, Articles 104 and 107. ↩