spb/firc0001_uqo

1% ============================================================================2\section{Resolution, Timelines and Amounts}\label{sec:resolution}3% ============================================================================45\subsection{The resolution rule and what it keys on}\label{sec:resolution_rule}67Mentions 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.89Rebuilding the key from the stored mentions reproduces the \SPIDprojectCountCurrentKey\ project identifiers exactly and shows what the key is made of. \SPIDprojectsKeyedLocationPct\% of projects (\SPIDprojectsKeyedLocation; \SPIDmentionsKeyedLocationPct\% of mentions) are keyed on a location, \SPIDprojectsKeyedNameTokenPct\% (\SPIDprojectsKeyedNameToken\ projects, \SPIDmentionsKeyedNameTokenPct\% of mentions) on a name token, and \SPIDprojectsKeyedGeneralPct\% on the residual ``general''. The name token is almost always a generic head word: the ten most frequent are \SPIDtopNameTokens\ (shares of token-keyed projects), and the single token ``acquisition'' absorbs \SPIDtopTokenMentions\ mentions (\SPIDtopTokenSharePct\% of token-keyed mentions) into \SPIDtopTokenProjects\ projects, that is, every acquisition of an issuer whose name begins with that word is one project per issuer. The location branch is coarse as well: \SPIDlocationKeysCountry\ projects are keyed on a country and \SPIDlocationKeysUsState\ on a U.S. state (\SPIDlocationKeysCountryStatePct\% of location-keyed projects; ``united states'' alone keys \SPIDlocationKeyUnitedStatesProjects\ projects). The representative fields are not unique either: \SPIDprojectsTieMaxConfidence\ projects have more than one mention at the maximum confidence (\SPIDprojectsTieDistinctNames\ of them with different names, \SPIDprojectsTieDistinctDescriptions\ with different descriptions) and \SPIDprojectsStatusTie\ have more than one status on the latest filing date, and the SQL picks among ties in execution order. Re-running the authors' SQL reproduces every project identifier but changes the representative name of \SPIDrebuiltNameDiff\ projects and the description of \SPIDrebuiltDescDiff; a deterministic tie-breaker (confidence, then mention identifier) is idempotent and would change \SPIDtiebreakNameDiff\ names, \SPIDtiebreakStatusDiff\ statuses and \SPIDtiebreakDescDiff\ descriptions relative to the stored table. Until that tie-breaker is adopted, every representative name, description and status in this paper, including those of \Cref{tab:provenance}, is one admissible choice among ties rather than a reproducible value.1011The 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, and two of them are now measured:1213\begin{itemize}14\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 \Cref{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 \SPIDmentionsPerProjectDrug\ mentions per \texttt{drug\_pipeline} project versus \SPIDmentionsPerProjectTechDeploy\ for \texttt{technology\_deployment} partly reflects this. Among \texttt{ma\_integration} projects, \SPIDmaGeThreeNamesPct\% carry three or more distinct project names across their mentions (\SPIDmaGeThreeNamesOverTenPct\% of those with more than ten mentions), \SPIDmaGeThreePartnersPct\% of those with a partner carry three or more distinct first partners, and the project-level amount of \SPIDmaAmountOtherCounterpartyN\ of \SPIDmaAmountOtherCounterpartyDenom\ M\&A projects where both are named comes from a mention naming a different counterparty than the representative mention (\SPIDamountOtherCounterpartyN\ of \SPIDamountOtherCounterpartyDenom\ across all categories); these are over-merges by construction.15\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.16\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.17\end{itemize}1819The \SPIDsingleMentionShare\% 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 (\SPIDoverTenMentionShare\%) are where false merges concentrate. The specification'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 \citep{li2020,peeters2023}, with ambiguous clusters routed to review.2021\subsection{Sensitivity of the project count to the key}\label{sec:speccurve}2223Because the key is a modelling choice, the project count is reported in this revision as a range. \Cref{tab:spec_curve} recomputes it for nine keys and five confidence thresholds from the same \SPIDmentions\ mentions. At the production threshold of \SPIDconfThreshold, grouping by issuer and type alone gives \SPIDprojectsKeyCikType\ projects; dropping the type from the current key gives \SPIDprojectsKeyTypeDropped; keying on the name token only gives \SPIDprojectsKeyNameOnly; the current key gives \SPIDprojectCountCurrentKey; normalizing city and state spellings gives \SPIDprojectsKeyCityNorm; removing stop-words before taking the token gives \SPIDprojectsKeyStopwords; keying on two salient tokens gives \SPIDprojectsKeyTwoTokens; a strict key on the full normalized name and location gives \SPIDprojectsKeyStrict; and treating every mention as its own project gives \SPIDprojectsKeyMentionLevel. Raising the threshold to 0.9 under the current key leaves \SPIDprojectsCurrentKeyAtNine\ projects. The single-mention share moves with the key from \SPIDsingleMentionShareCikType\% (issuer and type) to \SPIDsingleMentionShareStrict\% (strict), and the Cheniere cluster of \Cref{tab:provenance} has \SPIDchenierClusterCurrent\ mentions under the current key, \SPIDchenierClusterStrict\ under the strict key, \SPIDchenierClusterNameOnly\ under the name-only key and \SPIDchenierClusterCikType\ under issuer-and-type. The abstract and \Cref{sec:results} therefore quote \SPIDprojectCountCurrentKey\ ``under the current key'' and \SPIDprojectsKeyTypeDropped--\SPIDprojectsKeyStrict\ as the range over the alternative keys that keep a notion of initiative; none of these counts is a count of initiatives validated against human judgment.2425\begin{table}[H]26\centering\scriptsize27\caption{Project count, single-mention share and cluster statistics under alternative resolution keys and confidence thresholds (specification curve)}\label{tab:spec_curve}28\begin{threeparttable}29\adjustbox{max width=\textwidth}{\input{tables/tab_spec_curve}}30\begin{tablenotes}\footnotesize31\item Source: \texttt{results/resolver/spec\_curve.csv} (\texttt{code/audit/a03\_resolver\_speccurve.py}, read-only rebuild of the key from \texttt{project\_mentions} at revision \texttt{2324b58}). Keys: \texttt{k\_cik\_type} = issuer and type; \texttt{k\_type\_dropped} = issuer and location-or-token; \texttt{k\_current} = the production key (issuer, type, location-or-token); \texttt{k\_current\_stopwords} = current key with stop-words removed before the token; \texttt{k\_city\_normalised} = current key with city/state spellings normalized; \texttt{k\_name\_only} = issuer, type and token (location ignored); \texttt{k\_two\_tokens} = issuer, type and the first two salient tokens; \texttt{k\_strict} = issuer, type, full normalized name and location; \texttt{k\_mention\_level} = one project per mention. ``Threshold'' is the minimum mention confidence retained. ``Example cluster'' is the number of mentions in the Cheniere Corpus Christi cluster of \Cref{tab:provenance}. No key is validated against human labels; the table bounds the artefact of the key, it does not estimate the number of initiatives.32\end{tablenotes}33\end{threeparttable}34\end{table}3536\subsection{Timelines and point-in-time structure}3738Each 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 specification 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 for up to \SPIDyearsRegexEqualPct\% of mentions they may have been read from the model's paraphrase rather than from the text (\Cref{sec:contract}); and a project's status is the latest statement rather than a dated transition, with ties on the latest date resolved arbitrarily for \SPIDprojectsStatusTie\ projects. The proposed \texttt{project\_events} table (\Cref{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.3940\subsection{Amounts}\label{sec:amounts}4142The amount of a mention is whatever USD figure the model associated with the project in the passage, coerced to a float; the source wording is not retained (\Cref{sec:contract}), so currency, scale and basis cannot be recovered from the stored data. 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 (\Cref{sec:resolution_rule}). The tail of the distribution shows what unchecked coercion produces: the largest stored amount is $\SPIDamountMaxSci$~USD (one mention, found as a number in a 10-K MD\&A with no currency token nearby), \SPIDamountGeFiftyBMentions\ mentions in \SPIDamountGeFiftyBProjects\ projects carry amounts of 50~B~USD or more, \SPIDamountNegative\ amounts are negative and \SPIDamountZero\ are zero. Of the \SPIDamountTopN\ largest amounts, \SPIDamountTopNumberFound\ are found as a number in the source section and \SPIDamountTopCurrencyFound\ with a currency token within forty characters, so most of the tail is transcribed rather than invented, but scale errors from tables ``in thousands'' or ``in millions'' cannot be excluded without typing; a non-USD currency token sits within forty characters of \SPIDamountNonUsdTokenN\ of the \SPIDamountLocatedN\ located amounts (\SPIDamountNonUsdTokenPct\%). 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 source string, 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 it requires either a second extraction pass or annotation, neither of which was authorised for this revision, and the release notes recommend excluding non-positive amounts and flagging amounts of 50~B~USD or more until then.4344\subsection{Data model: current and proposed}4546\Cref{tab:datamodel} in \Cref{app:dictionary} lists the tables of the current build alongside the tables required by the specification and marks each as implemented, partial or proposed. In summary, the current \texttt{companies}, \texttt{filings}, \texttt{filing\_sections}, \texttt{spid\_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 model snapshot, seed, fingerprint, prompt and taxonomy hashes, call status and raw response) and \texttt{human\_labels} tables are proposed and would be added by migration, never by destructive replacement.47