QRF is a class-independent infrastructure Core for massive, dynamic computation. The same protected Core is demonstrated across Routing, AI Resource Allocation, and Storage Placement & Replication without creating a new domain-specific engine per class. It is designed for integration across decision, control, orchestration, and execution layers while keeping the Core independent of any single domain or operational class. Published Routing evidence reaches 500M nodes / ~3.0B directed edges on a 6-core / 12-thread desktop-class PC with 16 GB RAM, using resource-adaptive operation beyond resident memory, with no GPU/HPC and no mandatory preprocessing. The three published classes are representative engineering proofs of the class-independent architecture, not its boundary. The 500M-node / ~3.0B-edge Routing result is separate scale-and-hardware evidence, demonstrating operation on a standard 6-core / 12-thread system with 16 GB RAM and no GPU/HPC.
One Core·No New Domain Engine per Class·Standard Hardware at Massive Scale
Engineering Validation: Gates 1–3 are PASS under frozen benchmark conditions. Gate 4 is PASS for the tested service workload across Routing, AI Resource and Storage, including updates under load and state correctness.
0.8095 ms p95 AI Resource at 100M · median Core-post p95
0.8923 ms p95 Storage at 100M · median Core-post p95
6-core / 12-thread 16 GB RAM · no GPU/HPC
Why QRF
QRF changes the unit of infrastructure implementation. One reusable Core can support distinct operational classes without a separate domain-specific engine for each one, while published evidence demonstrates massive-scale operation on standard desktop-class hardware without GPU/HPC. Routing, AI Resource Allocation, and Storage Placement & Replication are proof points for the architecture — not three separate products.
500Mnodes tested in Routing
~3.0Bdirected edges
< 1 msAI & Storage Core-post p95 at 100M in the measured suite; excludes upstream work and API overhead
16 GBRAM benchmark system
How the Operating Model Changes
Common Domain-Specific Pattern
QRF Operating Model
Domain-specific implementation
Reusable class-independent Core
New class requires new domain engine
New operational class without a new domain-specific engine
Single system-layer role
Core usable across system layers
Fixed use case
Extensible operational classes
Resident-memory-centric execution
Resident + resource-adaptive operation
Preprocessing-dependent architecture
No mandatory preprocessing
State-size-coupled execution pressure
Resource-aware execution at massive scale
Selected capability comparisons. Supporting evidence and measurement boundaries are available for technical review.
Massive Scale
QRF Routing evidence spans from 1M to 500M tested nodes and reaches approximately 3.0B directed edges. Across the published range, QRF demonstrates practical Core execution as graph size increases, including resource-adaptive operation beyond resident-memory scale.
At the tested 100M scale, AI Resource Allocation and Storage Placement & Replication remain below 1 ms median Core-post p95 across five measured runs. Full API/service-path latency is evaluated separately.
AI ~1.66× · Storage ~1.78× median Core-post p95 growth across 100× scale
Standard Hardware
Published engineering benchmarks were produced on a 6-core / 12-thread general-purpose desktop with 16 GB RAM. At 200M and 500M Routing scale, resource-adaptive execution is used as the dataset exceeds available resident memory; no GPU or HPC platform is required for the published evidence.
6-core / 12-thread · 16 GB RAM · no GPU/HPC
Class-Independent Core
Routing, AI Resource, and Storage keep their own workload and result semantics while preserving the same Core architecture.
One Core · No New Domain Engine per Class
Separate Evidence Streams
Each operational class has its own workload, result type, latency, throughput, and validation evidence. This produces independently interpretable evidence for Routing, AI Resource Allocation, and Storage while preserving the same class-independent Core model.
Separate workloads · Separate results · vendor-controlled same-Core binary attestation
Engineering Evidence → Technical Due Diligence
QRF enters technical discussions with a defined engineering evidence base. Organizations can review the architecture, benchmark evidence, and measurement boundaries against their own infrastructure requirements; existing results and supporting records are available for verification during technical due diligence.
Evidence Review → Due Diligence → Integration
Lower Total Cost of Ownership (TCO)
QRF’s value extends beyond execution speed to infrastructure efficiency and total cost of ownership. Hardware requirements shape both upfront investment and recurring operating costs. Where QRF enables a workload to run on fewer or smaller machines, the benefits can extend beyond equipment acquisition to electricity, cooling, rack and facility space, and staff time for deployment, monitoring, maintenance, and hardware replacement.
Cost Area
Potential Benefit of a Smaller Hardware Footprint
Hardware & Lifecycle
Fewer machines to purchase, provision, maintain, and replace
Existing Infrastructure
Potential to use current equipment more effectively and defer upgrades where workload and service requirements permit
Power
Lower electricity demand from a smaller equipment footprint
Cooling
Less equipment heat to remove and lower associated cooling demand
Space
Reduced rack, server-room, and facility-space requirements
Operations & Staff Time
Less hardware administration and maintenance effort, freeing staff capacity for other work
Evidence and economic scope: Published QRF benchmarks demonstrate the reported workloads on a standard 6-core / 12-thread desktop with 16 GB RAM and no GPU/HPC. Power, cooling, space, and staffing savings have not been quantified by those benchmarks; actual benefits depend on the infrastructure replaced, utilization, deployment design, and service requirements.
The QRF Difference
One reusable Core. Multiple operational classes. Massive scale on standard hardware. Routing, AI Resource, and Storage are proof points; the Core is the asset.
Application Domains
QRF is not bound to one domain or one system layer. The class-independent Core is designed for integration across large, dynamic system environments and across decision, control, orchestration, and execution layers. The examples below illustrate potential environments; published benchmark evidence remains separately identified in the Technical Evidence sections.
MOBILITY
V2X & Connected Mobility
Dynamic vehicle, roadside, and mobility-network systems with changing topology, connectivity, state, and operational constraints.
V2XVANETConnected vehicle
CONNECTED INFRASTRUCTURE
IoT, Telecom & Edge
Large connected-device, gateway, telecom, and edge environments with continuously changing state, resources, relationships, and execution requirements.
IoT / IIoTTelecomEdge
GRAPH-BASED SYSTEMS
Dynamic Infrastructure Systems
Large graph-representable systems whose state, relationships, constraints, and operational actions change over time.
Large graphsDynamic stateInfrastructure Core
Evidence coverage: Published performance figures cover Routing, AI Resource Allocation, and Storage Placement & Replication. These are the current public evidence streams for the class-independent Core; they do not define the architectural boundary of QRF.
Beyond the Current Benchmarked Classes
QRF separates the protected Core from class identity. Routing, AI Resource Allocation, and Storage Placement & Replication provide three published evidence streams; they demonstrate that the same architecture is not hard-coded to one domain. Additional expressible classes can be introduced through the class contract without redefining QRF as a new domain-specific engine.
One Core Above Individual Classes and Layers
QRF is designed for integration across decision, control, orchestration, and execution environments. Current public benchmarks document three operational classes. Further integrations are discussed against the target requirements, with confidential implementation details reserved for an appropriately protected technical review.
QRF extends the protected class-independent Core through an operational service architecture designed for controlled integration and deployment. The same service model supports Single-Host and Distributed topologies across SaaS, Private Cloud, On-Premise, and Edge environments.
Single-Host & Distributed
Self-contained deployments and distributed infrastructure use the same QRF service model, allowing deployment topology to change without redefining the Core architecture.
Operational Control Plane
Centralized management covers companies, environments, class types, graph versions, licenses, credentials, limits, and operational resources.
Protected Execution Layer
Controlled API access supports authorized use of QRF with defined access policies and operational limits. Proprietary implementation details are reserved for confidential technical review.
Operations & Governance
Queue and execution visibility, monitoring, roles and access control, audit logs, incidents, backups, and platform-service management provide the surrounding operational controls.
Pilot-stage integration: Following evidence verification and technical due diligence, a jointly agreed pilot supports interface alignment, deployment coordination, and integration into the target environment. Its scope builds on existing engineering evidence and agreed access policies.
Class 01 — Routing Decision
Routing Decision is QRF Class 01. Its benchmark evidence is measured independently, while AI Resource and Storage maintain their own class-specific KPIs and evidence streams.
Result Snapshot
Maximum tested scale500M nodesLargest published Routing scale, demonstrating operation on a graph containing approximately 3.0B directed edges.
Median p958.8663 msMedian Routing engine-query p95 across 5 stable measured runs at the 500M-node scale; the Hybrid result is conditioned fixed-hotset steady-state, not cold/unseen-pair or full API latency.
Measured benchmark runs25Five stable measured runs at each of five Routing scales.
HardwareStandard PCThe same standard desktop-class benchmark context is disclosed publicly to make the scale-to-hardware relationship clear.
QRF Public Technical BriefA concise overview of QRF positioning, benchmark proof points, application areas and evidence review pathway.
55 measured benchmark runs are represented on this page: Routing 25, AI Resource 15, and Storage 15. A vendor-controlled same-binary attestation links all three classes to the same frozen Core binary. This is engineering evidence, not third-party certification.
QRF Technical Demo
100M nodes • 600M edges • 10 live routing queries • 10/10 valid
Watch QRF execute and validate routing queries on a 100M-node / 600M-edge graph.
Controlled technical demonstration at 100M nodes / 600M edges. Production KPI and SLA qualification are established separately for the target deployment environment.
Routing Benchmark Results
Scale
Edges
Scale Class
Memory Mode
Median p95
Measured Runs
1M
6M
Standard-scale
Memory-resident
0.2452 ms
5/5
10M
60M
Standard-scale
Memory-resident
0.4478 ms
5/5
100M
600M
Standard-scale
Memory-resident
1.0036 ms
5/5
200M
1.2B
Large-scale
Memory-adaptive
3.4782 ms
5/5
500M
3.0B
Large-scale
Memory-adaptive
8.8663 ms
5/5
Measurement Scope
The figures above report median p95 across five stable measured runs per scale. At 200M and 500M, Routing uses Hybrid conditioned fixed-hotset steady-state engine-query scope; these figures are not cold/unseen-pair latency or full API/service-path latency. Existing results are reviewed within their stated measurement scope. Target-environment service requirements and deployment-specific SLAs are addressed separately during integration planning.
Class 01 Routing — Core p95: 1M-100M
Median p95 across 5 stable measured runs per scale
Median p95 reaches 1.0036 ms at 100M tested nodes.
Class 01 Routing — Core p95: 200M-500M
Median p95 across 5 stable measured runs per scale
Median p95 is 8.8663 ms at 500M tested nodes / approximately 3.0B edges, under conditioned fixed-hotset steady-state Hybrid scope.
Routing Engineering Evidence
Published results span 1M to 500M tested nodes, approximately 6M to 3.0B edges, and 25 stable measured runs.
Class 02 — AI Resource Allocation
AI Resource Allocation is QRF Class 02. It evaluates AI-infrastructure resource decisions and returns dedicated class-specific allocation results with its own benchmark evidence.
Result Snapshot
Scale100MLargest currently published AI Resource Allocation benchmark scale using the frozen workload.
Frozen workload1000 jobs/runThe same 1000-job workload is used at every tested scale to improve comparability between 1M, 10M, and 100M.
Median p950.8095 msMedian Core-post p95 across 5 stable measured runs at 100M.
Median throughput2,398 jobs/sMedian decision throughput across 5 stable measured runs at 100M.
Benchmark scope1M / 10M / 100M · 1000 frozen jobs/run · 5 measured runs/scale · benchmark suite
Benchmark Results
Scale
Workload
Median mean / request
Median p95
Median throughput
Measured Runs
1M
1000 frozen jobs/run
0.246 ms
0.4870 ms
4,014 jobs/s
5/5
10M
1000 frozen jobs/run
0.327 ms
0.5907 ms
3,022 jobs/s
5/5
100M
1000 frozen jobs/run
0.415 ms
0.8095 ms
2,398 jobs/s
5/5
AI Resource latency and throughput are reported under measured Core execution (excluding upstream processing and Python overhead) scope on the frozen workload. One clean conditioning observation per scale is retained as NOT_MEASURED; five stable measured runs are then collected per scale. Full API/service-path metrics are evaluated separately.
Class 02 AI Resource — Core-post p95
Median Core-post p95 across 5 measured runs per scale
At 100M scale, median Core-post p95 is 0.8095 ms.
Class Evidence
Class-specific workload: The same frozen 1000-job workload is used at each tested scale.
Class-specific result: The public result is a dedicated AI Resource Allocation decision result.
Low-latency evidence: Five stable measured runs are collected at each scale after a non-measured clean conditioning observation.
Class 03 — Storage Placement & Replication
Storage Placement & Replication is QRF Class 03. It evaluates distributed-storage placement and replication decisions and returns dedicated class-specific storage results with its own benchmark evidence.
Result Snapshot
Scale100MLargest currently published Storage Placement & Replication benchmark scale using the frozen workload.
Frozen workload1000 requests/runThe same 1000-request workload is used at every tested scale to support scale-to-scale comparison.
Median p950.8923 msMedian Core-post p95 across 5 stable measured runs at 100M.
Median throughput2,539 req/sMedian decision throughput across 5 stable measured runs at 100M.
Benchmark scope1M / 10M / 100M · 1000 frozen requests/run · 5 measured runs/scale · benchmark suite
Benchmark Results
Scale
Workload
Median mean / request
Median p95
Median throughput
Measured Runs
1M
1000 frozen requests/run
0.227 ms
0.5027 ms
4,270 req/s
5/5
10M
1000 frozen requests/run
0.312 ms
0.6675 ms
3,161 req/s
5/5
100M
1000 frozen requests/run
0.389 ms
0.8923 ms
2,539 req/s
5/5
Storage latency and throughput are reported under measured Core execution (excluding upstream processing and Python overhead) scope on the frozen workload. One clean conditioning observation per scale is retained as NOT_MEASURED; five stable measured runs are then collected per scale. Full API/service-path metrics are evaluated separately. Placement success and decision quality are documented within the class-specific evidence scope and are available for verification during technical due diligence.
Class 03 Storage — Core-post p95
Median Core-post p95 across 5 measured runs per scale
At 100M scale, median Core-post p95 is 0.8923 ms.
Class Evidence
Class-specific workload: The same frozen 1000-request Storage workload is used at each tested scale.
Class-specific result: The public result is a dedicated Storage Placement & Replication decision result.
Class 03 identity: Storage is measured as an independent operational class with its own benchmark section and evidence stream.
ENGINEERING EVIDENCE · 09 OCT 2026
Four gates. Validated behavior at scale.
Correctness, capacity, concurrency and live updates—measured across three graph classes.
PASSReported gate outcomes
3Graph classes
500MRouting nodes
90 / 10Read / update mix validated
Gate
Result
Validated scope
Evidence context
Gate 1
PASS
Correctness & exact-oracle checks
Frozen historical benchmark
Gate 2
PASS
Resource behavior & operating modes
Routing · AI Resource · Storage
Gate 3
PASS
Performance & concurrency
Frozen historical benchmark
Gate 4
PASS
Updates under load & state correctness
Service update-under-load · Native + HTTP
PASS results are tied to each test's workload and evidence scope. Gates 1–3 describe the historical frozen benchmarks; Gate 4 describes the service update-under-load tests. The combined table summarizes separate test campaigns, not one all-gates qualification run of a single build. Native engine and HTTP service checks are separate parts of Gate 4.
Gate 3 · Measured concurrency capacity
Closed-loop capacity points under the frozen benchmark workload. Client counts are the measured operating points, not a claim of maximum service capacity.
Class
Concurrent clients
Median p95 (ms)
Median throughput (QPS)
Result
AI Resource
6
0.4306
10,458.26
PASS
Routing
2
19.7240
264.28
PASS
Storage
6
0.4349
10,521.83
PASS
Gate 4 · Native execution under updates
Routing: 500M nodes. AI Resource and Storage: 100M nodes each. Mixes indicate reads / updates (%).
Class
Read / update
Native read p95 (ms)
Harness throughput (QPS)
Result
Routing
100/0
14.1526
322.57
PASS
Routing
95/5
13.9628
254.51
PASS
Routing
90/10
13.8807
231.75
PASS
AI Resource
100/0
6.7896
1,180.26
PASS
AI Resource
95/5
6.7345
989.25
PASS
AI Resource
90/10
6.6744
792.33
PASS
Storage
100/0
6.9440
1,231.13
PASS
Storage
95/5
6.6641
939.59
PASS
Storage
90/10
6.7219
769.24
PASS
Native read timing and native harness throughput are separate measurement fields. These results use the Gate 4 workload; compare them within this table rather than against Gate 3 or HTTP timings.
Gate 4 · Service HTTP + correctness verification
Routing was tested through HTTP on the original 500M-node graph; AI Resource and Storage used 100M-node graphs. All three classes passed the 100/0, 95/5 and 90/10 mixes, with zero reported errors and zero oracle violations.
Class
Read / update
Verified read p95 (ms)
Verified read p99 (ms)
Harness QPS
Verified visibility p95 (ms)
Result
Routing
100/0
433.35
502.52
17.79
—
PASS
Routing
95/5
430.30
510.30
13.72
347.17
PASS
Routing
90/10
434.14
504.14
12.57
307.02
PASS
AI Resource
100/0
436.59
511.78
17.86
—
PASS
AI Resource
95/5
431.61
498.72
14.52
886.79
PASS
AI Resource
90/10
422.33
493.78
11.38
818.94
PASS
Storage
100/0
438.07
518.64
17.87
—
PASS
Storage
95/5
438.39
527.33
14.34
828.27
PASS
Storage
90/10
433.40
518.30
11.34
804.94
PASS
Tests were executed by the project team on an Intel Core i5-12400F desktop with 16 GB RAM. Independent correctness verification refers to oracle checks, not third-party certification. HTTP timings include the request, response processing and independent correctness verification. Isolated API latency and verification overhead were not separately measured in this test; these figures should not be used as an API latency SLA. Visibility measures acknowledgement to a verified serving read, including witness checks where applicable; it does not isolate the underlying commit-to-first-observation delay. “—” indicates a read-only mix. Native and HTTP workloads have distinct timing scopes.
Verify QRF’s existing engineering evidence and assess its fit with your infrastructure. Engage directly with the QRF Project Lead to review documented results, measurement scope, architecture, and integration requirements.
Verify existing engineering evidence, establish technical fit, and coordinate integration. Any agreed pilot focuses on environment alignment and deployment interfaces.
1
Review Existing EvidenceArchitecture, benchmark results, and engineering-gate records
2
Verify Results & ScopeRecorded outputs, evidence integrity, and measurement boundaries
3
Assess Technical FitInfrastructure requirements and documented Core capabilities
4
Agree Integration ScopeInterfaces, topology, responsibilities, and any jointly agreed pilot
5
Coordinate IntegrationEnvironment alignment, operational coordination, and deployment
Shahram Darvishi
QRF Project Lead · Software Architect & AI Researcher
Direct technical contact for QRF architecture review, technical due diligence, strategic integration, and protected commercial discussions.
Measurement Scope & Hardware
Published benchmark figures use the current canonical evidence set: 25 Routing measurements plus 15 AI Resource and 15 Storage measurements. AI Resource and Storage use Core-post scope that excludes upstream processing and Python overhead; 200M/500M Routing uses conditioned fixed-hotset steady-state Hybrid engine-query scope. Full API/service-path KPIs, cold/unseen-pair latency, and deployment-specific SLAs are characterized separately for the target environment.
Benchmark hardware: 6-core / 12-thread general-purpose desktop with 16 GB RAM. No GPU acceleration or specialized server/HPC hardware was used.
