IPRR is the problem. IAPI is an architectural response. DECA is an implementation architecture.

1Progression: From Architecture to Problem Class

IAPI was introduced as an architectural inversion: instead of requiring a person to translate a resource need into a physical search strategy, infrastructure can participate in resolving what resource satisfies the intent, where that resource is, and how the physical environment should respond [1][2]. IAPI-03 then isolated the addressability problem, distinguishing logical identity from mutable location and formalizing represented state, eligibility, endpoint adequacy, abstention, and realized failure [3]. IAPI-04 placed the architecture within the broader Physical AI landscape [4]. IAPI-05 expanded the client model from humans to software agents and robots and made the architectural boundary explicit: intent on one side, physical execution on the other, and resource resolution between them [5].

That progression reveals that the resolution operation is not identical to IAPI. A nurse can resolve a request through memory and search. A robot can resolve it through perception and a world model. An enterprise application can resolve it through inventory state. A digital twin can expose a represented endpoint. Infrastructure can resolve it as a service. These systems differ architecturally, yet each must answer the same underlying question.

Given an objective and relevant context, what physical resource can satisfy it, and where is the actionable endpoint against which physical action should occur?

IAPI-06 therefore does not introduce a new step into the earlier architecture. It extracts and generalizes a step that the earlier papers progressively exposed. IPRR is the problem abstraction. IAPI is one architectural strategy for solving it. This separation is consistent with broader intent-based computing, which distinguishes declarative goals from realization mechanisms [6], and with Physical AI work that increasingly links perception, reasoning, modeling, and embodied interaction [14].

2Scope and Formal Definition

Established resource and address model

To avoid notation drift, this paper adopts the core symbols introduced in IAPI-03 [3]. Let R be the set of individually represented physical resource instances, K the space of semantic resource classes, A the physical address space, T the time domain, and M the supported response modes. Let G*_t(r) denote the modeled ground-truth address of instance r at time t, and Ĝ_t(r) the system representation, where Ĝ_t(r) = ⊥ means that the system cannot currently assert a sufficiently reliable address. Let A*_R,t(r) denote true physical availability of instance r. For inventory-bearing endpoints, N*_t(a, k) and N̂_t(a, k) denote true and represented counts of class k at endpoint a. As in IAPI-03, V(a) denotes the physical region represented by address a, ζ(a, m) is its response-relevant spatial descriptor, and Z*_req(r, m) or Z*_req(k, m) is the true adequacy region for the intended response mode. Event-centered standards such as GS1 EPCIS provide a related precedent for representing objects, locations, and changing physical state [13].

The semantic and policy constraints of a request are represented through the eligibility sets already used in IAPI-03: R_elig(i, c) for eligible resource instances and A_elig(i, c) for eligible inventory-bearing endpoints under intent i and bounded context c. Physical availability remains separate from semantic eligibility. Address correctness and response-relevant spatial adequacy also remain separate: a coarse address can be correct by containment yet still be inadequate for the intended action [3].

Request and acceptable-solution set

For a single-target request, define q = (i, c, t, m, τ), where i is the expressed intent, c is relevant bounded context and policy, t is the decision time, m is the anticipated response or execution mode, and τ ≥ 0 is the required validity horizon for downstream use. The interval [t, t+τ] is the period over which the consumer expects the resolution to remain actionable; τ = 0 recovers decision-time correctness. IPRR does not require that every element be supplied explicitly, but these variables identify information on which a correct resolution may depend.

Define Ω(q) as the set of physical fulfillment targets that are acceptable for request q under physical ground truth over the requested validity horizon. A member of Ω(q) can be an instance-address pair or a class-bearing inventory endpoint, depending on the resource pathway. Membership for the single-target model requires semantic and policy eligibility, continuing physical availability or positive inventory throughout the requested horizon, address correctness by containment, and response-relevant spatial adequacy for the intended downstream action. In the base formulation, eligibility and endpoint adequacy are evaluated at resolution time t and assumed stable over the horizon unless an implementation explicitly models them as time-varying. Physical availability, inventory, and address containment are evaluated throughout [t, t+τ].

The IPRR solver and correctness relation

An IPRR solver is a resolution procedure, modeled as a partial function, that attempts to select an admissible member of the acceptable-solution set using available representations of intent, context, resource state, and location. By accepting τ as part of the request, a successful return also constitutes a time-bounded resolution claim: the selected target is intended to remain actionable for the requested horizon.

Ψ(q) → y, where y ∈ (R × A) ∪ (K × A) ∪ {⊥}. If y ≠ ⊥, the attempted resolution is correct iff y ∈ Ω(q). ⊥ is abstention or an unresolved state; it is not a physical target.

IPRR correctness is defined against the acceptable set, not against one uniquely correct resource

This matters because many physical requests legitimately admit multiple solutions. Three stocked bins may contain equivalent supplies. Several compatible parts may satisfy a maintenance objective. Multiple tools may satisfy a capability requirement. IPRR is therefore not necessarily a single-answer lookup problem; it is a constrained physical fulfillment problem. Selection policy can rank acceptable members of Ω(q), but correctness requires membership in the acceptable set.

Abstention must be evaluated separately from correctness. Returning ⊥ when an acceptable solution exists reduces coverage but can remain safer than returning a confidently wrong endpoint. This preserves the coverage-versus-success distinction and reject-option logic already formalized in IAPI-03 [3]. The validity horizon adds a second discipline: a target that is correct at t but becomes invalid before t+τ does not satisfy Ω(q) for that request. For scarce, consumable, or exclusive resources, horizon validity may also depend on contention. A target that is correct at t can become invalid before execution if another actor claims, consumes, reallocates, or relocates it. The formalism therefore exposes contention as a resolution-validity problem even when coordination mechanisms are implemented elsewhere in the system.

A problem class needs more than a pipeline. It needs an input boundary, an output boundary, a failure output, and a relation that says which attempted outputs are correct.

3What IPRR Includes, and Where It Stops

IPRR begins when an objective is expressed above the level of a physical address and ends when the system has produced an admissible physical fulfillment target with an actionable endpoint. It does not require physical actuation. It does not prescribe who executes the action. It does not require a robot, voice interface, cloud service, digital twin, or instrumented environment.

4IPRR and IAPI: Problem Versus Architecture

The distinction can be made directly against the architecture formalized in IAPI-02. There, resource resolution and physical address resolution precede a separate response function that closes the loop in the environment [2]. IPRR corresponds to the resolution problem up to an accepted physical endpoint. IAPI goes further: it constrains where important parts of that resolution live and requires closed-loop physical response for conformance.

Using the IAPI-02 notation directly, F: (I, C) → R* performs semantic and contextual resource resolution, G: (R*, S) → A maps the selected resource to a current physical address, and H: (A, M) → P converts that address into a physical response [2]. IPRR spans the problem expressed by F and G, while H is downstream physical closure. IAPI couples all three and imposes infrastructure-level conformance requirements around them.

IPRR: Intent → Resource / Fulfillment Resolution → Actionable Physical Endpoint. IAPI: Intent → Resource / Fulfillment Resolution → Actionable Physical Endpoint → Physical Response.

IPRR ends at a resolved endpoint. IAPI adds architectural placement and closed-loop response

This mapping preserves the meaning of IAPI rather than redefining it. IPRR is broader because the resolution can be performed by an actor, robot, application, infrastructure service, or distributed combination. IAPI is narrower and more specific: it makes intent-addressable behavior a property of physical infrastructure and, under the IAPI-02 conformance model, closes the loop through guidance or actuation.

IPRR is architecture-neutral. IAPI is architecture-committed.

5Relationship to Adjacent Problem Classes

A useful problem class should clarify neighboring work rather than erase it. IPRR overlaps several established research traditions. Its proposed contribution is the end-to-end, client-independent combination of semantic intent, physical eligibility and state, and actionable resource addressability. The closest antecedents illuminate individual parts of that chain.

• Intentional naming and resource discovery. The Intentional Naming System (INS) let applications specify what they were looking for rather than where to find it, resolving descriptive names against dynamic network services [7]. IPRR extends the resolution target from network endpoints into stateful physical resources whose availability, location, spatial adequacy, and actionability change independently of their logical identity.
• Perceptual anchoring. Anchoring creates and maintains correspondence between symbols and sensor data referring to the same physical objects, including finding, tracking, and reacquiring them over time [8]. It can be a mechanism within robot-localized IPRR, but IPRR additionally asks whether that object is an admissible fulfillment target for the current intent and exposes an endpoint that a different downstream actor may consume.
• Object-goal navigation and open-vocabulary mobile manipulation. ObjectNav navigates to an instance of a requested object category in an unexplored environment, and open-vocabulary mobile manipulation combines language, perception, navigation, and manipulation to retrieve or place objects [9][10]. Both perform robot-localized resolution inside a larger embodied task. IPRR abstracts that step away from any one robot.
• Task and motion planning. TAMP integrates high-level discrete tasks with the continuous motion needed for navigation and manipulation [11]. IPRR sits earlier and narrower: it determines the admissible target and endpoint; TAMP determines how a robot achieves the goal. A robot may solve both internally, but they need not be architecturally co-located.
• Multi-robot task allocation. MRTA formalizes how tasks are assigned among robots and relates assignment structures to established optimization problems [12]. The primary IPRR question is different: which physical resource should satisfy the objective? Assigning the executing actor is a neighboring decision that may consume the result of IPRR or join a distributed joint optimization.

6Resolution Placement as a Stage Assignment

Saying that resolution "lives" in the actor, application, robot, or infrastructure is useful but incomplete. IPRR is itself composed of stages, and different stages can be placed in different loci. A placement architecture can therefore be described as an assignment of resolution stages to computational actors, with explicit interfaces between them.

A distributed architecture might interpret a high-level objective in an agent, maintain shared inventory and location state in infrastructure, validate final local geometry on a robot, and preserve physical execution inside the robot controller. Another system might perform every stage in a human operator. IPRR gives both systems a common function to compare.

7Evaluation: How IPRR Solvers Should Be Compared

Once the problem is separated from the architecture, evaluation can become architecture-neutral. Human search, a robot world model, a warehouse application, an IAPI environment, and a distributed hybrid can be compared against the same request distribution and physical ground truth. At minimum, an evaluation should report:

• Resolution correctness conditional on attempt. How often an attempted output belongs to the acceptable-solution set Ω(q).
• Coverage and abstention. What fraction of legitimate requests are resolved, clarified, refused, or returned as ⊥.
• Horizon validity. Whether the selected resource and endpoint remain semantically admissible, physically available, correctly contained by the returned address, and spatially adequate throughout the requested interval [t, t+τ].
• Resolution latency. Time from accepted intent to actionable endpoint, separated from downstream physical execution time.
• Severity-aware loss. Incorrect resolutions should be weighted by consequence rather than treated as equally harmful.
• Robustness to environmental change. Relocation, depletion, reassignment, occlusion, stale mappings, connectivity loss, and policy changes.
• Systems cost. Sensing, instrumentation, compute, network dependence, model maintenance, human search burden, and duplicated perception across actors.

IAPI-03 already provides a detailed realized-event and risk-accounting framework for addressability and closed-loop attempts [3]. IPRR can reuse the same evaluation logic while stopping before the final physical-response event. In that sense, the problem abstraction does not discard the earlier formalism; it gives that formalism a broader comparison domain.

The key comparison is no longer "Is this IAPI?" It is "How well does this system solve IPRR, and where does it place the work?"

8Single-Target and Multi-Resource Objectives

The base definition in this paper treats a single fulfillment target as the primitive. This covers requests such as "I need a 20-gauge IV catheter," "bring the torque wrench," or "locate the replacement pump." Many real objectives, however, imply bundles: "prepare for arterial-line insertion," "reset this room," or "stage the parts for the next maintenance operation."

A multi-resource objective cannot always be reduced to independent single-resource lookups. Joint constraints may matter: compatibility among components, co-location, sequence, substitute sets, expiration, kit completeness, shared scarcity, or dependency between choices. Formally, the acceptable solution becomes a set or structured bundle of resource-endpoint assignments satisfying joint constraints rather than a single member of Ω(q). This paper therefore treats bundle resolution as a compositional extension of the single-target IPRR primitive and leaves a full formal treatment of constrained multi-resource resolution to subsequent work. Making that scope explicit is preferable to silently treating a bundle request as if it were a single lookup.

9Why Shared Environments Change the Economics of Resolution

The placement question becomes especially important when many actors repeatedly operate inside the same bounded environment. If every clinician, technician, robot, or autonomous agent must independently reconstruct the same resource identities, locations, stock state, permissions, and spatial relationships, the environment incurs duplicated search and perception costs. A shared resource-resolution layer can amortize portions of that work across clients.

This does not imply that infrastructure should replace local perception or actor judgment. Shared state can be wrong; infrastructure can fail; a robot may require final grasp-time verification; a human may override an inappropriate recommendation. The architectural opportunity is division of labor. Stable or shareable facts can be maintained once and exposed as a service, while client-specific perception and execution remain local where they provide the most value.

The strongest case for infrastructure-localized IPRR should therefore appear where resource populations are bounded, multiple clients repeatedly encounter the same environment, physical state can be maintained with sufficient confidence, and the cost of duplicated actor-level search or reconstruction is high. Open and uninstrumented environments may favor actor-localized resolution. Many real deployments will be hybrid.

10Research Agenda

11Conclusion

The earlier IAPI papers began with a practical observation: physical search remains a human burden in environments where digital systems increasingly understand intent and physical resources can increasingly be sensed, represented, and actuated. Formalizing IAPI revealed a sequence from intent to resource, from resource to physical address, and from address to response. Formalizing physical addressability then exposed the importance of eligibility, state validity, uncertainty, abstention, and realized physical correctness. Extending the architecture to software agents and robots made the central boundary unavoidable.

The resolution problem is more general than the architecture that first exposed it.

Intent-to-Physical-Resource Resolution names that problem. Given an objective and relevant context, a solver must determine an admissible physical fulfillment target and actionable endpoint, or explicitly decline resolution when it cannot do so with sufficient reliability. The computation can reside in a human, application, robot, infrastructure layer, or distributed system. Those choices are architectural. IPRR is the common problem they solve.

This separation creates a neutral foundation for comparing architectures and a clearer hierarchy for subsequent work: the problem can be studied independently of the architecture; the architecture can be evaluated independently of a specific implementation; and implementations can be judged against a common resolution objective.

IPRR = problem class → IAPI = architectural framework → DECA = implementation architecture → products and deployments = embodiments

Before the physical world can become programmable, it must first become resolvable.

12Series Progression

About this paper. IAPI-06 is part of the Intelligent Clinical Systems IAPI research series. Its purpose is to isolate Intent-to-Physical-Resource Resolution as a problem abstraction that can be analyzed independently of any specific implementation or commercial product. The formulation is intended to support critique, comparison, refinement, and future empirical evaluation.