An AI-Ready Precedent Transaction Data Schema

An AI-ready precedent-transaction record is not one row containing a buyer, target, date, deal value and multiple. It is a set of linked facts: parties, events, consideration components, valuation bridges, financial periods, calculations and source passages. The schema must preserve those relationships or the model will combine values that were never meant to be compared.

The design objective is reproducibility. Another analyst should be able to reconstruct why a deal was included and how every multiple was produced.

The seven record groups

Record group	Purpose	Examples
Identity	Resolve the parties and transaction	Target, buyer, seller, legal identifiers
Event	Preserve the deal timeline	Announcement, signing, approval, completion, termination
Consideration	Describe what security holders receive	Cash, stock, earnout, CVR, rollover
Valuation bridge	Move from equity value to enterprise value	Debt, cash, leases, NCI
Financial metric	Define each denominator	Revenue, EBITDA, LTM, NTM, period end
Calculation	Preserve formula and inputs	Calculated EV/EBITDA, FX conversion
Evidence	Trace every field to a document	Filing, exhibit, page, passage, access date

Each group should have its own identifier and link back to a stable transaction key. Do not make one generic “deal date” or “deal value” field carry several meanings.

For US public-company transactions, the companion filing map explains where to find M&A deal terms in SEC filings, including the distinct roles of Form 8-K, proxy materials, Form S-4, Schedule TO, Schedule 14D-9 and their amendments.

1. Identity

The identity layer answers who participated and in what role.

Minimum fields:

• transaction identifier;
• target legal and trading names;
• target identifier and jurisdiction where available;
• buyer, merger subsidiary and ultimate parent;
• seller or divesting parent when relevant;
• buyer type as stated or analytically classified;
• stake or assets being acquired; and
• source supporting each relationship.

This matters when the named acquirer is a newly formed merger subsidiary but the strategic or financial buyer used for comparability is its parent. Preserve both rather than replacing one with the other.

2. Event timeline

A transaction can have several valid dates. Store events as separate records:

• first public announcement;
• signing or definitive agreement;
• competing or revised offer;
• shareholder approval;
• regulatory approval;
• completion;
• termination or withdrawal; and
• later consideration settlement where relevant.

Each event needs a date, status, source and observation time. The transaction’s current status can be a derived field based on the latest reviewed event.

SEC Form 8-K illustrates why this matters. Item 1.01 can disclose entry into a material agreement, while Item 2.01 addresses completion of a significant acquisition or disposition. Those are different events and may be reported in different filings.

3. Consideration

Do not store consideration as one text field. Model the components:

Component	Useful attributes
Cash	Amount per share or aggregate, currency and payment timing
Stock	Exchange ratio, acquirer security, reference price and reference date
Earnout	Maximum amount, milestones, measurement period and probability treatment
Contingent value right	Trigger, payout terms, tradability and valuation treatment
Rollover equity	Holder, percentage or value rolled, and surviving vehicle
Assumed liabilities	Type, amount, date and inclusion in the value bridge

IFRS 3 describes consideration transferred as potentially including assets, liabilities incurred, equity interests and contingent consideration. A disclosure’s accounting treatment and a banker’s enterprise-value bridge are not automatically identical, so preserve the source label and the analytical treatment separately.

4. Valuation bridge

Every value needs a type:

• reported equity value;
• calculated fully diluted equity value;
• reported enterprise value;
• calculated enterprise value;
• purchase price or consideration with another definition; or
• value type unresolved.

For a calculated enterprise value, store every adjustment as a signed component:

enterprise value = equity value + debt + debt-like items + non-controlling interests - cash - excluded assets

The exact bridge depends on the methodology. The record should expose:

• component name;
• source value and currency;
• balance-sheet or reference date;
• sign in the calculation;
• inclusion rationale;
• source; and
• reviewer.

Do not let the AI rename a headline “transaction value” as enterprise value without reconstructing what the source included.

5. Financial metrics

Revenue or EBITDA is not comparable until its definition and period are known.

Each metric record should include:

• metric name;
• reported, adjusted or normalized basis;
• actual, estimate or forecast status;
• LTM, NTM or fiscal-period label;
• period start and end;
• amount and currency;
• continuing-operations or acquired-scope treatment;
• source; and
• normalization adjustments.

Keep the source value and normalized value separate. If an analyst removes a non-recurring expense or aligns lease accounting, the transformation needs its own adjustment record.

6. Calculations and lineage

A calculated multiple should be stored as an output linked to immutable inputs, not typed into the record.

For every calculation, retain:

• formula version;
• numerator field identifier;
• denominator field identifier;
• input values and units;
• currency conversion, rate source and date;
• calculation timestamp;
• software or process that calculated it; and
• reviewer status.

For example:

calculated EV / LTM EBITDA = reviewed enterprise value / reviewed LTM EBITDA

If either input changes, the result should be recalculated and versioned. The old result should not remain attached to the new inputs.

A multiple quoted in a proxy statement is a reported multiple. Keep it as such even when the underlying values are unavailable. A multiple built by the analyst is calculated. The two can be compared, but not silently substituted.

7. Evidence

The evidence object makes the record auditable:

• document type;
• filing or publication date;
• issuer or publisher;
• accession number or document identifier;
• URL;
• exhibit, section or page;
• relevant passage;
• retrieval date; and
• source hierarchy.

EDGAR may provide an announcement 8-K, merger agreement exhibit, proxy statement, tender-offer documents and closing filing for one transaction. No single document necessarily contains every final term. Attach each field to the document that supports it.

Source hierarchy and conflicts

A practical hierarchy starts with executed agreements, regulator filings and exchange announcements, then company investor-relations releases, then reputable secondary reporting for discovery or corroboration.

Conflicts should remain visible. Store both values, identify the difference and record the reviewed resolution. Common causes include:

• announcement value versus final consideration;
• basic versus fully diluted share counts;
• equity value labelled “transaction value”;
• debt and cash from different reference dates;
• reported EBITDA versus an adviser-adjusted figure; and
• stock consideration valued on different dates.

The model should describe the conflict rather than choose the larger or more recent-looking number without a rule.

Separate source data from analytical judgments

Use three layers:

1. Reported facts: what the document states.
2. Deterministic transformations: currency conversions, value bridges and formulas.
3. Analytical judgments: comparability, normalization policy, outlier treatment and inclusion.

This lets an AI assistant retrieve source facts and explain judgments without rewriting either. It also lets a reviewer change the analytical policy while preserving the original deal record.

Validation rules before a record is searchable

At minimum, test:

• Every party has a role and identity source.
• Announcement and completion are different events.
• Every amount has a currency and value type.
• Stock consideration has a reference price and date.
• Every denominator has a metric definition and period.
• Calculated outputs point to versioned inputs and formulas.
• Reported and calculated values are visibly different.
• Missing consideration or financials remain missing.
• Conflicts are resolved or labelled unresolved.
• Every decision-relevant field has a source locator.

NIST identifies confident erroneous content as a generative-AI risk. For transaction analysis, the schema is a control against that risk: it limits which facts can be joined and makes every transformation inspectable.

Retrieval output for an analyst

When an AI system returns a comparable transaction, the answer should include:

• why the deal matched the screen;
• current transaction status and the relevant date;
• value type and consideration components;
• the exact financial period behind each multiple;
• reported versus calculated labels;
• source links;
• unresolved or undisclosed fields; and
• any analytical judgment that still requires approval.

That is enough context to validate the result without flooding the model with an entire document archive.

Read why finance AI valuation needs sourced precedent transaction data for the broader risk framework, then apply the precedent-selection methodology. PrivyLogic provides browser, REST API and remote MCP access to sourced transaction research on eligible plans; review the access options.

Sources

1. Artificial Intelligence Risk Management Framework — Generative Artificial Intelligence Profile — National Institute of Standards and Technology; accessed September 19, 2026
2. Form 8-K — U.S. Securities and Exchange Commission; accessed September 19, 2026
3. EDGAR Search — U.S. Securities and Exchange Commission; accessed September 19, 2026
4. IFRS 3 Business Combinations — IFRS Foundation; accessed September 19, 2026