01.AppliedXL / Technology reference
AppliedXL monitors public records continuously, identifies events as they emerge, and preserves the evidence and history required to understand what happens next.
AXL Core detects candidate events by comparing source observations and extracting possible occurrences from text. Atlas definitions and evidence requirements govern acceptance. Accepted events form a connected history with supporting evidence. Client Lenses assess their implications.
Models assist semantic comparison, classification, and evidence assessment. Software orchestrates source monitoring, retrieval, validation, storage, and delivery.
Input
Public registries, filings, releases; authorized client archives
Pipeline
Capture date and provenance; compare with retained state to detect change
Atlas
Resolve entities; test candidates against event definitions and evidence rules
Ledger
Accepted events join the situation history with prior and new states
Lens
Select relevant events; assess potential impact using the client’s criteria
Output
Signals, indicators, forecasts, and resolutions through the agreed schema
AppliedXL serves enterprise data and information companies, investment firms, and exchanges.
The Atlas defines every event the system is built to detect, the evidence required to verify it, and the relationships that connect it to a larger situation.
Event family
The Atlas defines what to monitor and what qualifies as an event.
The shared Atlas is a versioned set of definitions covering sources, entities, event taxonomies, sector-specific event types, lifecycle states, evidence requirements, and permitted-combination rules. Sector Event Atlases present the domain-specific definitions within this shared framework. Private extensions add client-specific concepts on top of it.
| Layer | Contents | Owner |
|---|---|---|
| Cross-sector taxonomies | Event families that recur across sectors: operational, regulatory, credit and financial. Common instruments and lifecycle states. | AppliedXL |
| Domain definitions | Per sector: the actors, terminology, source records, lifecycle stages, and acceptance rules for each event type. | AppliedXL |
| Source and entity catalog | Curated high-impact sources with their publication behavior; reference tables for entity resolution. | AppliedXL |
| Private extension | Client-specific terminology, entity relationships, event subtypes, and evidence requirements found in authorized client material. | Client (confidential) |
| Coverage profile | Per deployment: which sectors, sources, entities, and event types are monitored. | Agreed per deployment |
A drug approval and a mining permit share an authorization framework, but each requires its own evidence. The sector and taxonomy tables are in Coverage.
The first biopharma Atlas took roughly six months while AppliedXL built the underlying platform. The carbon Atlas took three weeks using existing registries, the combination generator, the review workflow, and delivery infrastructure. These timelines cover Atlas development. Full deployment also requires source integration, entity resolution, and coverage validation.
News archives, analyst notes, and research contribute historical cases, terminology, relationships, and institutional context. Applying the Atlas to these records can reveal concepts absent from the shared definitions. A private extension captures them. The client's Lens then applies its analytical criteria to the resulting events.
In the pharma Atlas, a change to a trial's primary completion date is an event type with a defined threshold for Significantly Delayed. The evidence requirement is the prior and current registry values with their observation dates. A readout commitment requires a source establishing the dated commitment; a completion-date change is a separate operational event.
The Ledger preserves what changed, when it changed, and the evidence behind it. It connects individual events into a persistent history that can be inspected, compared, and verified. Automated fact-checks cross-reference sources and flag conflicting accounts.
Heart-failure study
Every event is checked against source evidence using computational journalism automated workflows.
Low expected benefit;
congestion concerns.
Within its retained observation history, the Ledger supports point-in-time reconstruction of source states, including values overwritten in the original source.
| Retained | Used for |
|---|---|
| Observations | The next comparison; reconstruction of the retained record at a selected date. |
| Event histories | Sequence analysis within a situation; connecting a new event to earlier ones. |
| Data provenance | Links from each classification and assessment to dated observations and supporting source passages. |
| Held and rejected candidates | Follow-up review when evidence changes; evaluation of acceptance decisions. |
| Review decisions | Benchmark judgments; audit of overrides. |
| Forecasts and resolutions | Accuracy and calibration evaluation against outcomes. |
| Known gaps | Attached to the observation history where a source interruption occurred. |
In Eli Lilly’s volenrelaxin trial, enrollment closed on the same record date that planned primary completion moved ten months earlier. The Ledger retains these as separate events linked to the same trial.
The same event can have different implications for each institution. A Client Lens evaluates it against the companies, products, exposures, and priorities the client follows, then traces its potential effect through revenue, cost, market access, and other defined channels.
FDA warns Hims & Hers over claims implying its compounded semaglutide products are the same as FDA-approved medicines and requests corrective action.
The warning letter directly names Hims & Hers. Marketing changes at one provider could affect how it attracts patients and competes for business.
For a telehealth peer such as Ro, the relevance is competitive. The letter does not establish that the same violations apply.
Compare each company’s dependence on compounded-drug offerings and test whether customer-acquisition and revenue-growth assumptions need revision.
A Client Lens sets the focus, relevance criteria, and impact assessments for one institution.
A Client Lens is a versioned configuration of four components applied to accepted events: scope, routing, exposure records, and scores.
| Component | Function |
|---|---|
| Scope | Selects the companies, company types, event types, and geographies relevant to the institution. |
| Routing | Connects events to institutional categories through a mechanism: revenue, cost, financing, market access, physical supply, demand, or a client-defined channel. |
| Exposure records | Establish the party’s relationship to an event and assess its implications: mechanism, direction, time horizon, magnitude, confidence, and evidence. |
| Scores | Provide an optional quantitative summary using the institution’s selected metrics and weights. |
One policy Lens uses two scoring components. Magnitude measures expected economic reach. Authority measures the acting institution's capacity to implement or enforce the event. Both use a 1 to 10 scale. Clients can use their own metrics alongside them.
AppliedXL detects what changed, measures the pattern, forecasts what may happen next, and verifies the eventual outcome.
Bristol Myers Squibb and Johnson & Johnson stopped the Phase 3 LIBREXIA ACS trial after an interim analysis found milvexian was unlikely to meet its primary cardiovascular efficacy endpoint. No new safety signal was identified.
The failure increases skepticism toward Factor XIa inhibition in acute coronary syndrome, with the strongest competitive readthrough for Bayer’s asundexian and a broader, more limited readthrough for Anthos/Novartis’s abelacimab. Milvexian’s separate LIBREXIA AF and STROKE trials remain underway, with results expected in 2026.
Share of trials recruiting at the start of the window that closed recruitment during it.
| Output | Contents | Availability |
|---|---|---|
| Signals | Published briefs based on accepted events, with the subject, event type, observation date, evidence, prior and new states where applicable, and Lens assessments. | All deployments. |
| Indicators | A numeric measure such as an event aggregate or index value, with its universe, calculation method, version, and update schedule. | Deployments can produce indicators alongside event feeds before a domain supports forecasting. |
| Forecasts | A probability for a specified outcome by a specified date, with the evidence and assumptions available at issuance. | Depends on the domain's comparable history and a validated estimation method. |
| Resolutions | Whether and when an outcome occurred, determined under the evidence rule fixed at issuance. | Wherever a forecast or a dated commitment exists. |
Comparable histories with known outcomes inform forecast probabilities. Each estimate uses only information observable at its assessment date. New evidence can update the estimate; the Ledger retains earlier versions for evaluation.
In the pharma domain for example, the model reconstructs up to 500 biological and operational event inputs as they would have been known at each historical date. It separately estimates completion, schedule adherence, endpoint attainment, regulatory approval, and clinical significance, then updates those estimates as new events enter the Ledger. The checkpoints are separate questions and can resolve at different times. Read each probability against its calculation date and underlying evidence.
Resolution tests later evidence against the outcome rule fixed when the forecast or commitment was recorded. For a readout commitment, the question is whether the readout occurred within the announced window. Each conclusion requires its own evidence: a registry update establishes operational status; an efficacy disclosure establishes the endpoint result; a timing assessment needs a dated sponsor commitment linked to the relevant disclosure; program discontinuation needs a separate sponsor statement. Insufficient evidence leaves an outcome unresolved.
AXL Core converts fragmented source material into persistent, connected objects. Each object has defined fields, evidence requirements, provenance, and rules governing how it can change.
| Term | Definition |
|---|---|
| Source | A monitored public record or an authorized client archive. |
| Observation | A capture of source material at a stated time, with provenance. |
| Candidate event | A possible occurrence extracted from an observation, before acceptance as an event. |
| Event | An accepted occurrence that meets an Atlas event definition and its evidence requirements. |
| Candidate event awaiting evidence | A possible occurrence that does not yet meet the event definition’s evidence requirements. |
| Evidence | A passage or record that supports a specific claim. |
| Context | Retained material that supports retrieval and interpretation without itself being an event or evidence. |
| Entity | A company, product, agency, program, project, facility, or instrument with resolved identifiers. |
| Situation | The connected history of events, candidate events, evidence, forecasts, and outcomes for one subject. |
| Exposure record | A Lens assessment of an event's implication for one party or asset. |
| Score | A summary of exposure assessments using an institution's metrics and weights. |
| Indicator | A numeric measure derived from events, such as an aggregate or index value. |
| Forecast | A probability for a specified outcome by a specified date, issued with its evidence. |
| Resolution | A determination of whether and when an outcome occurred, under a fixed evidence rule. |
| Review decision | A reviewer's approval, revision, rejection, or override of a system result. |
| Coverage profile | A deployment's specification of sectors, sources, entities, and event types to monitor. |
| Private extension | Client-specific additions to the shared Atlas: terminology, relationships, event subtypes, evidence rules. |
AppliedXL selects sources for impact and monitors them according to their publication behavior.
Some sources display only the latest state. Detecting a change in such a source depends on an earlier observation held in the Ledger.
AXL Core compares each new observation with the retained prior state.
Rule. Observation and occurrence dates use separate fields. Record the occurrence date only where established. See Evaluation for latency measurement.
Structured records yield candidates through field, lifecycle, structural, and semantic comparison. AXL Core decomposes articles, releases, and transcripts into candidates and links each to its supporting passage.
Rule. The Ledger retains rejected candidates and their reason codes for later evaluation and configuration changes.
A candidate becomes an event when it has an in-scope actor and event type and the evidence the Atlas definition specifies.
Rule. Related occurrences keep separate identities. A complaint, an injunction, and a settlement are three events connected to the same case.
A formal proposal can qualify as an event; a stated intention may remain a candidate event until further evidence establishes a qualifying occurrence.
Published Signals are briefs based on accepted events.
Rule. These candidate events remain in the situation history and can become events when later evidence meets the event definition and its evidence requirements.
Verification is claim-specific: a revised trial date supports the finding that the date changed; an explanation of the cause needs its own support.
Background on a program, an entity's history, or terminology from a client archive can be context.
Entity resolution connects references to the same entity across sources that use different names or identifiers.
Reference tables and client identifiers support resolution. Reviewers can inspect and correct resolution decisions using the retained records.
A new observation can add an event, update an existing event, strengthen an earlier candidate event, or establish an outcome.
Sequence analysis evaluates a new event against prior events in the same situation and against timing thresholds. The RELATIVITY-098 case study shows earlier delays followed by a large pull-in, with prior values retained.
An event can carry several exposure records, one per affected party.
See Lens for score components, retained calculations, and handling of uncertainty.
See Outputs for calculation methods, forecast requirements, and outcome rules.
Each decision records the authorized reviewer, reason, and date.
Rule. The system preserves review decisions for inspection and uses them as benchmark judgments in later evaluation.
The Atlas defines what can happen. The Ledger preserves what did happen. Each Client Lens determines why it matters. Their versions remain separate, allowing domain coverage, accumulated history, and institutional priorities to evolve independently.
| Component | What it controls | How it evolves |
|---|---|---|
| Atlas | Sources, entities, taxonomies, event definitions, lifecycle states, evidence requirements, private extensions. | Coverage expands or definitions are revised. Versioned with stable event codes and a change log. |
| Ledger | Observations, event histories, evidence, held and rejected candidates, review decisions, forecasts, resolutions. | The Ledger adds new observations and decisions while retaining superseded states. |
| Lens | Scope, routing, exposure assessments, scores, thresholds, weights for one institution. | Client priorities change. Versioned separately from the Atlas. |
The shared Atlas, each private extension, and each Lens carry separate version numbers. Each deployment records the versions it runs.
Every new observation moves through a defined sequence of comparison, resolution, classification, verification, recording, and client-specific assessment.
Source records
Observations; candidate events
Semantic comparison; decomposition of prose into candidates
Collection, scheduling, provenance, exact field and structural comparison
Candidates
Candidates linked to resolved entities and events
Assist matching across names and formats
Reference tables, client identifiers, match rules
Resolved candidates
Proposed event classification, evidence, or context
Classification against Atlas definitions
Permitted-combination checks
Classified candidates
Accepted events; held or rejected candidates, with evidence links
Check candidate claims against source evidence and Atlas requirements
Context retrieval and assembly, structured validation, provenance links
Observations; accepted events; held and rejected candidates; review decisions
Ledger entries
Ledger writes; review routing; decision capture
Accepted events and their supporting Ledger history
Assessed events in the agreed schema
Exposure assessment; institutional analysis
Score calculation, schema mapping, delivery
The system holds candidate events that lack sufficient evidence and routes cases requiring judgment for review. Every approval, revision, rejection, or override becomes part of the permanent Ledger record.
Authorized reviewers make these decisions.
AppliedXL combines sector-specific Atlases with shared regulatory, operational, and financial taxonomies. This allows the same underlying event mechanism to be recognized across different industries, entities, and asset classes.
| Sector | Scope | Events covered |
|---|---|---|
| Pharma & Biotech | Clinical development, drug approvals, safety, market access | Trial enrollment changes, endpoint revisions, readout delays, clinical results, drug approvals, safety findings. |
| Energy | Power generation, grid connections, project permitting, capacity development | Generation project announcements, permit decisions, grid connection milestones, construction delays, capacity additions. |
| Carbon Markets | Project registration, verification, credit issuance and retirement | Project registration, methodology changes, verification, credit issuance, retirement. |
| Mining & Critical Materials | Exploration, permitting, processing, supply agreements | Exploration results, resource estimate revisions, permit decisions, processing capacity changes, supply agreements. |
| AI Infrastructure | Compute pricing, data centers, semiconductors, power capacity | Compute pricing changes, data center development, chip supply agreements, power procurement, capacity additions. |
Use arrow keys to move between families or events. Home and End select the first or last item.
| Taxonomy | Events covered |
|---|---|
| Operational | Product and project milestones, development delays, outages, production interruptions, facility closures. |
| Regulatory | Rule changes, authorization and permit decisions, enforcement actions, sanctions, trade restrictions. |
| Credit & Financial | Corporate borrowing, missed payments, defaults, restructuring. |
One underlying event. Different implications across markets.
Taxonomy mapping
Evidence needed
AXL Core is model-agnostic. Each task can use the provider and configuration best suited to its quality, latency, security, and cost requirements.
| Option | Arrangement |
|---|---|
| AppliedXL-managed | AppliedXL supplies model access under its own provider agreements. |
| Client-supplied | The deployment uses a supported provider through the client's API keys. See Client data for processing terms. |
Detection, extraction, retrieval, verification, classification, and forecasting can use different model configurations. Each is evaluated independently for quality, latency, and cost.
The Atlas, Ledger, and Client Lens remain intact when a deployment changes supported model providers. Definitions, accumulated evidence, client criteria, and prior outcomes do not have to be rebuilt.
Optimization improves definitions, retrieved context, prompts, thresholds, and scoring without training on client data or changing model weights.
Each deployment begins with the decisions the system must support and ends with a continuously operating intelligence feed.
Select the subject area, entities, event coverage, and sources, including authorized client archives where relevant.
Specify the decisions to support, intended users, relevance criteria, materiality thresholds, scoring, and routing. Use representative cases to set desired outputs.
Define the product, schema, cadence, and destination, plus the model provider, API access, and permitted inputs.
Process representative records. Evaluate configuration refinements against benchmark cases and quality, latency, and cost targets.
Begin continuous processing through the agreed API or feed. Monitor coverage, output quality, and delivery performance. Route exceptions for review.
The client defines the intended decisions and acceptance criteria. AppliedXL operates the recurring collection, detection, verification, assessment, and delivery system. Domain experts and authorized reviewers handle the cases that require institutional judgment.
Performance is evaluated across detection, verification, institutional interpretation, forecasting, operations, and efficiency. Results remain tied to the exact coverage, configuration, evidence cutoff, and benchmark cases tested.
| Area | Assessment basis |
|---|---|
| Detection and verification | Agreement with reviewed event labels; precision and recall within covered sources; evidence support; false acceptances and missed events. |
| Institutional interpretation | Agreement with benchmark judgments; routing and scoring consistency; reviewer corrections and overrides. |
| Operations | Source continuity; processing and delivery latency; exception rates; review requirements; recovery from interruptions. |
| Forecasting | Accuracy and calibration against resolved outcomes, using information available at issuance, compared with simpler baselines. |
| Efficiency | Processing cost, latency, and review effort for a defined workload; effort to add and maintain coverage. |
Comparisons use the same cases and the same information cutoff.
Latency measurements distinguish source publication (where known) from first observation, verification, and delivery.
The system evaluates changes to the Atlas, private extensions, Lenses, or models, along with material source changes, against relevant tasks and benchmark cases before adoption. Production records, rejected candidates, corrections, and resolved outcomes inform this evaluation.
The system tracks source interruptions and format changes during operation. Collection is updated to restore coverage, and known gaps remain attached to the observation history. Recovery of missed observations depends on what the source or available archives preserve. Reviewers can inspect and correct identity and classification errors using supporting records, retained decisions, and overrides.
Detection depends on source coverage, publication timing, monitoring cadence, and verification. The system does not detect changes in unmonitored sources.
Public-source deployments require no access to internal client systems. When proprietary material is authorized, its use, retention, processing, and ownership are explicitly defined.
AppliedXL does not train or fine-tune models on client data. Authorized material is used only for inference, retrieval, evaluation, and configuration within the client’s private Atlas extension and Lens. Client corrections, context, and proprietary analytical criteria remain within the authorized deployment.
Each deployment specifies permitted inputs, approved model-provider endpoints, credential access, and retention and training terms. When a client supplies its own provider API keys, the provider's processing terms form part of that arrangement. Access requirements depend on the selected delivery method and on whether the deployment includes proprietary material.
| Asset | Ownership or treatment |
|---|---|
| Client material | Supplied archives, analyst notes, research, and other proprietary inputs remain the client's property. |
| Client criteria and context | Proprietary definitions and analytical criteria encoded in a private extension or Lens remain the client's confidential intellectual property. |
| Client-specific deliverables | Agreed intelligence feeds, scores, indicators, and index values are assigned to the client as the agreement specifies. |
| AppliedXL technology | The shared Atlas, cross-sector taxonomies, detection and resolution methods, Ledger infrastructure, Lens framework, orchestration, software, and reusable methods remain with AppliedXL. |
| Third-party inputs | Models and source material remain subject to their applicable ownership and usage terms. |
Shared technical improvements remain separate from client content, proprietary criteria, and institutional judgment.
Bristol Myers Squibb · RELATIVITY-098 · Phase 3 melanoma
The system followed RELATIVITY-098 from registration through enrollment changes, timeline revisions, endpoint failure, termination, publication, and final registry results.
The study enrolled people whose stage III–IV melanoma had been completely removed by surgery.
PD-1 and LAG-3 are immune checkpoints that can limit the immune system’s response to cancer.
Trial registered.
Status changed from Not yet recruiting to Recruiting. Primary completion moved from July 29, 2025 to December 14, 2025, a delay of about five months.
Primary completion moved from December 14 to December 15, 2025.
A one-day revision was retained but was not material on its own.
Primary completion moved from December 15, 2025 to February 15, 2026, a further delay of about two months.
Cumulative primary-completion delays reached 201 days.
Status changed from Recruiting to Active, not recruiting.
Enrollment closed. The study remained active.
Primary completion moved from February 15, 2026 to December 16, 2024, a 14-month pull-in. Enrollment increased from 1,050 to 1,190, or 13.3%.
The new record placed primary completion in the past and reversed the earlier delays.
The trial failed its primary endpoint.
Status changed from Active, not recruiting to Terminated.
The operational status was updated after the endpoint failure.
Phase 3 results were published.
Added peer-reviewed evidence after the initial readout.
Tumor and peripheral biomarker findings were presented at ESMO.
Added evidence that could inform future combination strategies despite the failed endpoint.
Results became available in the registry. Enrollment was revised from 1,190 to 1,093, an 8.2% reduction.
RELATIVITY-098 changed from Active, not recruiting to Terminated on May 19, 2025, following its primary endpoint failure on February 13. The study had closed enrollment in September 2023 and later moved its primary completion date 14 months earlier, reversing 201 days of earlier delays.
Opening estimate
Relative to a typical trial: 7.90 percentage points lower.
Did nivolumab plus relatlimab meet the Phase 3 primary endpoint against nivolumab alone?
| Output | Investor | Competitive intelligence |
|---|---|---|
| Signals | Remove the trial from the catalyst calendar; update the adjuvant melanoma valuation and review broader program exposure. | Update the competitor pipeline; assess the opportunity for another adjuvant approach. |
| Benchmark | Apply a higher evidence threshold in light of the cohort’s activity and failures; distinguish trial efficiency from clinical probability. | Compare internal duration and enrollment with the cohort; assess differentiation and execution speed. |
| Forecast | Use the opening endpoint probability in position sizing and probability-adjusted valuation before readout. | Adjust monitoring and commercial preparation to the competitor’s estimated probability of success. |
| Resolution | Replace the forecast scenario with the failed endpoint outcome; reassess value in other indications or assets. | Remove the trial from active competition; use biomarker findings to assess acceleration, partnering, or a change in program direction. |
Each new sector reuses the pipeline, Ledger, Lens framework, and shared regulatory, operational, and financial taxonomies. Domain development adds the sources, entities, event definitions, lifecycle states, and evidence requirements unique to that market.
Coverage expands fastest where existing definitions and infrastructure can be reused. Each addition is validated against representative records before entering production.
Shared taxonomies, including credit, also supply classification rules. For example, a new sector can reuse corporate-default definitions and extend permit and facility definitions. Sector selection considers source accessibility, event density, entity-resolution difficulty, and required specialist judgment. See Atlas for build timelines.
Shared source monitoring, event definitions, verification systems, and operating infrastructure can support multiple deployments. Client-specific work is concentrated in private extensions, Lens configuration, integration, and acceptance testing.
| Cost category | Main activities |
|---|---|
| Domain development | Establishing sources, entities, event definitions, lifecycle rules, and evidence requirements for shared coverage. |
| Client deployment | Configuring Lenses and private extensions, processing authorized archives, integrating delivery, testing acceptance, and additional engineering. |
| Continuous operation | Collection, inference, storage, verification, review, delivery, source maintenance. |
Public-source monitoring, verification, and source maintenance can serve several clients. Operating costs include shared coverage and the processing required for each client.
Public sources and model providers are broadly available. The durable advantage comes from the system built around them: formal event definitions, resolved entities, evidence rules, retained source states, review history, client-specific configurations, and resolved outcomes.
| Compounding asset | Why it becomes harder to reproduce |
|---|---|
| Domain and operating capability | Curated sources, event definitions, resolved identities, evidence checks, and review processes must be built and maintained for the covered domains. |
| Accumulated observation history | Earlier source states support comparisons and sequence reconstruction, including values no longer available from the original source. See Ledger for retained history and coverage. |
| Institutional configuration | Private definitions, benchmark judgments, exposure assessments, and materiality criteria adapt the system to each client's decisions. |