Human Runtime, or HRT, makes different cognitive processors discoverable, composable, and meaningfully comparable while allowing specialist providers to protect their implementations. Existing technical ecosystems show that this is possible when the shared layer is chosen carefully.
The central distinction is not simply open versus closed. It is interface versus artifact versus oracle:
- An interface defines permitted operations and result semantics. It can preserve a private implementation.
- An artifact such as a model file or locally distributed binary puts implementation material in another party's possession.
- An oracle is an interface that can be queried so freely and precisely that its behavior becomes a training dataset for a substitute.
The strongest precedents open the interface, publish conformance rules, and compare observable performance while keeping sensitive state inside a controlled runtime. The clearest failures either distributed secrets into a hostile environment or exposed an overly informative query surface.
Findings at a glance
| Example | Shared layer | What remains protected | What happened | HRT lesson |
|---|---|---|---|---|
| OpenTelemetry and Datadog | Telemetry APIs, semantic conventions, OTLP, Collector | Datadog analytics, backend, product logic, many differentiated features | Open intake works, but feature portability is incomplete | Open the measurement intake while keeping value above it; standardize evaluation more deeply than OTel |
| OpenXR and Vulkan | Public API specifications and conformance suites | Runtime and driver implementations | Many proprietary implementations compete behind one interface | Conformance can test behavior without requiring source disclosure |
| PKCS #11 and WebAuthn | Standard operations and result formats | Private keys and authenticator implementation | Multiple providers interoperate while secrets remain within tokens | Give agents handles and bounded operations, not internal state |
| A2A | Agent Cards, authenticated extended cards, tasks, extensions | Agent implementation and privileged capability details | Public and authenticated discovery can coexist | Use an HRT extension and tiered processor profiles |
| TPC database benchmarks | Common workload, metrics, audit, reporting rules | Database engine source and core algorithms | Proprietary systems are compared using reproducible evidence | Compare outcomes under declared conditions, not internal similarity |
| Prediction APIs | Query and prediction interface | Intended to protect model parameters and training data | Research extracted or approximated model behavior from queries | Precise, adaptive, bulk access needs a separate authorization tier |
| ONNX | Portable graph and tensor format | Little of the serialized model itself | Portability deliberately includes graph structure and weights | Do not use a model-artifact format as the default protected processor interface |
| Widevine L3 | Local software content-decryption interface | Intended to protect keys and implementation | Researchers bypassed software obfuscation and recovered protected material | A binary on a user-controlled host is not equivalent to a controlled service or TEE |
Where the boundary held
OpenXR and Vulkan: open behavior, private runtime
Khronos APIs provide one of the clearest precedents for HRT. OpenXR supplies a common API across proprietary XR devices and runtimes. Khronos explicitly states that the specification describes how the system should behave but not how a function must be implemented; proprietary runtime source code need not be shared. Its open conformance test suite checks consistent behavior across implementations. Khronos OpenXR standardization FAQ, OpenXR CTS guide
Vulkan uses the same pattern. The API specification and conformance tests are public. Implementations must pass the conformance process before being presented as Vulkan-conformant, while GPU vendors retain their driver implementations and optimizations. Khronos Vulkan conformance
This is almost exactly the HRT processor pattern:
- publish the callable surface and common semantics;
- publish conformance tests for valid behavior;
- allow provider extensions;
- identify conformant products and versions;
- do not require the implementation source.
The conformance suite tests contract behavior, authorization, units, provenance, and error handling. Outcome benchmarks remain separate from basic conformance.
PKCS #11: operations without possession of the secret
PKCS #11 defines a common interface to cryptographic tokens. Software can discover mechanisms, identify key objects, and request signing or decryption operations. A private key can be marked sensitive and non-extractable, so callers can use the capability without receiving the key material. OASIS PKCS #11 specification, PKCS #11 conformance profiles
The HRT equivalent is not to pretend that a cognitive model is a cryptographic key. It is to copy the architectural separation:
- the network receives a processor identifier and capability handle;
- authorized data is delivered to the processor boundary;
- the processor returns a signed result;
- internal features, weights, thresholds, and intermediate state do not need to leave;
- permitted operations are explicit and enforceable.
This pattern works best when the protected state remains in provider-controlled infrastructure or trusted hardware. It weakens when the supposedly protected material is copied into software controlled by the caller.
WebAuthn: a shared ceremony around a protected implementation
WebAuthn allows browsers and services to work with many different authenticators. The standard defines registration and authentication ceremonies, while the credential private key is expected to remain bound to the authenticator and never be exposed, even to its owner. W3C WebAuthn Level 2
For HRT, this supports the idea of a processor ceremony: a standardized sequence for discovery, authorization, input submission, result return, provenance verification, and expiry. The agent does not need possession of the processor to trust and use its signed output.
TPC benchmarks: competition without publishing the engine
The Transaction Processing Performance Council compares commercial database systems through standardized workloads, metrics, independent audits, and disclosure rules. Its benchmark specifications are intended to make results comparable and reproducible. Vendors disclose configurations and benchmark materials, but they do not publish their database engine source code. TPC benchmark overview, TPC submission and audit process
TPC also shows where HRT exercises caution. Some TPC benchmarks require extensive full-disclosure reports so a result can be recreated. That is suitable for public database performance claims, but it may ask too much of a small cognitive-analytics provider if copied literally. HRT supports several publication levels:
- private customer comparison;
- confidential independent audit;
- anonymized research result;
- provider-approved public benchmark.
The shared principle is strong: compare processors against a declared workload and outcome, under documented conditions, rather than demanding their internal algorithms.
Datadog and OpenTelemetry: a useful but incomplete model
OpenTelemetry deliberately standardizes APIs, SDK behavior, semantic conventions, OTLP, and collection. Its vendor guidance says the goal is for users to switch vendors and for default SDK implementations to work with vendors that claim support. A vendor can support OTel by accepting default SDK output through an exporter or OTLP receiver. OpenTelemetry vendor guidance
Datadog has moved meaningfully into this open layer:
- the Datadog Agent user-space components are published under Apache 2.0; Datadog Agent repository
- Datadog accepts OTLP through its Agent, Collector distribution, and direct intake; Datadog OTLP intake
- its DDOT Collector is described as open source and can be extended with other Collector components; Datadog DDOT Collector
- Agent Observability accepts OpenTelemetry GenAI and supported OpenInference conventions, mapping them into Datadog's span model. Datadog OpenTelemetry instrumentation for Agent Observability
Datadog has not made its whole product open. Its hosted storage, query, correlation, visualization, detection, evaluation, and product logic remain differentiated commercial capabilities. Its own compatibility documentation shows that the most portable OTel paths do not provide every Datadog feature, and Datadog recommends its SDK plus DDOT configuration for the broadest integration. Datadog and OpenTelemetry compatibility
That makes Datadog a strong example of the IP boundary holding, but only a partial example of full composability:
- instrumentation and intake are increasingly portable;
- the local Agent and Collector path are substantially open;
- the high-value analytical product remains proprietary;
- configurations, dashboards, evaluations, detections, and enriched product behavior are not necessarily portable;
- native Datadog paths can expose more features than the most vendor-neutral path.
This is commercially coherent, and HRT goes one step further. It standardizes processor input and output together with processor profiles, evaluation traces, outcome links, abstention, calibration evidence, and comparison conditions. This avoids reproducing the OTel pattern in which data enters many vendors through a common pipe but the evidence needed to compare their higher-level analytics remains trapped in each product.
The lesson is not that Datadog keeps too much proprietary. Its differentiation is what funds the product. The lesson is to decide explicitly which layer must remain portable for the HRT market to work.
A2A is a good carrier, not the complete protection model
The A2A specification supports public Agent Cards, authenticated extended Agent Cards, skills, security schemes, and extensions. Extended cards can expose different capability detail according to the authenticated caller, while the specification warns against placing sensitive internal information in public cards. A2A specification, A2A extensions
This maps well to HRT:
- a public card advertises that a processor supports HRT;
- an authenticated card reveals customer- or partner-specific metrics, quotas, and disclosure tiers;
- an HRT A2A extension defines processor-profile and evaluation-task payloads;
- the task returns an HRT result or a reference to one;
- high-volume sensor data travels through a more appropriate authorized telemetry or object path.
A2A does not, by itself, prevent model extraction, define cognitive semantics, or establish fair benchmarks. It is the discovery and task envelope. HRT must define the measurement and evaluation contract carried inside it.
Where the boundary failed
Prediction APIs became model-extraction oracles
The 2016 USENIX paper Stealing Machine Learning Models via Prediction APIs demonstrated attacks against models exposed through prediction services, including experiments involving BigML and Amazon Machine Learning. The researchers showed that black-box queries could recover or closely duplicate several model classes. Partial feature inputs and confidence values made some attacks particularly efficient, although simply omitting confidence did not eliminate the problem. USENIX paper page
The 2019 CVPR paper Knockoff Nets extended the concern to complex image models. It trained substitutes from image–prediction pairs and reported a useful approximation of a commercial image-analysis API at very low query cost, without access to its training data or architecture. CVPR paper
These are the closest precedents for specialist analytics providers. They show that a server-side black box protects code and weights, but not necessarily behavior. The HRT response is not a ban on comparison. It distinguishes:
- a bounded evaluation task from an unrestricted adaptive query service;
- outcome scores from a downloadable input–output corpus;
- ordinary result precision from diagnostic precision;
- private comparison from permission to train a substitute;
- trusted research access from anonymous bulk access.
Rate limits alone are not a complete answer. Query budgets, input-distribution monitoring, output quantization where scientifically acceptable, delayed or aggregated results, retention restrictions, audit logs, and provider-specific research agreements can be combined according to the disclosure tier.
ONNX demonstrates that artifact portability is disclosure
ONNX is an open and useful model format precisely because it represents the computation graph and model data. Its graph initializers carry constant tensors such as weights. ONNX IR specification, ONNX model construction documentation
This is not an ONNX security failure. It is a category lesson. If a provider exports its processor as an ordinary ONNX file, the recipient generally receives the graph and weights needed to run and inspect it. That may be appropriate for an open model, licensed on-premises deployment, or trusted development partner. It is not the default format for a protected processor.
HRT still uses portable file formats for transparent reference processors. Proprietary processors are normally represented by a profile plus a callable boundary, an encrypted package tied to a controlled execution environment, or a remotely hosted service.
Widevine L3 demonstrates the limit of software obfuscation
Research on Widevine's software-only L3 design showed that a closed and obfuscated local implementation could be reverse engineered and its root of trust recovered. Exploring Widevine for Fun and Profit
The analogy has limits: DRM keys and cognitive analytics are different assets. The architectural lesson is still important. Once a sensitive implementation and its secrets execute entirely on hardware controlled by another party, obfuscation is a delay mechanism rather than a durable security boundary.
For a specialist provider, a sealed local binary or WebAssembly module may be operationally convenient, but it is a licensed distribution model, not perfect concealment. A provider-hosted service or an attested trusted execution environment offers a stronger boundary when protection justifies the complexity.
The design pattern HRT adopts
The evidence supports a layered design.
1. Open processor interface
Standardize discovery, invocation, result envelopes, errors, provenance, authorization, expiry, and evaluation identifiers.
2. Public conformance suite
Test schema validity, units, timing, policy enforcement, version behavior, error handling, and declared capabilities. Follow the Khronos pattern: test the contract, not the implementation.
3. Outcome-based evaluation
Compare processors through independent task outcomes, reference annotations, intervention effects, calibration, latency, coverage, and robustness. Do not treat one provider's score as the truth another must imitate.
4. Graduated processor cards
Use a public profile and authenticated extended profiles. A2A can carry these cards and evaluation tasks; HRT defines their domain semantics.
5. Controlled execution boundary
Use provider-hosted processing for an initial specialist-provider integration. Add signed local modules or confidential execution only where latency, privacy, or customer constraints require them.
6. Separate comparison from extraction rights
Make private comparison an ordinary capability. Make corpus export, adaptive diagnostic querying, substitute-model training, and joint development separately authorized options rather than silently bundling them together.
7. Portable evidence
Keep benchmark definitions, evaluation traces, outcome links, and declared conditions portable. This is the layer Datadog and OpenTelemetry do not fully solve for proprietary analytics, and it may become HRT's most important contribution.
Integration pattern for a specialist provider
The first integration does not require a provider to upload a model file or hand over unrestricted raw input–output history. The provider exposes a small provider-controlled processor endpoint or supervised local service. HRT defines the processor profile and result envelope, builds the adapter, and creates an evaluation trace that can later accommodate another processor.
The first comparison can remain private. It uses synthetic or approved data, fixed evaluation tasks, declared metrics, and independent outcomes. The provider sees the complete evaluation method and results. Public identification requires separate approval.
This gives the provider evidence that interoperability does not mean implementation disclosure. It also demonstrates that HRT supports a multi-processor market rather than constructing a protected channel for one provider.
Bottom line
The line holds best when a protocol exposes capabilities, semantics, and conformance behavior while protected state remains behind a controlled boundary. It fails when portability means shipping the implementation itself or when a precise public API can be turned into an unlimited behavioral dataset.
Datadog shows that a company can support an open ingestion standard while retaining valuable proprietary analytics. Khronos shows how multiple proprietary runtimes can share an API and public conformance suite. PKCS #11 and WebAuthn show how callers can use a protected capability without possessing its secret state. A2A shows how public and authenticated capability descriptions can coexist. Prediction-API extraction and Widevine L3 show why query design and execution location still matter.
For HRT, the target remains:
Open the processor slot. Standardize the evidence. Protect the implementation. Permit comparison by design. Grant deeper learning deliberately.
Practical companion: HRT Processor IP Exposure and Extractability Self-Test