Patra Model Cards for Edge AI

• Patra Model Cards are dynamic, provenance-rich documentation tools that evolve with the AI model lifecycle in edge deployments.
• They integrate continuous runtime data using a lightweight Neo4j graph structure, enabling provenance queries and machine-actionable insights.
• The system supports dynamic model selection and lifetime accountability by aligning operational behavior with declared intent within the ICICLE ecosystem.

Patra Model Cards are a reconceptualization of AI/ML model cards for edge AI cyberinfrastructure, introduced in "AI/ML Model Cards in Edge AI Cyberinfrastructure: towards Agentic AI" (Plale et al., 26 Nov 2025). They are designed for scientific workflows spanning the edge–cloud–HPC continuum and depart from conventional model-card practice by treating the card not as a one-time, training-time disclosure artifact, but as a dynamic, machine-actionable, provenance-rich object that evolves with deployment and use. In this formulation, the central question is no longer only how a model performed when it was created, but how it is actually used over its lifetime: where it runs, under what conditions, by whom, on which devices, with what latency and resource behavior, and whether current use remains consistent with prior use and declared intent (Plale et al., 26 Nov 2025).

1. Conceptual basis and departure from static model cards

Patra Model Cards are framed against the model-card tradition associated with Mitchell et al., in which a model card documents model details, intended use, evaluation procedures, and performance characteristics of a trained model (Mitchell et al., 2018). The Patra paper accepts that such documentation remains useful, but argues that ordinary model cards are fundamentally limited because they typically capture a one-time, benchmarked description produced during training rather than an operational history accumulated across deployment (Plale et al., 26 Nov 2025).

This shift is motivated by edge AI. In edge environments, deployment conditions are variable, devices are resource-constrained, and the operationally best model can change with workload bursts, latency constraints, hardware differences, or environmental changes. The paper’s wildlife-monitoring example with camera traps illustrates the point: a model optimized for accuracy may cease to be the best operational choice during bursts of activity or on different hardware, while a latency-optimized model may become preferable. Static deployment strategies and static model cards do not represent that variation, whereas Patra is intended to support lifetime-aware benchmarking and accountability by continuously reassessing fit for purpose (Plale et al., 26 Nov 2025).

Patra therefore retains familiar documentation elements—metadata, fairness analysis, explainability analysis, links to artifacts, and intended usage—but embeds them in a system that continuously ingests runtime information. The resulting card is meant to answer not only “what was this model?” but also “what has happened to it in practice?” and “is its current use consistent with prior use and declared intent?” (Plale et al., 26 Nov 2025)

2. Lifecycle model and graph representation

Patra is organized around an explicit AI/ML model lifecycle. The paper defines four states:

Lifecycle state	Description	Key relation
Model Program Object	Model in training form, often a Python object in a code repository	$1:M$ to Model Serialized Object
Model Serialized Object	Serialized form for sharing or packaging in filesystems or object stores	Feeds Model Image
Model Image	Packaged deployment artifact such as a containerized inference server	$1:M$ to Inference Execution Instance
Inference Execution Instance	Running, time-bounded deployment of a model image	Most dynamic state

The architectural significance of this lifecycle is that Patra does not stop at the model artifact. The most dynamic state is the Inference Execution Instance, because it has temporal and spatial properties and records actual usage behavior, including where and when the model executed, how it was used, and with what observed performance. This is the point at which the idea of a dynamic model card becomes concrete (Plale et al., 26 Nov 2025).

The persistent data model is implemented in a Neo4j graph database. The paper identifies four core entities—Model Card, Model, Edge Server, and Deployment—and specifies a $1:1$ relation between Model Card and Model, plus a $1:m$ relation between Model and Deployment. Deployment corresponds to the runtime execution concept in the lifecycle model. Patra deliberately keeps the graph schema lightweight, representing “larger conceptual objects” as nodes and storing much of the detail in node properties, with additional semantics supplied by endpoint logic. The authors describe this as both a convenience and a limitation, because it simplifies some retrievals while moving schema interpretation into the application layer (Plale et al., 26 Nov 2025).

This graph structure enables provenance-style traversals, lineage queries, and full-text search. It also supports similarity and versioning relations such as alternateOf and revisionOf, which are intended to guide model selection among variants. A plausible implication is that Patra’s graph is less a static catalog than a continuously updated operational knowledge base for models and deployments.

3. Integration in the ICICLE ecosystem

Patra is embedded in the ICICLE AI Institute software ecosystem as a persistent service for model accountability, provenance, and discovery. It participates across development, deployment, runtime monitoring, and post hoc analysis rather than functioning as a passive registry (Plale et al., 26 Nov 2025).

Creation begins at model onboarding. During training, a researcher working in a Jupyter notebook uses the Patra ModelCard toolkit to provide core information about the model. The toolkit can auto-populate some metadata, including fairness and explainability scanner outputs, validate the card, and emit a structured JSON representation. The model artifact itself—for example a PyTorch .pt file—is stored externally in a repository such as Hugging Face or GitHub, and the Patra card is updated with the artifact location before the model becomes available in the catalog (Plale et al., 26 Nov 2025).

After onboarding, Patra continues to update the card through runtime data capture. The paper states that model behavior is continuously captured via the CKN streaming system: each edge server runs a CKN daemon that emits events through Kafka, including prediction outcomes, accuracy, latency, CPU/GPU usage, and related operational metrics. Patra subscribes to these streams and merges incoming data into its graph representation. Each runtime inference becomes a node representing an execution instance linked to the corresponding model card, so deployment history incrementally extends the card over time (Plale et al., 26 Nov 2025).

The operational pipeline is grounded in ICICLE tooling. A researcher uses MLFieldPlanner to configure an experiment; a Tapis job launches MLProvisioner; hardware such as OpenStack resources or edge devices is provisioned; and MLEdgeServer runs plugins for ingest, scoring, storage, monitoring, and inference. Plugin communication uses ZMQ topic streaming. A Resource Monitoring plugin captures CPU, memory, and energy usage, while the inference path emits model output data. The system propagates the original model_id supplied at launch so that Patra can link runtime observations back to the correct model card (Plale et al., 26 Nov 2025).

The paper also treats ownership and accountability as part of the model-card concept. Through Tapis authentication and authorization, Patra ties model cards to actual users and organizational affiliation. “By whom” refers to ownership and affiliation; “how” refers to operational deployment patterns and, in future work, perhaps the encompassing experiment or task graph. The authors suggest that such information could help detect model use outside the tolerance of its historical pattern (Plale et al., 26 Nov 2025).

4. Query, signposting, and machine-actionable use

Patra functions both as a design aid before deployment and as an evidence store during and after deployment. Before deployment, users or orchestration components can query Patra for models satisfying constraints such as latency thresholds, deployment history, fairness or explainability metadata, or hardware compatibility. During and after deployment, the system records how the model was actually used and links those observations into the card. This makes the card useful both to human operators and to automated orchestration (Plale et al., 26 Nov 2025).

The service layer exposes search, retrieval, signposting, and mutation operations. Neo4j full-text indexing supports a /search endpoint for prompts such as “camera-trap classification,” while direct querying on performance attributes supports machine-actionable model selection, for example choosing the model with the highest accuracy under a latency constraint. Because the card is treated as machine-actionable rather than purely descriptive, Patra can drive automated model selection (Plale et al., 26 Nov 2025).

A distinct architectural feature is FAIR Signposting. Patra assigns each model card a unique identifier composed of author, model name, and version. A HEAD request to /modelcard/<ID> returns HTTP Link headers pointing to semantic metadata, and a GET request to /modelcard/{id/linkset} returns the full linkset JSON. Through these linksets, clients can discover the model card, container image, datasheets, and related artifacts. The paper describes Patra as acting as a signposting broker over its knowledge graph (Plale et al., 26 Nov 2025).

This combination of queryability, provenance, and signposting means that Patra is intended not merely to archive model facts, but to support search, orchestration, accountability, and, eventually, anomaly detection or policy-triggering based on observed lifetime usage (Plale et al., 26 Nov 2025).

5. MCP, REST, and the move toward agentic interaction

A major part of the Patra paper evaluates the Model Context Protocol as an interface to the Patra Model Card server. MCP is described as a recently released, session-based JSON-RPC 2.0 protocol, often carried over Server-Sent Events, with abstractions for resources, tools, and prompts. The paper’s interest in MCP is not raw speed; it is the fit between session-oriented interaction and dynamic model cards (Plale et al., 26 Nov 2025).

The implementation, built with FastMCP, focuses on two operations. The first is Model Card Retrieval, implemented as an MCP resource with URI pattern modelcard://{mc_id}. Retrieval uses one base query for the main ModelCard node plus four separate queries for AI Model, Bias Analysis, Explainability Analysis, and Deployments, then aggregates the results into JSON. The second is Edge Creation, implemented as an MCP tool because it mutates the graph. It accepts two Neo4j elementId values and executes a four-stage pipeline: verify node existence and labels; normalize labels and validate the relationship against a schema dictionary; check for duplicates; and, if valid, commit the relationship in one Neo4j transaction (Plale et al., 26 Nov 2025).

The evaluation compares three interfaces: direct REST, Native MCP that talks to Neo4j via Bolt, and Layered MCP that wraps the existing REST API. For few-kilobyte model cards, the paper reports a raw database lower bound of $5.87$ ms and an observed total query time of $5.8 \pm 0.7$ ms. End-to-end retrieval times are $7.5$ ms for REST and $26.7$ ms for Native MCP; Layered MCP is about $4.1\times$ REST and $16\%$ slower than Native MCP. The explanation is protocol overhead from JSON-RPC framing, tool dispatch, SSE session management, and, in the layered case, double serialization (Plale et al., 26 Nov 2025).

The picture changes for large dynamic cards. In the paper’s pseudo-synthetic experiment, the graph contains 10,000 Deployment nodes, 1000 Experiment nodes, and 100 Device nodes, producing an average model-card JSON size of 13.63 MB. Raw retrieval time for the Model Card node rises to 7843.83 ms, and the authors conclude that for large payloads, non-trivial graph traversals, and wide-area transfers, MCP overhead becomes comparatively less important. For small mutation-style actions such as Edge Create, however, MCP is reported as $1:M$0 slower than REST in the wide-area setting (Plale et al., 26 Nov 2025).

The deeper argument is qualitative. REST is stateless; MCP maintains persistent sessions and supports ongoing notifications. The paper suggests that if Patra becomes an external memory and observation source for an AI agent, session persistence and change notifications are more natural in MCP than in pure REST. This is the basis for the subtitle’s “towards Agentic AI.” The paper likens the interaction style to a ReAct loop, while also noting that such loops can become repetitive and may require human feedback to avoid poor convergence (Plale et al., 26 Nov 2025).

6. Position in the model-card literature and unresolved issues

Patra belongs to a broader movement away from static, model-only disclosure toward richer operational documentation. The original model-card framework centered on intended use, performance, evaluation procedures, and caveats for trained models (Mitchell et al., 2018). DAG Cards later argued that, in many production settings, the correct documentation unit is the full ML workflow rather than the standalone model, with distinct flow-level and run-level information (Tagliabue et al., 2021). A plausible implication is that Patra and DAG Cards address different extensions of the same problem: Patra makes the model card runtime-aware and lifetime-aware, whereas DAG Cards make documentation pipeline-aware (Tagliabue et al., 2021).

Other adjacent work extends model cards along different axes. Automatic generation systems seek to improve completeness and consistency by extracting card content from papers and repositories (Liu et al., 2024). Verifiable ML property cards use trusted execution environments to make some technical claims in cards machine-verifiable rather than merely declarative (Duddu et al., 2024). Sustainability Model Cards add formal, machine-processable reporting for energy, carbon, water, and platform context (Jouneaux et al., 25 Jul 2025). CRAI-MCF reorganizes model-card content into a weighted hierarchy of atomic parameters for cross-model comparison and sufficiency scoring (Yang et al., 8 Oct 2025). This suggests that Patra’s distinctive contribution is not generic standardization, but the treatment of the card as a living operational object inside an edge deployment infrastructure.

The Patra paper also identifies unresolved design questions. One is scale: if models are frequently deployed, cards may become very large, even reaching the GB range. Another is semantics: although Neo4j stores the graph, Patra relies heavily on node properties and endpoint logic to define what a model card actually is. The authors identify this as a major design decision needing further study, especially for AI interactions with the repository. A further limitation is formalism: the paper provides lifecycle multiplicities such as $1:M$1 and $1:M$2, a URI notation, and timing values such as $1:M$3 ms, but does not provide mathematical scoring formulas, optimization objectives, or formal pseudocode for lifetime assessment (Plale et al., 26 Nov 2025).

In that form, Patra Model Cards are best understood as an infrastructure component for responsible, accountable, and reproducible AI in dynamic edge environments. Their novelty lies less in the existence of a card than in the claim that the card should accumulate operational history, support machine-actionable queries, and remain open to session-based interaction patterns suited to orchestration and, potentially, agentic AI (Plale et al., 26 Nov 2025).