% ============================================================================
\section{Resolution, Timelines and Amounts}\label{sec:resolution}
% ============================================================================

\subsection{The resolution rule}

Mentions are grouped into projects by a deterministic key computed in SQL (\texttt{spid/resolve.py}): the issuer CIK, the project type, and either the lower-cased first location of the mention or, when no location was extracted, the first token of at least four letters in the normalized project name (``general'' when none exists). The project identifier is the MD5 hash of that key. Within a group, the representative name and description are those of the highest-confidence mention, the canonical location is the group's location token, the technologies are the union of the mentions' technologies, the status is that of the \emph{latest} mention by filing date, the amount is the \emph{maximum} across mentions, and the timeline is the ordered list of mentions with their filing date, form, status, amount, confidence and snippet. First and last cited years are the minimum and maximum of the years mentioned in the text; first and last \emph{seen} are the filing dates of the earliest and latest mention.

The rule is transparent, cheap and reversible (the mentions are untouched), and it behaves well for the common case of a recurring physical program at one site. Its failure modes are equally clear:

\begin{itemize}
\item \textbf{False merges.} All mentions of one type at one location collapse into one project: every acquisition closed by a serial acquirer in the same city, every expansion of a multi-phase site (the Cheniere example of Table~\ref{tab:provenance}), every drug candidate of a pharmaceutical company with no location, which fall back to a name token that is often shared (``phase'', ``program'', ``study''). The mean of 4.99 mentions per \texttt{drug\_pipeline} project versus 1.63 for \texttt{technology\_deployment} partly reflects this.
\item \textbf{False splits.} The same initiative named differently across filings (``Project Atlas'' in 2019, ``our ERP transformation'' in 2021) or located at a different granularity (``Texas'' vs. ``Austin, Texas'') yields distinct keys; so does a change of category by the model.
\item \textbf{No cross-issuer identity.} A joint venture disclosed by both partners is two projects; a project inherited through an acquisition is a new project of the acquirer.
\end{itemize}

The 60.2\% of projects with a single mention are the population in which false splits, true one-off disclosures and false positives are mixed, and the projects with more than ten mentions (3.1\%) are where false merges concentrate. The brief's requirement---explainable, reversible merge/split decisions with match scores, resolver version and human adjudication of ambiguous clusters---is not met by the current rule and is the second schema change proposed: a \texttt{project\_mention\_links} table with a match score and an adjudication status, fed first by the deterministic key (score~1 by construction) and then by a probabilistic linker that uses name similarity, embedding similarity, location and time, with ambiguous clusters routed to review.

\subsection{Timelines and point-in-time structure}

Each mention is dated by the filing date of its document, and each project by the filing dates of its first and last mentions and by the years cited in the text. This is a point-in-time structure in one specific sense: the state of a project \emph{as known at} a filing date can be reconstructed by filtering the timeline to mentions filed on or before that date, and nothing in a later filing is used to alter an earlier mention. It is \emph{not} yet the event structure the brief describes. The database does not separate first announcement, SEC acceptance timestamp (only the filing date is stored), referenced period, expected start, observed start, expected completion, realized completion and cancellation; cited years are stored as an unordered list without roles; and a project's status is the latest statement rather than a dated transition. The proposed \texttt{project\_events} table (Appendix~\ref{app:dictionary}) would record each such event with its date, its evidence mention and a flag distinguishing information available at the acceptance date from information revised later.

\subsection{Amounts}\label{sec:amounts}

The amount of a mention is whatever USD figure the model associated with the project in the passage, coerced to a float; the raw string is retained. The project-level \texttt{total\_amount\_usd} is the \emph{maximum} over mentions, chosen in the June 2026 release because the same budget is typically restated in successive filings and summing would multiply it by the number of mentions. The maximum avoids that error but introduces others: it cannot tell a transaction price from a capex budget, a contract value from a financing facility, an incurred cost from an estimate, or a figure for the whole program from a figure for one phase, and it is silently inflated when a merged project combines distinct initiatives. We therefore insist on two reading rules. First, \texttt{total\_amount\_usd} is ``the largest amount an issuer cited in connection with this project'', nothing more. Second, amounts must never be summed across projects or interpreted as realized investment. The proposed \texttt{project\_amounts} table keeps every amount mention with its original value, currency, scale, reporting date, an \texttt{amount\_type} (announced budget, estimated cost, capex incurred, transaction value, contract value, financing, other) and an estimate/realization flag; filling \texttt{amount\_type} requires either a second extraction pass or annotation, both of which are in the validation plan.

\subsection{Data model: current and proposed}

Table~\ref{tab:datamodel} in Appendix~\ref{app:dictionary} lists the tables of the current build alongside the tables required by the brief and marks each as implemented, partial or proposed. In summary, the current \texttt{companies}, \texttt{filings}, \texttt{filing\_sections}, \texttt{project\_mentions}, \texttt{projects}, \texttt{project\_timeline} and \texttt{extracted\_sections} tables cover universe, filings, sections, mentions, projects, a timeline and an extraction ledger; the \texttt{issuers} history, \texttt{project\_mention\_links}, \texttt{project\_events}, \texttt{project\_amounts}, \texttt{extraction\_runs} (with prompt, schema and taxonomy hashes) and \texttt{human\_labels} tables are proposed and would be added by migration, never by destructive replacement.