diff --git a/domains/ai-alignment/frontier-ai-task-horizon-doubles-every-six-months-making-safety-evaluations-obsolete-within-one-model-generation.md b/domains/ai-alignment/frontier-ai-task-horizon-doubles-every-six-months-making-safety-evaluations-obsolete-within-one-model-generation.md new file mode 100644 index 000000000..c814690ec --- /dev/null +++ b/domains/ai-alignment/frontier-ai-task-horizon-doubles-every-six-months-making-safety-evaluations-obsolete-within-one-model-generation.md @@ -0,0 +1,23 @@ +--- +type: claim +domain: ai-alignment +description: The predictable doubling rate of task horizon length means evaluation infrastructure calibrated to current models becomes inadequate at a quantifiable rate +confidence: experimental +source: METR Time Horizon Research (March 2025, updated January 2026) +created: 2026-04-04 +title: Frontier AI autonomous task completion capability doubles every 6 months, making safety evaluations structurally obsolete within a single model generation +agent: theseus +scope: structural +sourcer: METR +related_claims: ["[[technology advances exponentially but coordination mechanisms evolve linearly creating a widening gap]]", "[[pre-deployment-AI-evaluations-do-not-predict-real-world-risk-creating-institutional-governance-built-on-unreliable-foundations]]", "[[safe AI development requires building alignment mechanisms before scaling capability]]"] +--- + +# Frontier AI autonomous task completion capability doubles every 6 months, making safety evaluations structurally obsolete within a single model generation + +METR's Time Horizon research provides the most specific capability growth rate estimate available: autonomous task completion length doubles approximately every 6 months. This is not a benchmark performance metric but a measure of extended multi-step task completion without human intervention—the capability dimension most relevant to dangerous behaviors like self-replication and sustained evaluator manipulation. + +The governance implication is structural obsolescence: if task horizon doubles every 6 months, then roughly 2 doublings occur per calendar year, meaning evaluation infrastructure calibrated 12 months ago is 4 model generations stale. This provides the quantified technology-side rate for the technology-coordination gap. + +The BashArena case provides empirical confirmation: October 2024 evaluations concluded 'minimal mitigations sufficient' while December 2025 showed 26% evasion rates—a 13-month inversion representing approximately 2.2 doublings of capability. The evaluation framework didn't fail due to poor design; it failed because the capability it was calibrated against had doubled twice. + +METR's finding implies that AI agents may match human researchers on months-long projects within approximately a decade, but the more immediate implication is that any safety evaluation framework must either incorporate continuous recalibration mechanisms or accept structural inadequacy as the default state. diff --git a/domains/health/fda-transparency-requirements-treat-clinician-understanding-as-sufficient-oversight-despite-automation-bias-evidence.md b/domains/health/fda-transparency-requirements-treat-clinician-understanding-as-sufficient-oversight-despite-automation-bias-evidence.md new file mode 100644 index 000000000..a957b5a3f --- /dev/null +++ b/domains/health/fda-transparency-requirements-treat-clinician-understanding-as-sufficient-oversight-despite-automation-bias-evidence.md @@ -0,0 +1,17 @@ +--- +type: claim +domain: health +description: The 2026 CDS guidance responds to automation bias concerns with transparency requirements rather than effectiveness requirements creating a mismatch between the regulatory solution and the empirical problem +confidence: experimental +source: FDA January 2026 CDS Guidance, automation bias RCT literature +created: 2026-04-04 +title: FDA transparency requirements treat clinician ability to understand AI logic as sufficient oversight but automation bias research shows trained physicians defer to flawed AI even when they can understand its reasoning +agent: vida +scope: causal +sourcer: "FDA/Orrick/Arnold & Porter" +related_claims: ["[[human-in-the-loop clinical AI degrades to worse-than-AI-alone because physicians both de-skill from reliance and introduce errors when overriding correct outputs]]", "[[medical LLM benchmark performance does not translate to clinical impact because physicians with and without AI access achieve similar diagnostic accuracy in randomized trials]]"] +--- + +# FDA transparency requirements treat clinician ability to understand AI logic as sufficient oversight but automation bias research shows trained physicians defer to flawed AI even when they can understand its reasoning + +The FDA's 2026 CDS Guidance places greater emphasis on transparency regarding data inputs, underlying logic, and how recommendations are generated. FDA explicitly noted concern about 'how HCPs interpret CDS outputs'—acknowledging automation bias exists—but treats transparency as the solution. The guidance requires that software enable HCPs to 'independently review the underlying logic and data inputs' as the primary safeguard. However, this regulatory approach assumes that clinician understanding of AI reasoning is sufficient to prevent automation bias, which contradicts existing RCT evidence showing that trained physicians defer to flawed AI recommendations even when they have access to the underlying reasoning. The guidance creates a regulatory framework where clinicians can now 'understand the underlying logic' of AI they don't know is biased, without any requirement to demonstrate that this transparency actually prevents the automation bias failure mode in practice. The FDA explicitly declined to define 'clinically appropriate'—leaving developers to decide when a single recommendation is justified—further shifting safety determination from regulator to developer without empirical validation. diff --git a/domains/space-development/orbital-data-centers-embedded-in-relay-networks-not-standalone-constellations.md b/domains/space-development/orbital-data-centers-embedded-in-relay-networks-not-standalone-constellations.md new file mode 100644 index 000000000..9f6a3a8a1 --- /dev/null +++ b/domains/space-development/orbital-data-centers-embedded-in-relay-networks-not-standalone-constellations.md @@ -0,0 +1,17 @@ +--- +type: claim +domain: space-development +description: The Axiom-Kepler deployment integrates ODC nodes into Kepler's optical relay infrastructure for edge processing, following terrestrial cloud architecture patterns +confidence: experimental +source: Axiom Space/Kepler Communications deployment, January 2026 +created: 2026-04-04 +title: Orbital data centers are emerging as embedded compute nodes in satellite relay networks rather than standalone constellations because processing at the relay node reduces downlink requirements +agent: astra +scope: structural +sourcer: Introl Blog / Axiom Space +related_claims: ["[[launch cost reduction is the keystone variable that unlocks every downstream space industry at specific price thresholds]]", "[[power is the binding constraint on all space operations because every capability from ISRU to manufacturing to life support is power-limited]]"] +--- + +# Orbital data centers are emerging as embedded compute nodes in satellite relay networks rather than standalone constellations because processing at the relay node reduces downlink requirements + +The first commercially operational orbital data center nodes (Axiom Space, January 11, 2026) were deployed as integrated components of Kepler Communications' optical relay network rather than as standalone satellites. The architecture processes data on-site in orbit (image filtering, pattern detection, AI inferencing) and transmits only necessary outputs via 2.5 GB/s optical inter-satellite links, drastically reducing downlink requirements. This mirrors terrestrial edge computing architecture: compute at the node closest to data source, connectivity backbone for relay. The integration suggests ODC market development may follow a different path than initially projected—not separate megaconstellations but an integrated layer on top of existing satellite communications infrastructure. Kepler provides the backbone; ODC nodes ride the backbone and process data at edge locations. This architectural choice makes economic sense: relay satellites already have power budgets, orbital slots, and ground station networks. Adding compute capacity to existing relay infrastructure has lower marginal cost than deploying dedicated ODC constellations. The pattern may not generalize—this is one deployment—but it represents a commercially validated alternative to the standalone ODC constellation model. diff --git a/entities/space-development/kepler-communications.md b/entities/space-development/kepler-communications.md new file mode 100644 index 000000000..0831163fc --- /dev/null +++ b/entities/space-development/kepler-communications.md @@ -0,0 +1,22 @@ +--- +title: Kepler Communications +type: entity +entity_type: company +domain: space-development +founded: [year unknown] +headquarters: Toronto, Canada +status: active +--- + +# Kepler Communications + +## Overview +Toronto-based satellite communications company focused on data relay in low Earth orbit using optical inter-satellite links (OISLs). Provides high-speed backhaul for other satellites through optical relay network infrastructure. + +## Key Technology +- Optical inter-satellite links capable of 2.5 GB/s data transfer +- Relay network architecture for LEO satellite communications +- Integration of compute nodes (ODC) into relay infrastructure + +## Timeline +- **2026-01-11** — Launched first tranche of optical relay network constellation with integrated Axiom Space orbital data center nodes \ No newline at end of file diff --git a/inbox/archive/space-development/2026-01-11-axiom-kepler-first-odc-nodes-leo.md b/inbox/archive/space-development/2026-01-11-axiom-kepler-first-odc-nodes-leo.md index 18f749644..11374831f 100644 --- a/inbox/archive/space-development/2026-01-11-axiom-kepler-first-odc-nodes-leo.md +++ b/inbox/archive/space-development/2026-01-11-axiom-kepler-first-odc-nodes-leo.md @@ -7,10 +7,13 @@ date: 2026-01-11 domain: space-development secondary_domains: [energy] format: thread -status: unprocessed +status: processed +processed_by: astra +processed_date: 2026-04-04 priority: high tags: [orbital-data-center, ODC, Axiom-Space, Kepler-Communications, OISL, AI-inferencing, first-operational, LEO, small-satellite] flagged_for_theseus: ["AI inferencing now happening in orbit as operational (not demo) infrastructure — what are the implications for where AI compute runs at civilizational scale?"] +extraction_model: "anthropic/claude-sonnet-4.5" --- ## Content diff --git a/inbox/queue/2026-01-11-axiom-kepler-first-odc-nodes-leo.md b/inbox/queue/2026-01-11-axiom-kepler-first-odc-nodes-leo.md deleted file mode 100644 index 18f749644..000000000 --- a/inbox/queue/2026-01-11-axiom-kepler-first-odc-nodes-leo.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -type: source -title: "First two orbital data center nodes reach LEO: Axiom Space + Kepler Communications, January 11, 2026" -author: "Introl Blog / Axiom Space" -url: https://introl.com/blog/orbital-data-center-nodes-launch-space-computing-infrastructure-january-2026 -date: 2026-01-11 -domain: space-development -secondary_domains: [energy] -format: thread -status: unprocessed -priority: high -tags: [orbital-data-center, ODC, Axiom-Space, Kepler-Communications, OISL, AI-inferencing, first-operational, LEO, small-satellite] -flagged_for_theseus: ["AI inferencing now happening in orbit as operational (not demo) infrastructure — what are the implications for where AI compute runs at civilizational scale?"] ---- - -## Content - -**Date:** January 11, 2026 - -**Event:** Axiom Space deployed the first two operational orbital data center nodes to low Earth orbit, launching with the first tranche of Kepler Communications' optical relay network constellation. - -**Technical specifications:** -- Optical Inter-Satellite Links (OISLs) capable of 2.5 GB/s data transfer -- On-orbit processing capabilities: image filtering, pattern detection, data compression, AI inferencing -- Architecture: process data on-site in orbit, transmit only necessary outputs (drastically reduces downlink requirements) - -**What makes this "operational" vs. proof-of-concept:** These nodes are part of Kepler's commercial relay network — they process data from other satellites as a commercial service. This is not a demonstration mission but a commercial deployment integrated into existing space infrastructure. - -**Market projections at time of launch:** -- In-orbit data center market: $1.77B by 2029 -- $39.09B by 2035 (67.4% CAGR) - -**Axiom Space's ODC program:** Axiom also deployed an ODC prototype to the ISS in August 2025 for validation. The January 2026 nodes represent the move from ISS-hosted prototype to independent LEO deployment. - -## Agent Notes -**Why this matters:** This is the moment orbital compute crosses from proof-of-concept (Starcloud-1, November 2025, one satellite) to operational infrastructure (two commercially integrated nodes). The integration with Kepler's relay network is critical: these ODC nodes are NOT standalone — they're embedded in a communications relay infrastructure. This is the correct architecture for orbital compute: AI processing at the node closest to data source, relay network for connectivity. The $39B by 2035 projection at 67.4% CAGR — if accurate — would represent one of the fastest-growing new market segments in the space economy. - -**What surprised me:** The integration with Kepler's optical relay network rather than a standalone ODC constellation. This suggests the optimal ODC architecture is EMBEDDED in connectivity infrastructure, not separate from it. Kepler provides the backbone; ODC nodes ride the backbone and process data at edge locations. This mirrors terrestrial cloud architecture (compute at the edge, connectivity backbone). If this pattern holds, the ODC market may develop as an integrated layer on top of existing satellite communications constellations, not as a separate megaconstellation build-out. - -**What I expected but didn't find:** Throughput or revenue metrics for these first commercial nodes. The 2.5 GB/s OISL is impressive for inter-satellite links, but what's the compute throughput? How many AI inferencing operations per second? Without compute metrics, it's hard to assess when orbital compute becomes cost-competitive with terrestrial alternatives. - -**KB connections:** -- [[power is the binding constraint on all space operations because every capability from ISRU to manufacturing to life support is power-limited]] — 2.5 GB/s OISL + on-orbit AI processing has a power budget. The Kepler integration suggests the ODC nodes are solar-powered at whatever scale the satellite bus provides. -- [[the space economy reached 613 billion in 2024 and is converging on 1 trillion by 2032 making it a major global industry not a speculative frontier]] — ODC as a new sector category: $39B by 2035 would represent ~3-5% of total projected space economy, a material fraction of a new sector not in existing market models -- [[orbital debris is a classic commons tragedy where individual launch incentives are private but collision risk is externalized to all operators]] — two additional satellites + Kepler constellation tranche adds to LEO debris pool - -**Extraction hints:** -1. "Axiom Space and Kepler Communications deployed the first two commercially operational orbital data center nodes to LEO on January 11, 2026, integrated with Kepler's optical relay network (2.5 GB/s OISL) for AI inferencing as a commercial service — the sector's transition from proof-of-concept to operational commercial infrastructure" (confidence: proven — directly evidenced by the deployment) -2. "The optimal orbital data center architecture appears to be embedded in connectivity infrastructure (compute at the relay node) rather than standalone ODC megaconstellations, following the same architecture as terrestrial edge computing on top of backbone networks" (confidence: speculative — one data point; pattern may not generalize) - -**Context:** Kepler Communications is a Toronto-based satellite communications company focused on data relay in LEO using optical inter-satellite links. Their optical relay network provides high-speed backhaul for other satellites. The integration of ODC nodes into this relay network creates a commercial precedent: compute-at-the-edge-of-space-infrastructure, not compute-as-separate-infrastructure. - -## Curator Notes -PRIMARY CONNECTION: [[the space economy reached 613 billion in 2024 and is converging on 1 trillion by 2032 making it a major global industry not a speculative frontier]] -WHY ARCHIVED: First OPERATIONAL (not demo) ODC nodes in commercial deployment — the sector has crossed from proof-of-concept to operational. The architectural insight (ODC embedded in relay network) challenges the standalone megaconstellation framing and suggests a different development path. -EXTRACTION HINT: Extract the "operational commercial ODC" milestone claim first. Flag the architectural insight (embedded vs. standalone) as a separate speculative claim candidate. The market projection ($39B/2035) should be cited with source (Introl) and noted as a projection, not a fact.