Competition and Composability Between Processors While Protecting Their Implementations

Human Runtime, or HRT, makes different human-performance processors easy to discover, connect, evaluate, and combine. A system can use one specialist provider for a class of cognitive analytics, another provider for a different sensor modality, and a reference processor for transparent baseline metrics. Those processors participate in the same human–agent network without publishing their source code, models, thresholds, training data, or internal feature engineering.

The design goal is straightforward:

HRT creates competition and composability between processors while protecting their implementations.

These aims reinforce one another. A provider is more likely to join a multi-provider ecosystem when the interface gives it control over its implementation and data. An integrator is more likely to adopt the ecosystem when providers can be tested against real requirements and changed without rebuilding the whole application.

An open processor slot, not an open processor

HRT does not need every processor to use the same algorithm. It needs each processor to describe its capability through a common contract.

A processor profile can declare:

• which HRT metrics and states it produces;
• which devices, signals, and task profiles it supports;
• its input-quality requirements;
• its output units, ranges, uncertainty representation, and abstention behavior;
• the populations and conditions for which it has evidence;
• its deployment options, latency, availability, and resource requirements;
• its version and provenance;
• its authorization, comparison, retention, and disclosure policies.

The profile describes how another participant can use the capability responsibly. It does not reveal how the capability was built.

This is the same distinction found in many technical systems. A payment network can call a fraud service without receiving the fraud model. An application can call a language model without receiving its weights. HRT lets an agent request an authorized cognitive estimate without turning the provider's implementation into part of the protocol.

What becomes interoperable

An HRT processor interface makes five things portable.

Discovery

An agent or application can identify processors that support a required metric, device, environment, latency target, or evidence level.

Invocation

An authorized task can be sent to a processor without writing a new integration for every provider.

Interpretation

The result arrives with enough shared semantics, provenance, timing, quality, and validity information for another system to use it correctly.

Evaluation

Processor outputs can be connected to independent outcomes, reference annotations, interventions, and later performance.

Composition

An orchestrator can select, combine, sequence, or compare processors according to the needs of a particular runtime episode.

The interface becomes common. The science, implementation, commercial service, and provider-specific extensions can remain differentiated.

Comparison is part of interoperability

If processors can be plugged into the same role, integrators must be able to compare them. HRT supports that comparison explicitly rather than leaving it to informal claims or incompatible demonstrations.

Useful comparisons include:

• conformance — whether the processor accepts and emits valid HRT records;
• operational performance — latency, availability, cost, coverage, and resource use;
• calibration — whether declared risk or quality bands correspond to observed frequencies;
• outcome performance — whether estimates predict or improve a separately measured result;
• robustness — how performance changes across devices, people, environments, missing signals, and distribution shifts;
• system performance — what happens to the complete human–agent workflow when the processor informs routing, timing, intervention, or supervision.

Comparison does not require one processor to reproduce another processor's score. Two providers may use similar terms while measuring different constructs or calibrating them differently. The stronger test relates each output to an independent outcome or declared evaluation target.

A common HRT evaluation trace can connect:

authorized runtime episode
    → processor A output
    → processor B output
    → processor C output
    → independent outcome or expert evaluation

The processors can run in shadow mode, so none of their outputs changes the live task. The trace preserves the device, task, population, timing, data-quality, and authorization conditions. The result is a fair, contextual comparison without disclosure of internal code or models.

HRT avoids presenting one universal processor leaderboard. A processor that performs well in aviation training with a particular eye tracker may not be the best choice for industrial work, real-time agent supervision, or another population. Evidence remains attached to its operating conditions.

Composition creates more value than replacement

A multi-processor architecture is not only about choosing a winner. Different processors can contribute different capabilities.

An orchestration agent might:

• select a specialist provider when an application needs one of its validated measurements;
• choose another processor for a modality that provider does not support;
• use a transparent reference calculation as a baseline;
• run two processors for a high-risk episode;
• treat disagreement as a signal that more evidence or human review is needed;
• route work according to latency, confidence, device availability, jurisdiction, or cost;
• combine provider outputs only when their semantics and validation permit it.

This turns processor diversity into system resilience and expands the range of applications the ecosystem can support. Providers do not have to build every sensor integration, analytical layer, workflow, or vertical product themselves.

The role of A2A, telemetry, and HRT

No single transport protocol needs to carry the whole architecture.

A2A or another agent-facing mechanism can support processor discovery, capability advertisement, authorization negotiation, task exchange, and result delivery. OpenTelemetry or another telemetry path can carry high-volume operational observations and correlated traces. Encrypted object references or local streams handle data that cannot travel through ordinary agent messages.

HRT supplies the meaning shared across those paths:

• cognitive metric and state schemas;
• processor capability profiles;
• human, task, span, event, and trace relationships;
• provenance and method-version identifiers;
• validity and uncertainty representations;
• consent, purpose, retention, and disclosure policies;
• evaluation and outcome records.

The transport moves a request or result. HRT makes the result interpretable and comparable.

A controlled processor boundary

The most practical protection is to keep raw signals and proprietary processing inside a provider-controlled boundary. That boundary can be implemented in several ways.

Provider-hosted service

Raw or prepared input is sent through an authorized interface. The provider returns signed HRT outputs. This gives the provider direct control over processing, versions, access, and monitoring.

Sealed local processor

A signed module, container, or application runs close to the device and emits only approved results. This can improve latency and data locality. Software packaging and obfuscation raise the cost of inspection, although they are not absolute security boundaries.

Attested confidential processor

For deployments that justify the complexity, a trusted execution environment can isolate the processor and prove which approved software handled the data. Inputs are available only within the protected runtime, and only permitted outputs leave it.

Provider-hosted sandbox or clean room

Approved partners can validate a processor, run research, or compare outputs without exporting the underlying dataset or the entire input–output history.

Encryption remains important for data in transit and at rest. It protects inputs, outputs, keys, and stored traces from unintended access. It does not by itself prevent an authorized recipient from inspecting information after decryption, so it must be combined with access scope, data minimization, query controls, and auditability.

Evidence from other ecosystems supports this boundary. OpenXR and Vulkan use public interfaces and conformance suites around proprietary runtimes. PKCS #11 and WebAuthn expose bounded operations while protected keys remain inside their providers. OpenTelemetry gives Datadog an open ingestion path while Datadog retains its commercial analytics. Conversely, prediction-API research shows that large collections of precise, adaptive queries can train useful substitutes, and ONNX shows that distributing a portable model artifact generally distributes its graph and weights as well. The detailed cases are examined in When Open Interfaces Protect IP—and When They Expose It.

Selective legibility instead of total secrecy

Protecting implementation does not mean preventing partners from learning how a processor works. Some relationships become more valuable when a provider shares methods, explanations, features, or research access.

HRT can support graduated disclosure:

1. Result access — a signed state, category, or recommendation.
2. Metric access — bounded values, quality bands, and provenance.
3. Validation access — approved evaluation inside a controlled environment.
4. Research access — selected signals, features, methods, or explanations.
5. Development access — agreed access to parts of the processing pipeline for joint work.

The provider chooses which tier applies to each relationship. An output can carry machine-readable terms describing its permitted purpose, recipient, precision, retention, onward sharing, comparison, and use for learning.

This is selective legibility: enough visibility to use, test, trust, and sometimes extend a capability, without assuming that every participant receives every layer.

Fair comparison needs governance

HRT protects providers from misleading comparisons as carefully as it protects integrators from unsupported claims.

A credible evaluation declares:

• the metric or outcome being tested;
• the dataset or runtime population;
• device and signal-quality conditions;
• processor and profile versions;
• missing-data and abstention handling;
• evaluation horizon and scoring method;
• who ran or sponsored the evaluation;
• whether results are private, permissioned, anonymized, or public;
• limitations and conflicts of interest.

Private evaluation is possible without automatic publication. Public claims require reproducible evidence and clear permission to identify participating providers. Conformance, scientific validity, commercial endorsement, and performance ranking remain separate claims.

This creates useful competition: providers compete on capability, evidence, reliability, integration quality, applications, and support. They do not have to compete by creating incompatible interfaces or locking customers into proprietary data structures.

Why this strengthens a specialist provider's position

A specialist analytics provider can participate as an HRT processor and measurement steward. It helps define what a responsible processor profile says, which uncertainty and validity fields matter, and how cognitive analytics are evaluated without flattening different constructs into one score.

The provider gains a reusable route into agent systems and new verticals. Integrators discover where its processor fits, test it against a real requirement, and connect its results to their workflows. The provider proves that the capability works without disclosing its algorithm.

Comparison does introduce competition. It also converts scientific and operational quality into visible evidence. A capable provider benefits when markets can distinguish a supported measurement from a convenient but weak imitation.

The leadership opportunity is not to prevent other processors from entering. It is to help establish the interface and evaluation practices through which serious processors can demonstrate their value.

The larger HRT proposition

An open HRT ecosystem does not make every provider interchangeable. It makes each provider's differences usable.

Devices can supply observations. Processors can derive specialized states. Vertical profiles can define task meaning. Evaluation traces can connect estimates to outcomes. Agents can discover, select, and coordinate those capabilities. Providers can retain their implementations and decide how deeply each partner may inspect or extend them.

That is the balance HRT offers:

Common interfaces without common ownership. Meaningful comparison without forced disclosure. Composition without commoditization. Competition on demonstrated value rather than integration lock-in.

Short version

HRT lets different cognitive processors plug into the same human–agent architecture. They are discoverable, testable, comparable against real outcomes, and differentiated by their evidence and capabilities. A2A or another agent transport connects them. HRT defines their shared profiles, metrics, policies, and evaluation traces. Each provider keeps its implementation inside a controlled processor boundary, exposes results by default, and opens deeper layers to selected partners. This creates competition and composability between processors while protecting their implementations.

Technical companion: Human Runtime Cognitive Metrics

Evidence companion: When Open Interfaces Protect IP—and When They Expose It

Owner test: HRT Processor IP Exposure and Extractability Self-Test