Give the AI models their own specification, and let a Server use them - #49
Merged
Conversation
Vision's frame vocabulary was World, Base, Tool, Camera, Object, Other. It had no value for the mechanical interface, so its own eye-in-hand picking example labelled the flange `Tool` and the frame tree contained no tool centre point at all. That is not a naming quibble. The hand-eye calibration in Annex F resolves camera to flange, and a pick has to reach the TCP. With one `Tool` role the example could not carry the offset between them: adding a second frame for the real TCP would have made `Tool` ambiguous inside one tree. Vision 5.8 describes this exact failure - "the pose is correct and the robot moves to the wrong place, because the two ends disagreed about what the numbers were relative to" - and the annex reproduced it. `MechanicalInterface` is added and the literals are renumbered to match Robot Intent, which had it right. Renumbering is free today and permanent after publication: enum values live in EnumStrings, so no NodeId moves - the CSV diff is 0 changed, 0 removed, 0 added for both models. The example descriptor gains a `GripperTcpFrame` so the picking example carries the flange-to-TCP offset explicitly rather than leaving a consumer to assume it, and says why the two frames are distinct. Annex F, both addenda and the overlays regenerate from it. Vision 5.12 gains the three pose rules it was missing beside Robot Intent's: right-handedness, quaternion normalisation, and the statement that this model defines no default frame. The last one matters most - the same empty `FrameId` means "not actionable" here and "default work frame" there, so a transcoder written by someone who read one specification would have produced a pose in the wrong frame. Ten bare "5.10" references cited DataTypes when the rules they name - corner datum, distortion ordering, frame precedence, the covariance sentinel - are all in 5.12. They passed CI because check_section_refs.py requires a literal section sign to see a reference at all. Both specifications now carry a mutual interop annex, which neither did: they never referenced each other despite being deployed on the same robot. Vision Annex I and Robot Intent Annex E fix which frame tree decides, how FrameId values correspond, that roles map by name and never by integer, how poses transcode across the covariance field, and that a grasp pose resolving only to the mechanical interface is refused. Annexes only - no NodeIds, no NodeSet dependency, and both models keep base OPC UA as their only RequiredModel. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
Vision had grown a model nameplate, a dataset, a deployment and a learning job - 30 members and ten types - none of which mention a camera. A process soft sensor needs all of it and none of a lens, so leaving it there would have obliged every other domain either to declare a vision model as a RequiredModel or to define the whole thing again, at which point the provenance question stops having one answer. metaverse-specs/ai-deployment/ is domain-neutral by construction: its validator fails the build if a type name acquires a domain term, and the check is CamelCase word-boundary matched so Framework is not a false hit. DeploymentStateEnum replaces the VisionEndpointStateEnum the deployment had borrowed - same five literals, no dependency. The join is a facet precondition, not a RequiredModel. InferencePipelineType.Deployment was already a plain NodeId, so Vision's namespace index does not shift and a Server that publishes cameras and verdicts without ever naming a model is still conformant to VIS-Base. VIS-Inference-* and VIS-Learning require AI-Base, and say so. No Vision NodeId moves. The vacated blocks - 6107..6136, 6177..6190, 6193, 6195 - are reserved rather than reclaimed, because reusing them would renumber all 45 members declared after them. The CSV diff is 61 removed, 0 added, 0 moved. Both validators now cross-check specification against model in both directions. That found 16 real gaps in Vision: enum literals and structure fields the model declared and the prose had truncated with "and so on". Mutation-tested in both directions on both models. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
Clause 9.5 carried StartCollection, StopCollection, TriggerTraining and PromoteModel with their StatusCodes, and 9.6 carried the state model - all of which LearningJobType owns and OPC UA - AI Deployment and Learning now states. Two documents stating one transition table is two places for it to be wrong, and the wrong one is found by an implementer rather than by a validator. 9.5.1 keeps only the vision-specific half: the join between a correction submitted through VisionFeedbackType and the job that consumes it. The distinct PromoteModel authorization is deliberately stated in both documents, because it is the one rule where a reader of either alone would reach the wrong conclusion. The both-directions cross-check then found a real defect the old prose had hidden. Clause 9.2 was titled "The three purposes" and described three; VisionFeedbackPurposeEnum declares four. Trigger had never been documented - it only appeared to be, because a "| From | Trigger | To |" table header in the deleted state model satisfied the word match. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
8 tasks
The model said what a model IS and never let anyone use one. EndpointUri was a bare String: no wire contract, no credential, no capabilities, no failure semantics. A Server holding one knew where to send bytes and nothing about what shape they should take or what to do when the far end stopped answering - so "consume a model hosted elsewhere", which is the whole point of the InferenceLocation property, was unimplementable from what this model told it. Three additions. Clause 7 defines one invocation surface whose signature does NOT change with InferenceLocation. That is not an aspiration: serving runtimes that run on a workstation and the hosted services they mirror already expose the same contract, differing only in addressing and auth. The payload stays opaque - it is domain vocabulary - and what gets fixed is the envelope, where ModelUsed reports the model that ACTUALLY answered. A fallback or a followed reference moves it between the call and the read, so the deployment's current model is the wrong answer to "what produced this result", and wrong in the direction that looks plausible. Clause 8 makes remote consumption real: dialect, auth kind, a credential REFERENCE that is never a secret, capabilities, reachability, and the question no inference API answers because it can assume its caller will wait - what the line does when the WAN drops. FallbackPolicy is Mandatory. So is DataJurisdiction and EgressPermitted, because encryption answers who can read data in flight and not where it went. Clause 9 makes the catalogue an xRegistry domain extension rather than a private invention. Two things then fall out of the base type instead of being designed: ResourceType IS a FileType, so a staged artefact streams through the inherited Open/Read/Close; and it already carries ExternalReference, so a federated entry whose bytes live elsewhere is expressible without pretending to hold them. The import job federates by default and stages when the target could not otherwise reach the source, and verifies the digest at staging - the one moment a substituted artefact would enter. Jobs now derive from the Part 10 ProgramStateMachineType through a shared AiJobType, as Robot Intent does, so the transition events and auditability are inherited rather than reinvented. Costs, stated plainly rather than buried: this model now requires OPC UA - xRegistry, which spends the "exactly one RequiredModel" claim and moves the own namespace from ns=1 to ns=2. Both validators hardcoded ns=1 while reading it - Vision's would have resolved nothing and passed. Both now derive the index from NamespaceUris. No NodeId moved. JobId and LastError moved up to AiJobType and their ids are reserved, not reclaimed: 0 removed in place, 141 added, 0 moved. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
The invariants that make clauses 7 to 10 executable rather than aspirational, each mutation-tested: - The four Mandatory members clause 8 rests on. A rule resting on an Optional member is a rule a conformant Server can silently not satisfy. - Invoke returns ModelUsed, Usage and FinishReason. - Nothing in the address space is NAMED like credential material. That is how the clause 8.2 prohibition gets violated by accident, and the address space is browsable, subscribable and historisable, so a secret placed here is not merely readable - it is archived. - The catalogue types narrow their inherited placeholders. A domain extension that leaves them open adds metadata while restricting nothing. - AiJobType still derives from the Part 10 base. - NamespaceUris order, because it fixes every namespace index in the file. All seven mutations caught; artifacts restored byte-exactly. Annex C works one arrangement end to end: a federated cloud model and a staged edge model, the WAN dropping, and the fallback answering. The point of it is the sentence a table cannot make - the client called the same Method with the same arguments throughout and never learned that inference had moved, except by reading ModelUsed, which is exactly what an audit a month later needs and what a client logging the deployment would have got wrong. ApiDialectEnum.OpenAiCompatible became RestChatCompletions. The literal named a company. A standard's enumeration should describe the contract, not advertise whoever published it first - and the prose says what it is compatible with without needing the name. No vendor is named anywhere in the document. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
Owner
Author
|
Stacked below #50. That PR builds directly on the specification this one creates, so this should land first. Worth knowing while reviewing this PR: #50 spends the "exactly one That turned out to matter for something in this PR: Vision's validator reads the AI NodeSet with a hardcoded |
Adding three clauses left the existing ones describing a smaller model than the one that now exists, and put 5.6 between 5.1 and 5.2 - the out-of-document-order defect this repository has been bitten by before and which no check catches. 5.6 moved to where it belongs. Every heading is now in order. 5.2 documents what a model carries beyond its artefact: the publisher that completes the identity triple, and Quantization, which is not a packaging detail - a quantized model is a different artefact that gives different answers, and treating it as a variant is how a model evaluated at full precision ends up deployed at reduced precision with nobody re-measuring it. 5.3 says why Mixed is not a hedge, and that a dataset whose class list disagrees in ORDER with its model is undetectable: every identifier resolves, every count is plausible, every label is off by one. 5.4 gains a table of everything that makes a deployment callable, and the reason State and Reachability are separate. Ready + Unreachable is a network fault; Faulted + Reachable points at credentials. Collapsing them loses exactly what a commissioning engineer needs. 6 gains the joins to the consuming half - a trained candidate is not privileged over an imported model and owes the same lineage - and says plainly that almost no Server implements the whole loop, which is why State is read rather than inferred from which Methods exist. 11 grew because the attack surface did. The chain has more links; two break while a Server looks correct. The resolver policy now governs seven URIs, and applying it to a staging import AFTER transfer is not a control. Credential material is unaddressable, argued from the fact that the address space is subscribable and historisable - a secret there is not exposed once, it is published and archived. FollowsRef is promotion's second door and needs the same authorization, or the audit trail shows every promotion having been authorized. And a fallback may not be more permissive on egress than what falls back to it, or a network fault quietly sends plant data where policy forbids. 11.4 now says what DigestVerified actually means: the artefact is the one this catalogue entry described. An attacker who can edit both artefact and entry defeats it, and the catalogue is the better target because many machines read it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
Critical: the prose described a root object the model does not have. VisionRootType lost Models and LearningJobs when the AI cluster moved, but 4.2 still listed them normatively, 5.3 still said "five folders", and the 5.2 figure still drew them. A Server following 4.2 literally would instantiate two folders no ModellingRule permits, and a client following 5.3 to decide "is this Server doing AI" would browse for a folder that can never exist. The figure now shows the AI cluster where it actually lives - under AiRootType, beside the Vision object, not inside it. Both worked examples had the same fault and a worse consequence: they parked AI instances in those folders and never instantiated AiRootType at all, so the only executable demonstration of the new seam could not satisfy the AI-Base facet that VIS-Inference-* and VIS-Learning now require. They now build a proper AI root under the Server object. The learning loop lost content in the move that landed nowhere: the StatusCode table, the idempotency of StartCollection/StopCollection, TriggerTraining returning Accepted=false with Good, and the all-or-none rule for a null Deployment. Worse, two transitions vanished - Promoted had NO outgoing edge, so the loop could run exactly once, contradicting the AI spec's own "the cycle repeats" two clauses earlier. Restored, with the transition table it needs to be testable. Both ReferenceType arrows in the AI overview figure were drawn backwards against their own definitions. UsesModel is Deployment->Model and TrainedOn is Model->Dataset; the figure said the opposite, so an implementer following it would emit references that fail the exactly-one rule. Vision's equivalent figure had them right, so the two documents disagreed. Vision still owned a rule it had handed over: 5.11 restated the exactly-one UsesModel constraint verbatim, over a ReferenceType it no longer defines - visible in the mangled "An DeploymentType", which is what a mechanical rename leaves behind. Also fixed: a stale AiModelType in a descriptor that a generated annex was publishing, an AiDeployment reference shipping inside the NodeSet itself, an ObjectType count that said 25 against an actual 21, and a scope sentence still claiming Vision covers AI. 9.5.1 rule 1 required something no member could express - there was no modelled path from a pipeline to a learning job, and the folder that used to anchor one had just been removed. InferencePipelineType.LearningJob makes it executable. Writing it beside its type renumbered InferencePipelineType.Stop, so it is allocated at the true end of the id space instead; 0 moved. The encoding id counter was unguarded, so the 5009 freed by the moved structure would have been silently reclaimed by the next structure added - the same append-only violation the member ids were carefully protected from. Two validator blind spots, both proved by the reviewers and both now mutation-tested: the AI validator rejected any struct field documented as Type.Field, and the reverse cross-check silently SKIPPED a backticked owner that no model declares - so a reference to a retired type passed. That check now lives in Vision's validator, which is the only one with both models loaded and therefore the only one able to tell an outside type from a nonexistent one. Types from companion specifications are allowlisted explicitly, so taking a new outside dependency is a deliberate edit. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
Critical: the namespace migration moved NodeIds and forgot BrowseNames. A BrowseName is namespace-qualified, and its index is independent of the NodeId's. T()/OWN_NS was threaded through every NodeId, but the BrowseName prefix stayed hardcoded "1:" - which after the xRegistry RequiredModel means index 1 is xRegistry. So all 201 own nodes browsed as xRegistry:ModelType while their NodeIds said ns=2: browse paths resolve against the wrong model, and the names collide with a namespace in which none of them are defined. Schema Registry, which this generator names as its precedent and has the identical layout, uses 2: throughout. Nothing in the validator noticed, so it now checks BrowseName indices directly - mutation-confirmed to catch the exact regression. Annex A had the same half-migration and is declared authoritative for identifiers, so the two normative sources disagreed: one row printed ns=1;i=1005 and ns=2;i=1006 for the same model. A dead ns=1 branch in _dt_name also meant DataType columns rendered raw ids instead of names. The xRegistry narrowing did not narrow. ModelRegistryType declared a NEW <ModelPublisher> placeholder rather than overriding the inherited <Group>, and an InstanceDeclaration is overridden only by one with the SAME BrowseName - so the inherited placeholder stayed fully open beside it and a conformant registry could still organize any GroupType at all. The reference type had silently become HasComponent too. Now overridden properly, by name and with Organizes. That forced a real modelling decision rather than a rename: a publisher holds both models and datasets, but <Resource> can be overridden only once. AiResourceType is an abstract base of both, so the single override admits exactly the two. The validator's check was BrowseName-blind, which is why it passed a narrowing that narrowed nothing; it now checks the name, the type and the reference, and all three mutations are caught. Also: a dangling 5.10 introduced by this PR, invisible because a bare section reference resolves against any document the file cites. Merged from vision-restructure, keeping the expanded overview figure with the corrected arrow directions, and restoring the StatusCode table and transition table that the merge dropped. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
The both-directions cross-check only compared type NAMES, so a whole Method and three Mandatory members shipped undocumented: a Server is obliged to implement them and a client has nothing to read. ListModels, ModelSourceType.SourceId, and EvaluationRunType's RunId, EvaluatedModel and Metrics. The forward direction now checks member granularity for Methods and Mandatory members, and stops there: demanding prose for every Optional member would produce padding rather than documentation. All five are now documented, including why ListModels takes a filter - a public catalogue holds more models than any client wants to page through, so a Method that could only return everything would be unusable against exactly the sources clause 8 exists to reach. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
Owner
Author
Review response — Critical + 4 High fixedCritical — the prose described a root object the model does not have. Both worked examples had the same fault with a worse consequence. They parked AI instances in those non-existent folders and never instantiated The learning loop lost content that landed nowhere. The StatusCode table, the idempotency of Both ReferenceType arrows in the AI overview figure were backwards against their own definitions. Vision still owned a rule it had handed over. §5.11 restated the exactly-one Also: a stale §9.5.1 rule 1 was not executable — it required something no member could express, and the folder that used to anchor one had just been removed. The encoding id counter was unguarded, so the Two validator blind spots, both proved by the reviewerThe AI validator rejected any struct field documented as Both directions mutation-tested, including negative controls that must not fire. 9/9 checks green; determinism byte-identical. |
* Let a Server actually use a model, not just describe one The model said what a model IS and never let anyone use one. EndpointUri was a bare String: no wire contract, no credential, no capabilities, no failure semantics. A Server holding one knew where to send bytes and nothing about what shape they should take or what to do when the far end stopped answering - so "consume a model hosted elsewhere", which is the whole point of the InferenceLocation property, was unimplementable from what this model told it. Three additions. Clause 7 defines one invocation surface whose signature does NOT change with InferenceLocation. That is not an aspiration: serving runtimes that run on a workstation and the hosted services they mirror already expose the same contract, differing only in addressing and auth. The payload stays opaque - it is domain vocabulary - and what gets fixed is the envelope, where ModelUsed reports the model that ACTUALLY answered. A fallback or a followed reference moves it between the call and the read, so the deployment's current model is the wrong answer to "what produced this result", and wrong in the direction that looks plausible. Clause 8 makes remote consumption real: dialect, auth kind, a credential REFERENCE that is never a secret, capabilities, reachability, and the question no inference API answers because it can assume its caller will wait - what the line does when the WAN drops. FallbackPolicy is Mandatory. So is DataJurisdiction and EgressPermitted, because encryption answers who can read data in flight and not where it went. Clause 9 makes the catalogue an xRegistry domain extension rather than a private invention. Two things then fall out of the base type instead of being designed: ResourceType IS a FileType, so a staged artefact streams through the inherited Open/Read/Close; and it already carries ExternalReference, so a federated entry whose bytes live elsewhere is expressible without pretending to hold them. The import job federates by default and stages when the target could not otherwise reach the source, and verifies the digest at staging - the one moment a substituted artefact would enter. Jobs now derive from the Part 10 ProgramStateMachineType through a shared AiJobType, as Robot Intent does, so the transition events and auditability are inherited rather than reinvented. Costs, stated plainly rather than buried: this model now requires OPC UA - xRegistry, which spends the "exactly one RequiredModel" claim and moves the own namespace from ns=1 to ns=2. Both validators hardcoded ns=1 while reading it - Vision's would have resolved nothing and passed. Both now derive the index from NamespaceUris. No NodeId moved. JobId and LastError moved up to AiJobType and their ids are reserved, not reclaimed: 0 removed in place, 141 added, 0 moved. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Enforce the new rules, and show what they add up to The invariants that make clauses 7 to 10 executable rather than aspirational, each mutation-tested: - The four Mandatory members clause 8 rests on. A rule resting on an Optional member is a rule a conformant Server can silently not satisfy. - Invoke returns ModelUsed, Usage and FinishReason. - Nothing in the address space is NAMED like credential material. That is how the clause 8.2 prohibition gets violated by accident, and the address space is browsable, subscribable and historisable, so a secret placed here is not merely readable - it is archived. - The catalogue types narrow their inherited placeholders. A domain extension that leaves them open adds metadata while restricting nothing. - AiJobType still derives from the Part 10 base. - NamespaceUris order, because it fixes every namespace index in the file. All seven mutations caught; artifacts restored byte-exactly. Annex C works one arrangement end to end: a federated cloud model and a staged edge model, the WAN dropping, and the fallback answering. The point of it is the sentence a table cannot make - the client called the same Method with the same arguments throughout and never learned that inference had moved, except by reading ModelUsed, which is exactly what an audit a month later needs and what a client logging the deployment would have got wrong. ApiDialectEnum.OpenAiCompatible became RestChatCompletions. The literal named a company. A standard's enumeration should describe the contract, not advertise whoever published it first - and the prose says what it is compatible with without needing the name. No vendor is named anywhere in the document. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Deepen the clauses that were already there Adding three clauses left the existing ones describing a smaller model than the one that now exists, and put 5.6 between 5.1 and 5.2 - the out-of-document-order defect this repository has been bitten by before and which no check catches. 5.6 moved to where it belongs. Every heading is now in order. 5.2 documents what a model carries beyond its artefact: the publisher that completes the identity triple, and Quantization, which is not a packaging detail - a quantized model is a different artefact that gives different answers, and treating it as a variant is how a model evaluated at full precision ends up deployed at reduced precision with nobody re-measuring it. 5.3 says why Mixed is not a hedge, and that a dataset whose class list disagrees in ORDER with its model is undetectable: every identifier resolves, every count is plausible, every label is off by one. 5.4 gains a table of everything that makes a deployment callable, and the reason State and Reachability are separate. Ready + Unreachable is a network fault; Faulted + Reachable points at credentials. Collapsing them loses exactly what a commissioning engineer needs. 6 gains the joins to the consuming half - a trained candidate is not privileged over an imported model and owes the same lineage - and says plainly that almost no Server implements the whole loop, which is why State is read rather than inferred from which Methods exist. 11 grew because the attack surface did. The chain has more links; two break while a Server looks correct. The resolver policy now governs seven URIs, and applying it to a staging import AFTER transfer is not a control. Credential material is unaddressable, argued from the fact that the address space is subscribable and historisable - a secret there is not exposed once, it is published and archived. FollowsRef is promotion's second door and needs the same authorization, or the audit trail shows every promotion having been authorized. And a fallback may not be more permissive on egress than what falls back to it, or a network fault quietly sends plant data where policy forbids. 11.4 now says what DigestVerified actually means: the artefact is the one this catalogue entry described. An attacker who can edit both artefact and entry defeats it, and the catalogue is the better target because many machines read it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Require a Mandatory member to be documented, not just its type The both-directions cross-check only compared type NAMES, so a whole Method and three Mandatory members shipped undocumented: a Server is obliged to implement them and a client has nothing to read. ListModels, ModelSourceType.SourceId, and EvaluationRunType's RunId, EvaluatedModel and Metrics. The forward direction now checks member granularity for Methods and Mandatory members, and stops there: demanding prose for every Optional member would produce padding rather than documentation. All five are now documented, including why ListModels takes a filter - a public catalogue holds more models than any client wants to page through, so a Method that could only return everything would be unusable against exactly the sources clause 8 exists to reach. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
Five changes, none of which alter what the model can do. The NodeId space had gaps at 6036, 6042 and 6104..6106 - residue of two members that moved to a base type and three placeholders that narrowed nothing - and the generator explained them with comments like "6036 held JobId, now inherited". A reader implementing this today should not be able to tell any of that happened. The model is unpublished, so the ids are now contiguous: 6001..6145, 145 members, none lost. The diff against the previous commit is a deliberate full renumber rather than the usual 0-moved. 1.2 "Why this is a separate specification" is gone. Its third paragraph duplicated 4.2 outright, its second defended the document existing, and only the first said anything about the model - which is now in 1.1 where the motivation lives. 1.3 also carried two bullets that both said training is out of scope. 11.1.1 was titled "The chain has more links than it used to", which is a changelog sentence in a heading. It says what the chain is. Five flows had no diagram: a call and what comes back, async submit and subscribe, the far end failing and a fallback answering, federate vs stage with the digest gate, and the provenance walk. Every arrow direction was checked against the generator's ReferenceType definitions rather than against intuition, because the last review found both arrows in the overview figure drawn backwards against their own. Annex D deploys an ONNX gearbox classifier end to end. Clause 7 had acquired some vocabulary from generative models - a capability called chat, accounting that is often tokens - while what industry runs is a fixed-shape tensor model executed in-process. The annex shows the same envelope carries it with nothing bent: tensor signatures as the entire interface description, a staging import with the digest verified, usage metered in samples rather than tokens, and Capabilities naming no chat capability at all - an absence that means nothing, because the list is open so a deployment describes what it does instead of scoring itself against a menu. It also says why no tensor wire format is standardised: raw buffers, protobuf, Arrow and npy are each right somewhere, and a Server already speaking one to its runtime should not transcode into a format chosen here. ContentType names which is in use, which is what a client needs. Plus a table of contents, 69 entries, all resolving. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
#50 was squash-merged into this branch at 12:02, which flattened everything ai-expansion held at that moment. Two commits pushed after that point were left behind: - the member-granularity cross-check, and the Method and three Mandatory members it found undocumented - the polish pass: contiguous NodeIds, 1.2 dropped, the delta voice removed from 11.1.1, five flow diagrams, the ONNX annex and the table of contents The squash and the branch describe the same model by different histories, so every AI-spec file conflicted; ai-expansion is strictly ahead on all of them and its version is taken, then regenerated from the generator rather than trusted as merged text. Verified after the merge: member ids contiguous 6001..6145, all three tree validators green, 772 internal links resolve, 0 unresolved clause references. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
Owner
Author
The AI specification work now lives here#50 was squash-merged into this branch while I was still pushing to it, which flattened everything
Every AI-spec file conflicted — the squash and the branch describe the same model by different histories — so Polish pass⚠ The NodeIds were renumbered deliberatelyThe member id space carried gaps at A reader implementing this today should not be able to tell any of that happened. The model is unpublished, so the ids are now contiguous — This is a deliberate departure from the append-only rule the stack has otherwise held to throughout. No released artefact is affected and no member was added or removed, but it is called out rather than left to be found. §1.2 "Why this is a separate specification" is goneIts third paragraph duplicated §4.2 outright. Its second defended the document existing, which a standalone specification does not need to do. Only the first said anything about the model, and that is now in §1.1. While reading it I found §1.3 carrying two bullets that both said training is out of scope. Merged. §11.1.1 was titled "The chain has more links than it used to"A changelog sentence in a heading. It now says what the chain is. Five flows gained diagramsA call and what comes back (§7.2), async submit and subscribe (§7.6), the far end failing and a fallback answering (§8.4), federate-vs-stage with the digest gate (§9.3/9.4), and the provenance walk (§11.1). Every arrow direction was checked against the generator's ReferenceType definitions rather than intuition — the earlier review of this PR found both arrows in the overview figure drawn backwards against their own definitions, which is easy to do and hard to spot. Annex D — an ONNX model, end to endClause 7 had picked up vocabulary from generative models — a capability called
It also states why no tensor wire format is standardised: raw buffers, protobuf, Arrow and npy are each right somewhere, and a Server already speaking one to its runtime should not transcode into a format chosen here. AlsoA table of contents, 69 entries, all resolving. Document ~13,000 words. 9/9 checks green, including Mermaid — the only gate for the new diagrams, since |
"AI Deployment and Learning" named two of thirteen clauses. The document also covers what a model is, calling it, calling one hosted elsewhere, the catalogue and bridge, and governance and provenance. Management carries the catalogue, import, lifecycle and governance; Inference carries the call, which is the largest clause and the first thing an implementer reaches for. The type system was already name-neutral, so almost nothing in the model changes. The namespace stays http://opcfoundation.org/UA/AI/ - it was never named for the old title, and changing it would invalidate every RequiredModel pin and every overlay reference for nothing. AiRootType, AiJobType, AiResourceType and the AI-* facets are all prefixed Ai, not AiDeployment, so they stand. Exactly one identifier carried the old title: the well-known browse entry point. AiDeployment becomes AiModelManagement, which is a BrowseName change - NodeId 7001 does not move. The CSV diff is 0 moved, with that one symbolic name replaced and nothing else touched. Folders moved with git mv so history follows the document rather than showing a delete and an add. The riskiest part was not the rename but what reaches into this tree by path: both Vision generators, the Vision validator, validate_all.py, the tree README and sixteen references in the Vision specification. A missed path there would not have failed loudly - the Vision validator returns empty sets when the AI NodeSet is absent and then passes - so AI_TYPE_ID was checked to be populated rather than inferring it from a green run. It resolves 42 types and 208 ids. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
marcschier
commented
Aug 3, 2026
Owner
Author
Retitled: OPC UA — AI Model Management and Inference"AI Deployment and Learning" named two of the document's thirteen clauses. Management carries the catalogue, import, lifecycle and governance; Inference carries the call, which is the largest clause and the first thing an implementer reaches for. The model barely changedThe type system was already name-neutral, so the rename is almost entirely cosmetic where it counts:
Exactly one identifier carried the old title: the well-known browse entry point. Paths
Moved with The part that was actually riskyNot the rename — what reaches into this tree by path: both Vision generators, the Vision validator, A missed path there would not have failed loudly. Vision's validator returns empty sets when the AI NodeSet is absent and then reports success — the same silent-pass shape the earlier review caught. So rather than inferring correctness from a green run, I asserted it directly: Left alone deliberatelyThree surviving matches for "AI Deployment" are correct: IDTA 02059 really is called the AI Deployment submodel template (twice, once in generated output), and a comment in Vision's generator names Vision's own retired 9/9 checks green; determinism byte-identical; the three critical guards re-confirmed by mutation after the move. |
Headings stated conclusions instead of naming topics, so a reader scanning the contents met forty arguments rather than a structure. Forty-three are now topic names - "Provenance", "Lineage", "Version binding", "Data residency and egress" - and every statement a heading was carrying has been restored as the opening sentence of the clause it belonged to, so nothing was lost in demoting them. The information model sections read as clipped one-liners. 5.2, 5.3 and 5.4 now open by saying what the type is for, who reads it and when, and the member descriptions say what each is needed for rather than only what it holds. The 5.4.1 table literally prefixed a "The question" column before each answer; it is prose now. 5.4.2 compared State with Reachability, which clause 8 does not introduce until much later - the reader met a comparison against something undefined. It now describes State on its own terms, including why Degraded sits between Active and Faulted, and defers the combination to 8.4 where the other half exists. "The bridge" was doing two jobs. A Server reaches an external AI system either by calling one per request (clause 8) or by obtaining a model from a catalogue once (clause 9), and both get called bridging. 9.2 now separates them before defining the import job, and the clause is titled "The catalogue and model import". "A card that lists only what a model can do is marketing" was polemic for a specification; it now says the same thing about behaviour and commissioning without the jab. The decision record explaining why this was a separate specification was already removed in an earlier commit; the section is gone rather than rewritten, since a standalone document does not argue for its own existence. Contents regenerated for the renamed headings: 69 entries, all resolving. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
marcschier
changed the title
marcschier
commented
Aug 3, 2026
marcschier
commented
Aug 4, 2026
Invoke carried its payload as a ByteString, which is bounded three times over - by MaxByteStringLength, by the negotiated MaxMessageSize and by the Session's MaxResponseMessageSize - none of which this model gets to choose. An image, a point cloud or a window of high-rate samples exceeds them routinely, so the one call the specification defined could not carry the input it was defined for. Invoke is now the shortcut and BeginTransfer is the general path. InferenceTransferType carries one chunked exchange whose Request and Response are Part 5 FileType objects, so a client opens, writes or reads in chunks of its own choosing, and closes. Nothing here invents a transfer protocol: OPC UA already has one, every client implements it, and a bespoke chunking scheme would be a second thing to get wrong. MaxInlinePayloadSize is Mandatory and says the bound before a client calls rather than after a rejection, because the three limits above are not all visible from the client side and the smallest of them is the real one. Clients that do not know their payload sizes in advance are told to start with the transfer path. The awkward case is not a large request - a client knows its own input - but a request that fits producing a response that does not. Invoke returns TransferRequired and Transfer for that, and a Server shall NOT fail the call: the inference already ran, and failing would discard the work and tell the caller nothing, leaving it to read an empty payload and conclude the model returned nothing. Streaming stays where it was. A transfer delivers one complete response however large; 8.5 covers output a client wants as it forms, over a Subscription or optionally a data channel. Clause 4 Scenarios is new, and informative: eight arrangements this specification supports, each with the flow that realises it, so a reader can find the one resembling their installation before reading the normative clauses that define its parts. They are not alternatives - a plant running a model locally, calling a hosted one for a second opinion and importing both from a catalogue is doing three at once. Clauses 5 to 14 shift by one to make room. Every clause reference was re-checked by hand rather than trusting the section-ref gate, which resolves a bare reference against any cited document and would not have caught a stale one. 0 NodeIds moved; 22 added.
8 tasks
…#54) * Add vendor implementation guides for the AI Model Management specification The specification names ApiDialectEnum literals for what a contract does rather than for whoever published it first, because a literal in a standard should not be an advertisement. That is right for the normative document and leaves an implementer holding a question it does not answer: they are not integrating a REST chat-completions contract, they are integrating Azure AI Foundry, or Bedrock, or the Triton server already in the plant. Eleven informative guides under extras, one per system, each with the same nine sections so the index's coverage table means something. The ninth - what this system does not tell you - is the one worth reading first; a mapping document that lists only what maps is marketing. Two findings the set makes hard to avoid noticing. No hosted inference platform in it exposes an artefact digest. Not Foundry, OpenAI, Bedrock, SageMaker, NIM, Triton or Vertex. Identity everywhere is a name string. Hugging Face is the only content-addressed system here and it serves no inference. So Digest stays empty against a hosted endpoint, a Pinned deployment is pinned to a NAME with the provider's policy rather than a hash holding it still, and the Stage import mode is the only path in the set that ends with a digest the Server computed itself. AuthenticationKindEnum cannot express AWS SigV4. The guides map it by what is STORED, which is what makes the member answerable across systems whose handshakes have nothing in common: an IAM role is WorkloadIdentity because no secret exists anywhere, static access keys are ApiKey. Whether the enumeration should gain a literal is a separate decision - it would be a NodeSet change - and is not taken here. validate_examples.py re-derives from the NodeSet and the specification, never from the guides, and is wired into validate_all.py because a validator outside the aggregate silently stops running. It checks that cited members exist, that every dialect and authentication literal is exercised, that conformance units are real, that each guide links the specification by relative path - which is also what makes a bare section reference resolve, metaverse-specs being a strict tree - and that the index agrees with the guides. It earned its place twice while being written: it found that no guide covered OpcUaInference, which is why there is now one for federating to another Server implementing this specification, and it caught a member this author had cited as ImportMode when the model calls it Mode. Mutation-tested against all five checks. No model file is touched: no NodeSet, no NodeIds CSV, no generator, so no version bump. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Correct the vendor guides against an audit of all eleven Nine of the guides were written by sub-agents and only spot-checked. A three-way audit against the sanctioned research and the specification found errors in every category the audit looked for, including in the two documents the lead wrote. Conformance claims that were simply wrong: AI-OffServer requires EndpointUri to name an authenticated, confidential scheme. The NIM, Triton and KServe guides all claimed it while showing a plain http:// listener as the default - which is the ordinary way a self-hosted inference server sits on a plant network, so this was wrong in exactly the case a reader would be in. AI-Import requires AI-Catalogue; an import job with nothing to import from is not implementable. SageMaker and Triton claimed AI-Import from S3 URIs and a model repository respectively, neither of which is a catalogue that declares a digest to verify against. The federation guide claimed every conformance unit an upstream Server implements is reachable through the link. A conformance unit describes what THIS Server exposes; reaching a Server with a catalogue does not give this Server AI-Catalogue, mirroring it does. Rewritten as three lists by what the downstream Server actually has to build. Model errors: ApiDialect is Mandatory, and the Hugging Face guide left it empty on the grounds that a catalogue speaks no inference contract. True, and not available: it is Proprietary with EndpointDescriptionUri doing the work, and the guide now says the cleaner arrangement is to model the Hub as a ModelRegistryType under clause 10 rather than bending a ModelSourceType around it. AI-Invoke requires ModelUsed populated on every response, so the federation guide's suggestion that a downstream Server may return null when it cannot resolve the upstream model was not one of the options. It publishes a ModelType for the substitute or it fails the call. RateLimit.RetryAfter is a Duration; Retry-After carries seconds or an HTTP date. Converted, not copied. Citations: ModelUsed is 8.2.1 and not 8.5, which is Incremental results; the payload bound and the transfer path are 8.2.4 and not the whole of 8.2. The index attributed the digest rules to clause 11 when 12.1 states them, and asserted a shall-not the specification does not contain - what 12.1 actually requires is that a Server populate Digest where the artefact is obtainable through ArtifactUri, which for a hosted model it is not. Unsupported vendor facts, removed rather than softened: ONNX file metadata fields, GGUF header contents, Triton's storage backends and repository-management extension, and Retry-After attributed to specific platforms rather than to HTTP. Triton's dialect split was a transport split. Clause 9.2 names the literals for the contract, and Triton serves OIP over both HTTP and gRPC, so both are OpenInferenceProtocol. TensorRemoteProcedure stays, described as what it is for. The index also called Hugging Face the only exception to no artefact digest, omitting embedded runtimes - the one arrangement in the set where the digest is something the Server computed rather than was told. Comparative praise replaced with description throughout. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Restore the blank line before a heading in the federation guide Lost while rewriting the catalogue section for the conformance-unit audit. MD022, and the only markdownlint finding across the set. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Releases 0.3.0 and 0.4.0: what eleven real systems taught the AI specification (#55) * Integrate what the vendor mappings taught the AI specification Mapping one information model onto eleven real systems was a natural experiment, and it found places where the model was unsatisfiable, unguarded or ambiguous. None of them needs a NodeSet change. AI-Invoke was unsatisfiable for every non-language model. The facet required Usage "populated on every response" while no clause imposed that obligation, and "empty" was unencodable: the three counts are UInt64 and the model declares no optional fields, so leaving them empty encodes as zero, indistinguishable from a metered zero. Five guides claimed the facet while documenting empty Usage. 8.2.3 now makes an empty UnitKind the not-metered sentinel, with the counts set to zero and clients forbidden from reading them as measurements. The unit carries the sentinel because the counts cannot. Residency did not compose across a federation hop. A payload leaves a deployment along exactly two modelled edges, FallsBackTo and Source, and only the first was guarded; EgressPermitted's only shall binds on InferenceLocation Cloud, so a cell-to-site EdgeOffServer hop escaped it. 9.5 states the members are end-to-end rather than next-hop, and obliges a Server federating to a peer to read its declarations and never publish anything more permissive, defaulting fail-safe where it cannot read them. This is the rule 12.3.2 already states for the other edge. Clause 13.1 described a plant MLOps node that "may never call Invoke at all" while AI-Base required at least one deployment. The facet's deployment requirements are now conditional on the Server exposing one. AI-OffServer cites 12.2's scheme requirement instead of restating it, so the two cannot drift. Three ambiguities are resolved where the guides had each invented an answer. ModelId carries the source's identifier verbatim, and Publisher names who produced the model rather than who serves it -- two Servers were reading owned_by into Publisher and publishing "azure" for a model Meta trained. AuthenticationKind classifies what is stored rather than the handshake performed, which is what makes SigV4 answerable without a new literal. ApiDialect classifies the contract this Server speaks, and a catalogue-only source is Proprietary with an EndpointDescriptionUri -- correct, not a shortcoming. The eleven guides are updated to cite these rules rather than derive them, and three that had softened 12.2's shall into an operator choice are corrected. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Release 0.3.0: state why a digest is absent, and reach a registry from an import Three changes the vendor mappings argued for that prose alone could not make. All three append; NodeId churn is 0 changed, 0 removed, 5 added. DigestProvenanceEnum, Mandatory on ModelType and Optional on ModelResourceType. Digest is Mandatory so that its absence is uniform and browsable, and that stays right -- seven of eleven systems cannot fill it, and Optional would make "no digest" indistinguishable from "does not implement digests". But empty then carried two meanings and populated carried three, and the missing answer was doing visible harm: five guides each prohibited a DIFFERENT wrong value -- a response fingerprint, a resource name, a storage entity tag, a manifest hash, a commit identifier -- and none could say what to publish instead. 12.1.1 states the prohibition once and supplies NotAvailable. Mandatory for the reason Digest is, which 6.2 already gives: clause 12 depends on it, and a rule that depends on an Optional member is one a conformant Server can silently not satisfy. A StatusCode cannot carry it -- DeclaredBySource and VerifiedOnStage are both Good. 12.1.1 also states that provenance does not strengthen by being forwarded, on the ordering NotAvailable < DeclaredBySource < ComputedByServer < VerifiedOnStage. Republishing an upstream peer's VerifiedOnStage would claim a check this Server did not perform, and the claim would be indistinguishable from one it had. Same composition argument as 9.5 residency, applied to the other thing a federated deployment forwards. ModelImportJobType.Registry, with 10.2 requiring exactly one of Source and Registry non-null. Source was Mandatory and typed ModelSourceType, so nothing connected an import job to a ModelRegistryType -- the edge the 4.4 and 5.1 diagrams draw. A Server importing from a catalogue had to invent a source wrapper around its own registry. Source keeps its Mandatory rule and takes null on the registry path, the idiom TargetDeployment already uses, so no existing member changes. ModelType.Name is constrained rather than retyped: its Text shall be the source's name carried across unchanged, translations may be added for display, and the Text is not reformatted. Retyping to String would have been cleaner and is breaking; the property wanted -- two Servers fetching one model from two mirrors produce the same string -- is obtainable by constraining the field. Version and PublicationDate bump to 0.3.0 / 2026-08-05, picked up by the vision overlays automatically because build_examples.py derives both from the AI generator rather than pinning them. The eleven guides state their DigestProvenance value and cite 12.1.1 instead of each re-arguing the prohibition. The index reads the member as the axis the set varies along: evidence tracks custody, which is why an embedded runtime -- a local file the Server can simply hash -- is the one arrangement here that produces evidence without vendor cooperation. Adds CHANGELOG.md, where this repository keeps release history so the specification does not have to narrate it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Stop sending a homeless identifier to a member that cannot hold it 12.1.1 correctly forbids a non-content identifier in Digest and then disposed of it into ArtifactUri or ProvenanceUri. Those are scalar String Properties on ModelType -- one artefact, one value. A serving configuration fingerprint is per-response and per-deployment, so the disposition is unimplementable for the case it was most needed in, and five guides were left telling an implementer not to publish a value the specification had just promised a home for. The narrowed rule says what is true: an identifier that LOCATES the artefact or its provenance record belongs in those members, and one that identifies something else has no member in this model. Recording that a datum has no home is better than filing it where a client reads it as an artefact digest. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Release 0.4.0: model what eleven real systems publish and this had no member for The same eleven mappings, read with a different question. 0.3.0 asked which rules were wrong; this asks what these systems do that the model cannot represent at all. The answer had a consistent signature: a guide NAMES a vendor field and then maps it nowhere, and the omission is invisible because nothing is missing from the guide's own tables. Twelve appended Properties, no new DataTypes. NodeId churn is 0 changed, 0 removed, 12 added. A model had no time on it. Six of eleven return a vintage in the call a Server populates ModelType from, and every guide dropped it. The asymmetry made it plain: DatasetType.CreatedAt exists with 6.3 defending it, and a catalogue resource inherits CreatedAt/ModifiedAt from xRegistry, so a model known through a catalogue had a vintage and the same model federated from an endpoint did not. LastModifiedAt is the load-bearing one: 9.3's FollowsRef lets the artefact change with nothing else changing, and 12.3.1 requires repointing to be an authorization-bearing act while pointing at a job record that a source-side move never produces. A model had no end to it. Bedrock alone publishes legacyTime and endOfLifeTime -- one vendor of eleven, and in the model anyway, because vendor count is the wrong measure for an industrial specification. On that date the deployment does not degrade, it stops; FallbackPolicy fires, and where that is FallBackTo the line keeps producing while something outside the qualified configuration answers. Every other availability facility here copes after the fact. This is the only one whose value is a date in the future. The asynchronous path could not carry a large payload. InferenceJobType had no TransferRequired and no Transfer, so InvokeAsync was bounded by exactly the limits 8.2.4 says this model does not choose -- while 8.6 motivated it with the requests most likely to exceed them, and 13.2 claimed a parity that did not exist. 8.6.1 separates two problems that had been collapsed: a result too large to carry, which the transfer pair solves, and data that never needed to move, which it does not. Five guides had discarded the vendor URI mechanism on the ground that it is not a chunked transfer; they were right, and there was nothing else to compare it to. A deployment did not say what to send it. Ten of eleven publish a request contract; the model captured the tensor half only, which is why AI-Signatures was unclaimable by every hosted platform. The vocabulary existed and was out of reach behind an explicit assertion in 9.2 that these members never affect how a client calls this Server. 6.4.2 puts ApiDialect and EndpointDescriptionUri on DeploymentType and 9.2's sentence is rewritten rather than quietly dropped: naming which contract opaque bytes must satisfy is not typing them, and 8.2's argument for opacity is about contents. A pinned deployment could move without anything changing. 12.1.1 forbade putting a serving-configuration fingerprint in Digest and offered ArtifactUri or ProvenanceUri, which are scalar Strings on ModelType and cannot hold a per-deployment value, so the datum was thrown away. RuntimeIdentity holds it, and 9.3.1 states what makes it matter: a change to it IS the observable change to the deployment that 9.3 says a pinned artefact cannot move without. Three defects found by reading the specification against itself. 6.4.3 made Degraded normative for a deployment missing its LatencyBudget while no measured latency existed anywhere, so the rule could not be observed to be satisfied or violated by any legal Server; ObservedLatency supplies the input. 13.2's AI-InvokeAsync row claimed size parity it did not have. 9.4's ListModels answered catalogue size with a cap and no cursor, putting everything past MaxResults permanently out of reach. Nothing added is Mandatory. Each is governed by a conditional shall in the clause that defines it, because a blanket Mandatory would oblige nine of eleven Servers to publish a RuntimeIdentity they cannot obtain, and a requirement no conformant implementation can satisfy is not a requirement. Breaking: Invoke and InvokeAsync gain a PayloadUri input and ListModels gains a ContinuationPoint in and out. Argument lists are the Value of an existing Variable, so no NodeId moves, but a client that calls positionally will break. Two tooling fixes fall out. validate_examples.py now reads Method argument names from the NodeSet, so a guide citing PayloadUri is checked rather than suppressed -- mutation-tested against a typo and an invented name. And a member description holding paragraphs was ending its own table row in the generated model reference, which stayed invisible only while such a member happened to be last in its table. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Define the profiles both clause titles have promised since 0.1.0 Clause 13 of the AI specification and clause 12 of Robot Intent are both titled "Profiles and conformance units" and both defined facets only. Neither information model changes, so neither version moves: profiles publish through the base-UA ServerProfileArray and need no member. A facet is a building block; a profile is a complete claim. The distinction is commercial rather than technical -- a plant writes a profile name into a purchase order, and enumerating nine facet names correctly is not something a procurement document does reliably. Robot Intent's 1.2 already depends on this without a word for it: a mixed-fleet cell works only if two robots claim the same shape. Four AI profiles. Inference Device, Inference Gateway, Model Catalogue, Model Lifecycle. The first three were already in 13.1 as prose examples -- a device running one fixed model, a gateway calling a hosted one, a plant MLOps node that may never call Invoke -- so naming them cost nothing but a name, and 13.1 now points at 13.3 instead of restating them. AI-Residency is INSIDE the gateway profile rather than optional to it. Once inference leaves the Server, where does my data go has an answer, and a gateway that cannot state it is the arrangement 9.5 exists to prevent. The Lifecycle profile is witnessed by none of the eleven mapped systems and is defined anyway. All eleven are inference or catalogue systems; none is a plant that trains, which is what clause 7 was written for. Its absence was also why AI-Learning, AI-Dataset and AI-Stream looked orphaned -- they belonged to a Server shape the document described nowhere. AI-Stream stays in no profile, because 13.2 already says a Server answering only through Invoke is conformant without it and a facet genuinely optional to every shape should not be bundled into one. Four Robot Intent profiles: Motion, Handling, Path, Mission. RI-Safety sits in the baseline, which is the decision here most worth arguing about. Clause 10 is explicit that nothing here is safety-rated and no Method is a safety function; what it imposes is a duty to report what the safety system enforces and refuse work exceeding it. An integrator specifying a profile is entitled to assume a robot declines an intent its safety configuration forbids rather than attempting it. The process facets are deliberately in no profile: a welding robot is a Path Server that additionally claims RI-Process-ArcWeld, and bundling the process in would have produced one profile per process with no way to say the motion underneath is the same. Both documents gain URI tables. A profile name is for a human and ServerProfileArray holds URIs, so without stated values two Servers implementing one profile publish different strings and no client matches either. Both gain definitions for conformance unit, facet and profile. Each used "facet" throughout and defined it nowhere, and in the AI document "profile" collides with the typed profile of a consuming specification, which is a payload vocabulary and unrelated to conformance. Profiles are added AFTER the facet tables. 13.2 is cited fourteen times; moving it would have churned every reference for nothing. validate_examples.py gates profile names against the profile table, so a guide naming a shape the specification does not define fails the way a misspelled facet does. Mutation-tested against a typo and an invented name. It checks the name and not the claim, which its docstring says plainly: whether a guide's facets cover the profile it names is a judgement over prose, and a checker guessing at that would fail on wording rather than substance. The eleven guides name their profile. Eight reach Gateway, two reach Device, one reaches Catalogue, and none reaches Lifecycle. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Separate a paragraph from the table it followed The ServerProfileArray obligation sat on the line after the last facet row, so markdownlint read it as a fourteenth row with one cell. My pre-push check tested for a table glued after text and not for text glued after a table; it now tests both directions. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
Both sides added to Robot Intent's Unreleased changelog and nothing else conflicted. Upstream recorded the defects found by implementing the specification in the .NET Standard stack -- observable refusals, the Part 10 ProgramDiagnostic promotion, the bounded Signal, the NodeId type table, and the capability-implies-Methods rule. This branch recorded the four profiles clause 12 has promised in its title since 0.1.0. They are independent, so both are kept, each under its own heading. One wording change on this side: the profiles entry said the information model does not change, which was true of that change alone and is not true of the release as a whole now that the implementation defects moved Method signatures. It now says the model does not change on its account. Verified rather than assumed: every RI- facet name the profiles bundle still resolves against the merged facet table, the terminology entries survived, and all three generators rebuild byte-identical, so the merge left no generated artefact inconsistent with its source. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
The README explained how to contribute well and what exists badly. The inventory was a Layout list of single-paragraph bullets -- the Data Channels one ran to 1,900 characters -- carrying no version, no status, and no link to any specification document. A reader could not get from the README to a specification in one click, could not tell which of the sixteen documents were under OPC Foundation review, and had no single place saying what the whole effort is. It is now one table per folder prefix, covering this repository and the private submodule together, so the grouping is complete rather than split by which repository a document happens to sit in today. That is why wot appears at all: both its specifications are under review and the tree has left, so a prefix-grouped list is the only place the reader learns they exist. Columns are Specification, what it is and why it exists, status, and documents -- markdown first, then Word. Three specifications have no Word rendering and their cell says so with an em dash rather than omitting the column, because the gap is worth seeing: Vision, Robot Intent and AI Model Management have no clause map under word-drafts/tools/specs/, which is what drives that build. release_spec.py gains a third repair pass. It maintains this file when a specification moves private -- capsuling the describing list item with its original base64-encoded so a return restores it, and emptying links into the moved tree -- and it understood list items and links, not table rows. Without the pass the next release would leave a row advertising a document that is no longer here. Three things had to be right and were verified rather than assumed. The row pass runs BEFORE the link pass, because afterwards every row already holds a capsule around its own links and would be skipped, exactly as the bullet pass skips such lines. The replacement keeps the row's cell count, since collapsing four cells into two fails MD056. And only tables whose last two columns are Status and Documents are touched, so a table of another shape is left alone rather than rewritten into something the function guessed at. Return needed no new code: capsule_belongs_to already matches a capsule by a link resolving into the returning set, and every row carries one. Round trips for six specifications across four trees restore the file byte-for-byte. The five capsules for the specifications already under review encode the table row they should become, not the bullet they used to be. Restoring a 1,900-character bullet into a table cell would be worse than the gap it filled. The five reviewed specifications link to github.com/OPCF-Members rather than to spec-drafts/ paths. The submodule is empty for everyone who is not a member, so a relative link would fail check_links.py for them and still open nothing. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
markdownlint counts a row's cells without stripping HTML comments, so a closing marker after the final pipe leaves the row ending in content: MD055 read it as a missing trailing pipe and MD056 counted a fifth cell. Both markers now sit between the outer pipes, which is invisible to a reader and correct to the parser. My pre-push check stripped the comments before counting, which is exactly why it passed locally and failed in CI. It now counts them the way markdownlint does. Round trips still restore byte-for-byte; the encoded original is the row between its outer pipes rather than after the first one. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
MD012 counts the newline after the final paragraph plus the file's own terminator as two blank lines. My check read the file through Get-Content, which drops that distinction, so it saw one. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
Both sides added a way to declare conformance to the end of clause 12.2, which is a genuine overlap rather than a textual collision, so the resolution states how the two relate instead of concatenating them. Upstream added IntentCapabilitiesType.SupportedFacets: a controller lists the facets of Table 12.2 it claims, because conformance was otherwise not machine-readable and several rows are behavioural, so two clients deriving it independently could reach opposite conclusions about one Server and both be reading the specification correctly. This branch added profiles and required their URIs in ServerProfileArray. Left as two independent SHALLs those would be two sources of truth for one fact. They are not, and the granularity is what separates them: SupportedFacets is a member of IntentCapabilitiesType, so it is stated per controller, and a Server hosting two robots of different capability has two answers. ServerProfileArray is a member of the Server object, so it is stated once for the Server, which is the right level for a profile -- a named shape an integrator specifies and a supplier builds to. So the Server publishes profile URIs, may publish facet URIs beside them, and where it does the two shall agree: a facet URI no controller lists in SupportedFacets is a claim nothing in the address space backs. Upstream had already reached for the same precedent, citing ServerCapabilitiesType.ServerProfileArray as what SupportedFacets mirrors. Two smaller consequences follow. 12.3 says that claiming a profile claims every facet in it on 12.2's terms -- structural requirements a client checks by reading, behavioural ones the Server attests to under clause 9 -- so a profile is a shorter way to say the same thing, not a weaker one. And 12.4 names SupportedFacets as the authority on what a controller satisfies, leaving the facet URIs for a generic tool that reads ServerProfileArray and knows nothing about robots. Upstream added a Mandatory member without a changelog entry, so this records SupportedFacets in the terms of its own commit message. The repository keeps release history in CHANGELOG.md, and a Mandatory addition going unrecorded beside a prose-only change that is recorded would misrepresent the release. Verified rather than assumed: all 31 facet names the profiles bundle resolve against the rewritten facet table, the generator rebuilds to 259 nodes with SupportedFacets at i=6139 and nothing renumbered, and every validator, link and section-reference check passes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa
marcschier
added a commit
that referenced
this pull request
Aug 7, 2026
* Supply the motion verbs OPC 40010 leaves undefined OPC 40010-1 describes robot topology in detail and defines no motion verbs at all: its whole actuation surface is Start, Stop and loading a named program. A client can discover everything about a robot's construction and cannot ask it to move anywhere. This adds OPC UA - Robot Intent, which supplies the verbs and nothing else, so the two compose rather than compete. The lifecycle is the harder half. A motion takes seconds and a pick takes a minute, while OPC 10000-4 clause 5.12.2 discards a method result when the Session ends "independent of the task actually performed at the Server" - so a synchronous motion method loses the outcome of work that has already physically happened. Submission therefore returns a Part 10 program instance and the client watches it, which is the resolution OPC 10000-10 clause 4.1 already reaches for exactly this case. Verbs are a DataType hierarchy rather than one Method each, so a single submission and a mission step are the same shape and extension is subtyping. Queueing is PLCopen MC_BufferMode and concurrency is VDA 5050 blockingType, both adopted unchanged because both are already implemented everywhere and no OPC UA specification defines either. Missions carry an immutable committed base and a revisable horizon. Orientation is a unit quaternion: OPC UA defines no quaternion type, and the A/B/C fields of ThreeDOrientation carry no convention of their own. Annex C carries the bidirectional conversion, including the clamp that stops a pole orientation becoming a domain error. Pick and Place reference Location nodes rather than naming a station in a string, which would be a second definition of a fact the address space already holds. Clause 10 declares the interface non-safety-rated, restricts submission to Automatic and Automatic External, and records that a stop request selects no IEC 60204-1 stop category. Clause 8 says plainly that command authority arbitrates between clients and is not the single point of control ISO 10218-2 requires. The NodeSet is standalone on base OPC UA, following the Vision precedent; OPC 40010-1 interop is an optional profile carried by a ReferenceType. The validator re-derives from the committed artifacts rather than asking the generator what it emitted, and cross-checks the specification against the model in both directions. It was mutation-tested against thirteen defects, including one introduced in the generator and fully regenerated so that the NodeSet, the CSV and Annex A all agree with each other - which only the specification invariants can catch. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Browse encodings where the standard says they are A DataTypeEncoding browses as "Default Binary" in namespace 0. The BrowseName is standard, not model-defined, and every published companion NodeSet writes it that way. Both generators were emitting 1:Default Binary. This is not cosmetic. Tooling that resolves encodings by BrowseName cannot find them: the UA-.NETStandard model source generator fails outright on such a NodeSet, and the failure surfaces as a NullReferenceException with no indication of which node caused it - it took a binary search over the node list to find. Both models are regenerated. No NodeId moves, because only the BrowseName and the added SymbolicName change: Vision is nine lines, Robot Intent eighteen. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Bring the deferred and excluded capability into scope Five things the specification did not do. Four are now defined; the fifth turns out not to be a scoping choice at all. Real-time was an exclusion and is now a division of labour. Trajectory execution is expressible over request/response - the whole path is handed over once and the robot's own motion kernel runs it, which is what FollowJointTrajectory and the PLCopen buffered path blocks already do - so TrajectoryIntentDataType, CartesianPathIntentDataType and ForceIntentDataType are defined here. Streaming control is not expressible, so the model brokers a channel instead: RealTimeChannelType describes and leases RTDE, EGM, FRI, RSI, MotoROS2 or OPC UA FX and the samples never traverse OPC UA. That is the same shape as the Vision model brokering a media endpoint rather than carrying pixels. Safety cannot be brought into scope as a rating, and the reason is structural rather than editorial. OPC 10000-15 carries cyclic safety data from a provider to a consumer; the consumer's request holds an identifier, a monitoring number and one octet of explicitly non-safety flags, so a caller has no channel through which to supply safety-rated arguments. Every safety fieldbus expresses a safety command as a continuously asserted cyclic signal, because the integrity argument rests on the fail-safe state that follows when assertion stops - and a Method call has no defined behaviour when it stops being called. So safety is in scope as awareness plus a duty: SafetyStateType reports what the safety system enforces, clause 10.4 requires a Server to refuse work that would exceed it, and the same clause says plainly that neither of those makes anything safe. A Server may observe the safety system and refuse on what it sees; it may never instruct it. Robot construction was excluded on the grounds that OPC 40010 covers it. It does not cover this part: OPC 40010-1 describes topology and axes and defines no kinematic chain an IK solver could use, and no tool centre point at all. RobotDescriptionType is therefore additive, and Annex B fixes which side decides where both are present. Process models are defined for all six applications, with fastening left deliberately thin: OPC 40450 and OPC 40451 already own joining and tightening, so FastenIntentDataType references a joint there rather than restating torque strategies - the rule that already made Pick take a Location node instead of a station string. Mission branching follows IEC 61131-3 rather than a behaviour tree. Steps and transitions with alternative and parallel divergence are the notation the controller audience knows and have an IEC serialization; a behaviour tree needs a tick runtime controller vendors do not provide. Transition conditions reuse the base UA ContentFilter, so nobody has to write a parser for an invented expression language, and an empty transition array leaves a mission the flat sequence it was. 83 nodes added, 0 removed, 0 renumbered. The validator gained invariants for the process hierarchy, the ContentFilter reuse and the mandatory safety members, and the mutation suite grew from 13 defects to 17 - all caught, with the tree restored byte-exactly. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Make three claims true that the model did not support The prose said TrajectoryIntentDataType carries PathTolerance, GoalTolerance and GoalTimeTolerance "all MotionToleranceDataType". GoalTimeTolerance is a Duration. An implementer decoding the structure from the prose gets the wire format wrong at that field, and the structure is not self-describing there. Lateness is one number, not a pose deviation. The 6.3 state diagram had Retriable --> Queued and gave Retriable no exit to terminal, so execution resumed on the same instance. Clause 3 defines Retriable as a state "from which execution does not resume", 6.6 says Retry creates a NEW operation with the original left terminal, and 6.7 says a terminal Result shall not change thereafter. The model cannot distinguish the two readings - Retriable to Queued is Halted to Ready, which Part 10 permits - so a conformance test built from the model alone rejects neither, and two implementations get incompatible operation lifetimes. FinalResultData and ProgramDiagnostic are Optional in ProgramStateMachineType and were not promoted. So 6.7's "shall also be reachable under FinalResultData" rested on a member a conformant Server may omit, and 1.2's headline "auditable commanding" claim - which IS ProgramDiagnostic and nothing else - was false against a legal implementation. Both are now Mandatory on IntentOperationType, which is the repository's stated remedy: a conformance unit that depends on an inherited member promotes that member. Written beside their type the promotions renumbered 39 members; they are allocated at the end of the id space instead. 0 moved. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Make refusal observable and the Part 10 promotions legal Implementing this specification in the OPC UA .NET Standard stack surfaced six defects. Each is a claim the document already made that the model did not let a conformant Server keep. Clause 6.2 orders six refusals and clause 5.8 calls the failure set small and diagnosable on purpose, but SubmitIntent returned only IntentId and Operation. A client could see that something had been refused and never which of the six it was, so the ordering was unobservable and the failure taxonomy unreachable. SubmitIntent, SubmitMission and Retry now return Accepted, Failure and Message, clause 6.2 states that a Server returns Good and reports the refusal there rather than substituting a Bad StatusCode, and OpenRealTimeChannel gains a Message because clause 6.9 hid four grounds for refusal behind one boolean. IntentOperationType declared ProgramDiagnostic as a Property of PropertyType reached by HasProperty. OPC 10000-10 declares it as a Variable of ProgramDiagnostic2Type reached by HasComponent, so the declaration added a second member beside the inherited one instead of promoting it - which is why a Part 10 client would not have found it where Part 10 says it is, and why the first stack to generate the model deleted it. A promotion changes the ModellingRule and nothing else; clause 6.1 now says so. WaitIntentDataType.Signal read "an OutputSignal or other node", which clause 11.3 cannot check, and an unvalidated NodeId is the surface clause 11.3 exists to close. It is now bounded to an OutputSignal under the controller or a Boolean Variable under it, and clause 11.3 tabulates the expected type of every NodeId-valued member rather than leaving "the expected type" to the reader. Ready, ActiveIntent, ActiveMission and ControlOwner were in the model and in no clause; clause 5.7.0 gives them normative meaning. Clause 6.9 now bounds RequestedLease, which the lease rules never limited. The NodeSet, the CSV and Annex A are regenerated; no previously assigned NodeId moves. * Make the capability declaration honest about its Method surface Implementing the specification a second time surfaced three more places where a conformant Server could tell a client something untrue. Clause 9 already had three rules keeping the capability declaration honest, but none of them said that a declared capability must come with the Methods that make it usable. SubmitMission, UpdateMission, CancelMission and both real-time channel Methods are Optional on IntentControllerType, so a Server could report MissionsSupported true and omit SubmitMission entirely - which is exactly what the first implementation did, and the contradiction only surfaced when a client called something that was not there. A fourth rule and a table now fix which Methods each declaration implies, and like the other three it is checkable by browsing a running Server. Clause 6.5 gave StopMode the PossibleStopModes vocabulary of OPC 40010-1 and then said nothing about a Server that treats every value alike, so accepting the argument and discarding it looked conformant. A Server must now either honour it or treat every value as its single stop behaviour, and should say which - a client that asks for OnPath and silently receives a QuickStop has been told something untrue about how the cell came to rest. Clause 6.4 left the stop mode of a superseded intent undefined, because an Aborting submission names none. The Server chooses, should choose the most urgent stop the cell tolerates since the successor is about to command motion of its own, and should document which. Prose only; the model is unchanged and regenerates identically. * Let a Server state which facets it satisfies Clause 12 defined conformance in terms of facets and then gave a Server nowhere to say which ones it had. A client that wanted to know whether a controller supported blending had to re-derive the whole of Table 12.2 from the address space itself, which is what the reference implementation ended up doing. That is worse than verbose. Several rows of the table are behavioural -- "the four blending buffer modes accepted and honoured", "the refusal rules of 6.2", "the base immutability rules of 7.2" -- and no amount of browsing settles them. Two clients deriving conformance independently could therefore reach opposite conclusions about the same Server and both be reading the specification correctly. OPC 10000-5 already answers this with ServerCapabilitiesType. ServerProfileArray: the Server states its profiles rather than leaving them to be inferred. IntentCapabilitiesType now carries SupportedFacets on the same principle, Mandatory, naming the facets of Table 12.2 verbatim. Clause 12.2 now separates the two kinds of requirement it had been mixing. Structural requirements are settled by reading -- the Outputs folder, more than one ToolType, axes covering 0 to AxisCount - 1 -- and a Server shall not list a facet whose structural requirements are unmet. Behavioural requirements are the Server's attestation, and clause 9 says what that means: listing RI-Blending while treating the buffer modes as Buffered is the same false statement rule 3 already forbids, whatever BlendingSupported says. RI-Base requires SupportedFacets, since a conformance claim that cannot be read is not a claim. The member appends at i=6139; no existing NodeId moves. * Make the Part 10 promotions real, and say what Pause means Two defects, both found by implementing the draft and reviewing the result. The promotions of FinalResultData and ProgramDiagnostic were emitted with namespace-1 BrowseNames. OPC 10000-3 says a subtype overrides an inherited InstanceDeclaration by re-declaring a child with the same QualifiedName, and a QualifiedName includes the namespace index -- so 1:ProgramDiagnostic never overrode 0:ProgramDiagnostic, it declared a second member beside it and left the inherited Optional one in place. That is the same failure the TypeDefinition and reference type were already careful to avoid, reached by a different route, and it defeated the entire point of promoting: clause 6.7's SHALL and the clause 1.2 auditable-commanding claim still rested on members a conformant Server could omit. The generated client made it visible -- its accessor used `new` to hide the base Part 10 one. Both now carry namespace-0 BrowseNames, using the same mechanism already applied to DataTypeEncoding browse names for the same reason, and every other NodeSet in the reference stack promotes inherited state-machine members unprefixed. Clause 6.6 required Pause to suspend execution retaining position, but the model defines no channel through which a Server can tell an actuator to pause mid-motion. A Server whose controller offers no pause could therefore only publish Suspended and hope -- and Part 10 defines that state as position retained, so an operator reading the HMI sees the arm at rest while it finishes the move. The reference implementation did exactly that until a review caught it. The requirement stays, because stopping the robot is what Pause should mean. What is added is the honesty rule the rest of clause 9 already applies elsewhere: a Server that cannot suspend a running intent declares PauseSupported false, may still stop its queue, and leaves the executing operation Executing with Ready reflecting that nothing new is admitted. Suspended is never reported while the robot is still moving. That makes clause 9 four rules rather than three, alongside the BlendingSupported rule it is modelled on. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: a248a589-9a20-4372-868e-5d347e57001b * Give the AI models their own specification, and let a Server use them (#49) * Give Vision a frame role for the flange Vision's frame vocabulary was World, Base, Tool, Camera, Object, Other. It had no value for the mechanical interface, so its own eye-in-hand picking example labelled the flange `Tool` and the frame tree contained no tool centre point at all. That is not a naming quibble. The hand-eye calibration in Annex F resolves camera to flange, and a pick has to reach the TCP. With one `Tool` role the example could not carry the offset between them: adding a second frame for the real TCP would have made `Tool` ambiguous inside one tree. Vision 5.8 describes this exact failure - "the pose is correct and the robot moves to the wrong place, because the two ends disagreed about what the numbers were relative to" - and the annex reproduced it. `MechanicalInterface` is added and the literals are renumbered to match Robot Intent, which had it right. Renumbering is free today and permanent after publication: enum values live in EnumStrings, so no NodeId moves - the CSV diff is 0 changed, 0 removed, 0 added for both models. The example descriptor gains a `GripperTcpFrame` so the picking example carries the flange-to-TCP offset explicitly rather than leaving a consumer to assume it, and says why the two frames are distinct. Annex F, both addenda and the overlays regenerate from it. Vision 5.12 gains the three pose rules it was missing beside Robot Intent's: right-handedness, quaternion normalisation, and the statement that this model defines no default frame. The last one matters most - the same empty `FrameId` means "not actionable" here and "default work frame" there, so a transcoder written by someone who read one specification would have produced a pose in the wrong frame. Ten bare "5.10" references cited DataTypes when the rules they name - corner datum, distortion ordering, frame precedence, the covariance sentinel - are all in 5.12. They passed CI because check_section_refs.py requires a literal section sign to see a reference at all. Both specifications now carry a mutual interop annex, which neither did: they never referenced each other despite being deployed on the same robot. Vision Annex I and Robot Intent Annex E fix which frame tree decides, how FrameId values correspond, that roles map by name and never by integer, how poses transcode across the covariance field, and that a grasp pose resolving only to the mechanical interface is refused. Annexes only - no NodeIds, no NodeSet dependency, and both models keep base OPC UA as their only RequiredModel. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Give the AI model its own specification Vision had grown a model nameplate, a dataset, a deployment and a learning job - 30 members and ten types - none of which mention a camera. A process soft sensor needs all of it and none of a lens, so leaving it there would have obliged every other domain either to declare a vision model as a RequiredModel or to define the whole thing again, at which point the provenance question stops having one answer. metaverse-specs/ai-deployment/ is domain-neutral by construction: its validator fails the build if a type name acquires a domain term, and the check is CamelCase word-boundary matched so Framework is not a false hit. DeploymentStateEnum replaces the VisionEndpointStateEnum the deployment had borrowed - same five literals, no dependency. The join is a facet precondition, not a RequiredModel. InferencePipelineType.Deployment was already a plain NodeId, so Vision's namespace index does not shift and a Server that publishes cameras and verdicts without ever naming a model is still conformant to VIS-Base. VIS-Inference-* and VIS-Learning require AI-Base, and say so. No Vision NodeId moves. The vacated blocks - 6107..6136, 6177..6190, 6193, 6195 - are reserved rather than reclaimed, because reusing them would renumber all 45 members declared after them. The CSV diff is 61 removed, 0 added, 0 moved. Both validators now cross-check specification against model in both directions. That found 16 real gaps in Vision: enum literals and structure fields the model declared and the prose had truncated with "and so on". Mutation-tested in both directions on both models. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Stop restating the learning loop in two places Clause 9.5 carried StartCollection, StopCollection, TriggerTraining and PromoteModel with their StatusCodes, and 9.6 carried the state model - all of which LearningJobType owns and OPC UA - AI Deployment and Learning now states. Two documents stating one transition table is two places for it to be wrong, and the wrong one is found by an implementer rather than by a validator. 9.5.1 keeps only the vision-specific half: the join between a correction submitted through VisionFeedbackType and the job that consumes it. The distinct PromoteModel authorization is deliberately stated in both documents, because it is the one rule where a reader of either alone would reach the wrong conclusion. The both-directions cross-check then found a real defect the old prose had hidden. Clause 9.2 was titled "The three purposes" and described three; VisionFeedbackPurposeEnum declares four. Trigger had never been documented - it only appeared to be, because a "| From | Trigger | To |" table header in the deleted state model satisfied the word match. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Let a Server actually use a model, not just describe one The model said what a model IS and never let anyone use one. EndpointUri was a bare String: no wire contract, no credential, no capabilities, no failure semantics. A Server holding one knew where to send bytes and nothing about what shape they should take or what to do when the far end stopped answering - so "consume a model hosted elsewhere", which is the whole point of the InferenceLocation property, was unimplementable from what this model told it. Three additions. Clause 7 defines one invocation surface whose signature does NOT change with InferenceLocation. That is not an aspiration: serving runtimes that run on a workstation and the hosted services they mirror already expose the same contract, differing only in addressing and auth. The payload stays opaque - it is domain vocabulary - and what gets fixed is the envelope, where ModelUsed reports the model that ACTUALLY answered. A fallback or a followed reference moves it between the call and the read, so the deployment's current model is the wrong answer to "what produced this result", and wrong in the direction that looks plausible. Clause 8 makes remote consumption real: dialect, auth kind, a credential REFERENCE that is never a secret, capabilities, reachability, and the question no inference API answers because it can assume its caller will wait - what the line does when the WAN drops. FallbackPolicy is Mandatory. So is DataJurisdiction and EgressPermitted, because encryption answers who can read data in flight and not where it went. Clause 9 makes the catalogue an xRegistry domain extension rather than a private invention. Two things then fall out of the base type instead of being designed: ResourceType IS a FileType, so a staged artefact streams through the inherited Open/Read/Close; and it already carries ExternalReference, so a federated entry whose bytes live elsewhere is expressible without pretending to hold them. The import job federates by default and stages when the target could not otherwise reach the source, and verifies the digest at staging - the one moment a substituted artefact would enter. Jobs now derive from the Part 10 ProgramStateMachineType through a shared AiJobType, as Robot Intent does, so the transition events and auditability are inherited rather than reinvented. Costs, stated plainly rather than buried: this model now requires OPC UA - xRegistry, which spends the "exactly one RequiredModel" claim and moves the own namespace from ns=1 to ns=2. Both validators hardcoded ns=1 while reading it - Vision's would have resolved nothing and passed. Both now derive the index from NamespaceUris. No NodeId moved. JobId and LastError moved up to AiJobType and their ids are reserved, not reclaimed: 0 removed in place, 141 added, 0 moved. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Enforce the new rules, and show what they add up to The invariants that make clauses 7 to 10 executable rather than aspirational, each mutation-tested: - The four Mandatory members clause 8 rests on. A rule resting on an Optional member is a rule a conformant Server can silently not satisfy. - Invoke returns ModelUsed, Usage and FinishReason. - Nothing in the address space is NAMED like credential material. That is how the clause 8.2 prohibition gets violated by accident, and the address space is browsable, subscribable and historisable, so a secret placed here is not merely readable - it is archived. - The catalogue types narrow their inherited placeholders. A domain extension that leaves them open adds metadata while restricting nothing. - AiJobType still derives from the Part 10 base. - NamespaceUris order, because it fixes every namespace index in the file. All seven mutations caught; artifacts restored byte-exactly. Annex C works one arrangement end to end: a federated cloud model and a staged edge model, the WAN dropping, and the fallback answering. The point of it is the sentence a table cannot make - the client called the same Method with the same arguments throughout and never learned that inference had moved, except by reading ModelUsed, which is exactly what an audit a month later needs and what a client logging the deployment would have got wrong. ApiDialectEnum.OpenAiCompatible became RestChatCompletions. The literal named a company. A standard's enumeration should describe the contract, not advertise whoever published it first - and the prose says what it is compatible with without needing the name. No vendor is named anywhere in the document. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Deepen the clauses that were already there Adding three clauses left the existing ones describing a smaller model than the one that now exists, and put 5.6 between 5.1 and 5.2 - the out-of-document-order defect this repository has been bitten by before and which no check catches. 5.6 moved to where it belongs. Every heading is now in order. 5.2 documents what a model carries beyond its artefact: the publisher that completes the identity triple, and Quantization, which is not a packaging detail - a quantized model is a different artefact that gives different answers, and treating it as a variant is how a model evaluated at full precision ends up deployed at reduced precision with nobody re-measuring it. 5.3 says why Mixed is not a hedge, and that a dataset whose class list disagrees in ORDER with its model is undetectable: every identifier resolves, every count is plausible, every label is off by one. 5.4 gains a table of everything that makes a deployment callable, and the reason State and Reachability are separate. Ready + Unreachable is a network fault; Faulted + Reachable points at credentials. Collapsing them loses exactly what a commissioning engineer needs. 6 gains the joins to the consuming half - a trained candidate is not privileged over an imported model and owes the same lineage - and says plainly that almost no Server implements the whole loop, which is why State is read rather than inferred from which Methods exist. 11 grew because the attack surface did. The chain has more links; two break while a Server looks correct. The resolver policy now governs seven URIs, and applying it to a staging import AFTER transfer is not a control. Credential material is unaddressable, argued from the fact that the address space is subscribable and historisable - a secret there is not exposed once, it is published and archived. FollowsRef is promotion's second door and needs the same authorization, or the audit trail shows every promotion having been authorized. And a fallback may not be more permissive on egress than what falls back to it, or a network fault quietly sends plant data where policy forbids. 11.4 now says what DigestVerified actually means: the artefact is the one this catalogue entry described. An attacker who can edit both artefact and entry defeats it, and the catalogue is the better target because many machines read it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Fix what the review found in the AI split Critical: the prose described a root object the model does not have. VisionRootType lost Models and LearningJobs when the AI cluster moved, but 4.2 still listed them normatively, 5.3 still said "five folders", and the 5.2 figure still drew them. A Server following 4.2 literally would instantiate two folders no ModellingRule permits, and a client following 5.3 to decide "is this Server doing AI" would browse for a folder that can never exist. The figure now shows the AI cluster where it actually lives - under AiRootType, beside the Vision object, not inside it. Both worked examples had the same fault and a worse consequence: they parked AI instances in those folders and never instantiated AiRootType at all, so the only executable demonstration of the new seam could not satisfy the AI-Base facet that VIS-Inference-* and VIS-Learning now require. They now build a proper AI root under the Server object. The learning loop lost content in the move that landed nowhere: the StatusCode table, the idempotency of StartCollection/StopCollection, TriggerTraining returning Accepted=false with Good, and the all-or-none rule for a null Deployment. Worse, two transitions vanished - Promoted had NO outgoing edge, so the loop could run exactly once, contradicting the AI spec's own "the cycle repeats" two clauses earlier. Restored, with the transition table it needs to be testable. Both ReferenceType arrows in the AI overview figure were drawn backwards against their own definitions. UsesModel is Deployment->Model and TrainedOn is Model->Dataset; the figure said the opposite, so an implementer following it would emit references that fail the exactly-one rule. Vision's equivalent figure had them right, so the two documents disagreed. Vision still owned a rule it had handed over: 5.11 restated the exactly-one UsesModel constraint verbatim, over a ReferenceType it no longer defines - visible in the mangled "An DeploymentType", which is what a mechanical rename leaves behind. Also fixed: a stale AiModelType in a descriptor that a generated annex was publishing, an AiDeployment reference shipping inside the NodeSet itself, an ObjectType count that said 25 against an actual 21, and a scope sentence still claiming Vision covers AI. 9.5.1 rule 1 required something no member could express - there was no modelled path from a pipeline to a learning job, and the folder that used to anchor one had just been removed. InferencePipelineType.LearningJob makes it executable. Writing it beside its type renumbered InferencePipelineType.Stop, so it is allocated at the true end of the id space instead; 0 moved. The encoding id counter was unguarded, so the 5009 freed by the moved structure would have been silently reclaimed by the next structure added - the same append-only violation the member ids were carefully protected from. Two validator blind spots, both proved by the reviewers and both now mutation-tested: the AI validator rejected any struct field documented as Type.Field, and the reverse cross-check silently SKIPPED a backticked owner that no model declares - so a reference to a retired type passed. That check now lives in Vision's validator, which is the only one with both models loaded and therefore the only one able to tell an outside type from a nonexistent one. Types from companion specifications are allowlisted explicitly, so taking a new outside dependency is a deliberate edit. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Require a Mandatory member to be documented, not just its type The both-directions cross-check only compared type NAMES, so a whole Method and three Mandatory members shipped undocumented: a Server is obliged to implement them and a client has nothing to read. ListModels, ModelSourceType.SourceId, and EvaluationRunType's RunId, EvaluatedModel and Metrics. The forward direction now checks member granularity for Methods and Mandatory members, and stops there: demanding prose for every Optional member would produce padding rather than documentation. All five are now documented, including why ListModels takes a filter - a public catalogue holds more models than any client wants to page through, so a Method that could only return everything would be unusable against exactly the sources clause 8 exists to reach. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Let a Server actually use a model, not just describe one (#50) * Let a Server actually use a model, not just describe one The model said what a model IS and never let anyone use one. EndpointUri was a bare String: no wire contract, no credential, no capabilities, no failure semantics. A Server holding one knew where to send bytes and nothing about what shape they should take or what to do when the far end stopped answering - so "consume a model hosted elsewhere", which is the whole point of the InferenceLocation property, was unimplementable from what this model told it. Three additions. Clause 7 defines one invocation surface whose signature does NOT change with InferenceLocation. That is not an aspiration: serving runtimes that run on a workstation and the hosted services they mirror already expose the same contract, differing only in addressing and auth. The payload stays opaque - it is domain vocabulary - and what gets fixed is the envelope, where ModelUsed reports the model that ACTUALLY answered. A fallback or a followed reference moves it between the call and the read, so the deployment's current model is the wrong answer to "what produced this result", and wrong in the direction that looks plausible. Clause 8 makes remote consumption real: dialect, auth kind, a credential REFERENCE that is never a secret, capabilities, reachability, and the question no inference API answers because it can assume its caller will wait - what the line does when the WAN drops. FallbackPolicy is Mandatory. So is DataJurisdiction and EgressPermitted, because encryption answers who can read data in flight and not where it went. Clause 9 makes the catalogue an xRegistry domain extension rather than a private invention. Two things then fall out of the base type instead of being designed: ResourceType IS a FileType, so a staged artefact streams through the inherited Open/Read/Close; and it already carries ExternalReference, so a federated entry whose bytes live elsewhere is expressible without pretending to hold them. The import job federates by default and stages when the target could not otherwise reach the source, and verifies the digest at staging - the one moment a substituted artefact would enter. Jobs now derive from the Part 10 ProgramStateMachineType through a shared AiJobType, as Robot Intent does, so the transition events and auditability are inherited rather than reinvented. Costs, stated plainly rather than buried: this model now requires OPC UA - xRegistry, which spends the "exactly one RequiredModel" claim and moves the own namespace from ns=1 to ns=2. Both validators hardcoded ns=1 while reading it - Vision's would have resolved nothing and passed. Both now derive the index from NamespaceUris. No NodeId moved. JobId and LastError moved up to AiJobType and their ids are reserved, not reclaimed: 0 removed in place, 141 added, 0 moved. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Enforce the new rules, and show what they add up to The invariants that make clauses 7 to 10 executable rather than aspirational, each mutation-tested: - The four Mandatory members clause 8 rests on. A rule resting on an Optional member is a rule a conformant Server can silently not satisfy. - Invoke returns ModelUsed, Usage and FinishReason. - Nothing in the address space is NAMED like credential material. That is how the clause 8.2 prohibition gets violated by accident, and the address space is browsable, subscribable and historisable, so a secret placed here is not merely readable - it is archived. - The catalogue types narrow their inherited placeholders. A domain extension that leaves them open adds metadata while restricting nothing. - AiJobType still derives from the Part 10 base. - NamespaceUris order, because it fixes every namespace index in the file. All seven mutations caught; artifacts restored byte-exactly. Annex C works one arrangement end to end: a federated cloud model and a staged edge model, the WAN dropping, and the fallback answering. The point of it is the sentence a table cannot make - the client called the same Method with the same arguments throughout and never learned that inference had moved, except by reading ModelUsed, which is exactly what an audit a month later needs and what a client logging the deployment would have got wrong. ApiDialectEnum.OpenAiCompatible became RestChatCompletions. The literal named a company. A standard's enumeration should describe the contract, not advertise whoever published it first - and the prose says what it is compatible with without needing the name. No vendor is named anywhere in the document. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Deepen the clauses that were already there Adding three clauses left the existing ones describing a smaller model than the one that now exists, and put 5.6 between 5.1 and 5.2 - the out-of-document-order defect this repository has been bitten by before and which no check catches. 5.6 moved to where it belongs. Every heading is now in order. 5.2 documents what a model carries beyond its artefact: the publisher that completes the identity triple, and Quantization, which is not a packaging detail - a quantized model is a different artefact that gives different answers, and treating it as a variant is how a model evaluated at full precision ends up deployed at reduced precision with nobody re-measuring it. 5.3 says why Mixed is not a hedge, and that a dataset whose class list disagrees in ORDER with its model is undetectable: every identifier resolves, every count is plausible, every label is off by one. 5.4 gains a table of everything that makes a deployment callable, and the reason State and Reachability are separate. Ready + Unreachable is a network fault; Faulted + Reachable points at credentials. Collapsing them loses exactly what a commissioning engineer needs. 6 gains the joins to the consuming half - a trained candidate is not privileged over an imported model and owes the same lineage - and says plainly that almost no Server implements the whole loop, which is why State is read rather than inferred from which Methods exist. 11 grew because the attack surface did. The chain has more links; two break while a Server looks correct. The resolver policy now governs seven URIs, and applying it to a staging import AFTER transfer is not a control. Credential material is unaddressable, argued from the fact that the address space is subscribable and historisable - a secret there is not exposed once, it is published and archived. FollowsRef is promotion's second door and needs the same authorization, or the audit trail shows every promotion having been authorized. And a fallback may not be more permissive on egress than what falls back to it, or a network fault quietly sends plant data where policy forbids. 11.4 now says what DigestVerified actually means: the artefact is the one this catalogue entry described. An attacker who can edit both artefact and entry defeats it, and the catalogue is the better target because many machines read it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Require a Mandatory member to be documented, not just its type The both-directions cross-check only compared type NAMES, so a whole Method and three Mandatory members shipped undocumented: a Server is obliged to implement them and a client has nothing to read. ListModels, ModelSourceType.SourceId, and EvaluationRunType's RunId, EvaluatedModel and Metrics. The forward direction now checks member granularity for Methods and Mandatory members, and stops there: demanding prose for every Optional member would produce padding rather than documentation. All five are now documented, including why ListModels takes a filter - a public catalogue holds more models than any client wants to page through, so a Method that could only return everything would be unusable against exactly the sources clause 8 exists to reach. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Make the document read as a statement of the model, not its history Five changes, none of which alter what the model can do. The NodeId space had gaps at 6036, 6042 and 6104..6106 - residue of two members that moved to a base type and three placeholders that narrowed nothing - and the generator explained them with comments like "6036 held JobId, now inherited". A reader implementing this today should not be able to tell any of that happened. The model is unpublished, so the ids are now contiguous: 6001..6145, 145 members, none lost. The diff against the previous commit is a deliberate full renumber rather than the usual 0-moved. 1.2 "Why this is a separate specification" is gone. Its third paragraph duplicated 4.2 outright, its second defended the document existing, and only the first said anything about the model - which is now in 1.1 where the motivation lives. 1.3 also carried two bullets that both said training is out of scope. 11.1.1 was titled "The chain has more links than it used to", which is a changelog sentence in a heading. It says what the chain is. Five flows had no diagram: a call and what comes back, async submit and subscribe, the far end failing and a fallback answering, federate vs stage with the digest gate, and the provenance walk. Every arrow direction was checked against the generator's ReferenceType definitions rather than against intuition, because the last review found both arrows in the overview figure drawn backwards against their own. Annex D deploys an ONNX gearbox classifier end to end. Clause 7 had acquired some vocabulary from generative models - a capability called chat, accounting that is often tokens - while what industry runs is a fixed-shape tensor model executed in-process. The annex shows the same envelope carries it with nothing bent: tensor signatures as the entire interface description, a staging import with the digest verified, usage metered in samples rather than tokens, and Capabilities naming no chat capability at all - an absence that means nothing, because the list is open so a deployment describes what it does instead of scoring itself against a menu. It also says why no tensor wire format is standardised: raw buffers, protobuf, Arrow and npy are each right somewhere, and a Server already speaking one to its runtime should not transcode into a format chosen here. ContentType names which is in use, which is what a client needs. Plus a table of contents, 69 entries, all resolving. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Retitle: AI Model Management and Inference "AI Deployment and Learning" named two of thirteen clauses. The document also covers what a model is, calling it, calling one hosted elsewhere, the catalogue and bridge, and governance and provenance. Management carries the catalogue, import, lifecycle and governance; Inference carries the call, which is the largest clause and the first thing an implementer reaches for. The type system was already name-neutral, so almost nothing in the model changes. The namespace stays http://opcfoundation.org/UA/AI/ - it was never named for the old title, and changing it would invalidate every RequiredModel pin and every overlay reference for nothing. AiRootType, AiJobType, AiResourceType and the AI-* facets are all prefixed Ai, not AiDeployment, so they stand. Exactly one identifier carried the old title: the well-known browse entry point. AiDeployment becomes AiModelManagement, which is a BrowseName change - NodeId 7001 does not move. The CSV diff is 0 moved, with that one symbolic name replaced and nothing else touched. Folders moved with git mv so history follows the document rather than showing a delete and an add. The riskiest part was not the rename but what reaches into this tree by path: both Vision generators, the Vision validator, validate_all.py, the tree README and sixteen references in the Vision specification. A missed path there would not have failed loudly - the Vision validator returns empty sets when the AI NodeSet is absent and then passes - so AI_TYPE_ID was checked to be populated rather than inferring it from a green run. It resolves 42 types and 208 ids. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Address PR #49 review feedback Headings stated conclusions instead of naming topics, so a reader scanning the contents met forty arguments rather than a structure. Forty-three are now topic names - "Provenance", "Lineage", "Version binding", "Data residency and egress" - and every statement a heading was carrying has been restored as the opening sentence of the clause it belonged to, so nothing was lost in demoting them. The information model sections read as clipped one-liners. 5.2, 5.3 and 5.4 now open by saying what the type is for, who reads it and when, and the member descriptions say what each is needed for rather than only what it holds. The 5.4.1 table literally prefixed a "The question" column before each answer; it is prose now. 5.4.2 compared State with Reachability, which clause 8 does not introduce until much later - the reader met a comparison against something undefined. It now describes State on its own terms, including why Degraded sits between Active and Faulted, and defers the combination to 8.4 where the other half exists. "The bridge" was doing two jobs. A Server reaches an external AI system either by calling one per request (clause 8) or by obtaining a model from a catalogue once (clause 9), and both get called bridging. 9.2 now separates them before defining the import job, and the clause is titled "The catalogue and model import". "A card that lists only what a model can do is marketing" was polemic for a specification; it now says the same thing about behaviour and commissioning without the jab. The decision record explaining why this was a separate specification was already removed in an earlier commit; the section is gone rather than rewritten, since a standalone document does not argue for its own existence. Contents regenerated for the renamed headings: 69 entries, all resolving. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Address PR #49 review feedback: payload size and scenarios Invoke carried its payload as a ByteString, which is bounded three times over - by MaxByteStringLength, by the negotiated MaxMessageSize and by the Session's MaxResponseMessageSize - none of which this model gets to choose. An image, a point cloud or a window of high-rate samples exceeds them routinely, so the one call the specification defined could not carry the input it was defined for. Invoke is now the shortcut and BeginTransfer is the general path. InferenceTransferType carries one chunked exchange whose Request and Response are Part 5 FileType objects, so a client opens, writes or reads in chunks of its own choosing, and closes. Nothing here invents a transfer protocol: OPC UA already has one, every client implements it, and a bespoke chunking scheme would be a second thing to get wrong. MaxInlinePayloadSize is Mandatory and says the bound before a client calls rather than after a rejection, because the three limits above are not all visible from the client side and the smallest of them is the real one. Clients that do not know their payload sizes in advance are told to start with the transfer path. The awkward case is not a large request - a client knows its own input - but a request that fits producing a response that does not. Invoke returns TransferRequired and Transfer for that, and a Server shall NOT fail the call: the inference already ran, and failing would discard the work and tell the caller nothing, leaving it to read an empty payload and conclude the model returned nothing. Streaming stays where it was. A transfer delivers one complete response however large; 8.5 covers output a client wants as it forms, over a Subscription or optionally a data channel. Clause 4 Scenarios is new, and informative: eight arrangements this specification supports, each with the flow that realises it, so a reader can find the one resembling their installation before reading the normative clauses that define its parts. They are not alternatives - a plant running a model locally, calling a hosted one for a second opinion and importing both from a catalogue is doing three at once. Clauses 5 to 14 shift by one to make room. Every clause reference was re-checked by hand rather than trusting the section-ref gate, which resolves a bare reference against any cited document and would not have caught a stale one. 0 NodeIds moved; 22 added. * Show how the AI model maps onto the systems people actually integrate (#54) * Add vendor implementation guides for the AI Model Management specification The specification names ApiDialectEnum literals for what a contract does rather than for whoever published it first, because a literal in a standard should not be an advertisement. That is right for the normative document and leaves an implementer holding a question it does not answer: they are not integrating a REST chat-completions contract, they are integrating Azure AI Foundry, or Bedrock, or the Triton server already in the plant. Eleven informative guides under extras, one per system, each with the same nine sections so the index's coverage table means something. The ninth - what this system does not tell you - is the one worth reading first; a mapping document that lists only what maps is marketing. Two findings the set makes hard to avoid noticing. No hosted inference platform in it exposes an artefact digest. Not Foundry, OpenAI, Bedrock, SageMaker, NIM, Triton or Vertex. Identity everywhere is a name string. Hugging Face is the only content-addressed system here and it serves no inference. So Digest stays empty against a hosted endpoint, a Pinned deployment is pinned to a NAME with the provider's policy rather than a hash holding it still, and the Stage import mode is the only path in the set that ends with a digest the Server computed itself. AuthenticationKindEnum cannot express AWS SigV4. The guides map it by what is STORED, which is what makes the member answerable across systems whose handshakes have nothing in common: an IAM role is WorkloadIdentity because no secret exists anywhere, static access keys are ApiKey. Whether the enumeration should gain a literal is a separate decision - it would be a NodeSet change - and is not taken here. validate_examples.py re-derives from the NodeSet and the specification, never from the guides, and is wired into validate_all.py because a validator outside the aggregate silently stops running. It checks that cited members exist, that every dialect and authentication literal is exercised, that conformance units are real, that each guide links the specification by relative path - which is also what makes a bare section reference resolve, metaverse-specs being a strict tree - and that the index agrees with the guides. It earned its place twice while being written: it found that no guide covered OpcUaInference, which is why there is now one for federating to another Server implementing this specification, and it caught a member this author had cited as ImportMode when the model calls it Mode. Mutation-tested against all five checks. No model file is touched: no NodeSet, no NodeIds CSV, no generator, so no version bump. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Correct the vendor guides against an audit of all eleven Nine of the guides were written by sub-agents and only spot-checked. A three-way audit against the sanctioned research and the specification found errors in every category the audit looked for, including in the two documents the lead wrote. Conformance claims that were simply wrong: AI-OffServer requires EndpointUri to name an authenticated, confidential scheme. The NIM, Triton and KServe guides all claimed it while showing a plain http:// listener as the default - which is the ordinary way a self-hosted inference server sits on a plant network, so this was wrong in exactly the case a reader would be in. AI-Import requires AI-Catalogue; an import job with nothing to import from is not implementable. SageMaker and Triton claimed AI-Import from S3 URIs and a model repository respectively, neither of which is a catalogue that declares a digest to verify against. The federation guide claimed every conformance unit an upstream Server implements is reachable through the link. A conformance unit describes what THIS Server exposes; reaching a Server with a catalogue does not give this Server AI-Catalogue, mirroring it does. Rewritten as three lists by what the downstream Server actually has to build. Model errors: ApiDialect is Mandatory, and the Hugging Face guide left it empty on the grounds that a catalogue speaks no inference contract. True, and not available: it is Proprietary with EndpointDescriptionUri doing the work, and the guide now says the cleaner arrangement is to model the Hub as a ModelRegistryType under clause 10 rather than bending a ModelSourceType around it. AI-Invoke requires ModelUsed populated on every response, so the federation guide's suggestion that a downstream Server may return null when it cannot resolve the upstream model was not one of the options. It publishes a ModelType for the substitute or it fails the call. RateLimit.RetryAfter is a Duration; Retry-After carries seconds or an HTTP date. Converted, not copied. Citations: ModelUsed is 8.2.1 and not 8.5, which is Incremental results; the payload bound and the transfer path are 8.2.4 and not the whole of 8.2. The index attributed the digest rules to clause 11 when 12.1 states them, and asserted a shall-not the specification does not contain - what 12.1 actually requires is that a Server populate Digest where the artefact is obtainable through ArtifactUri, which for a hosted model it is not. Unsupported vendor facts, removed rather than softened: ONNX file metadata fields, GGUF header contents, Triton's storage backends and repository-management extension, and Retry-After attributed to specific platforms rather than to HTTP. Triton's dialect split was a transport split. Clause 9.2 names the literals for the contract, and Triton serves OIP over both HTTP and gRPC, so both are OpenInferenceProtocol. TensorRemoteProcedure stays, described as what it is for. The index also called Hugging Face the only exception to no artefact digest, omitting embedded runtimes - the one arrangement in the set where the digest is something the Server computed rather than was told. Comparative praise replaced with description throughout. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Restore the blank line before a heading in the federation guide Lost while rewriting the catalogue section for the conformance-unit audit. MD022, and the only markdownlint finding across the set. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Releases 0.3.0 and 0.4.0: what eleven real systems taught the AI specification (#55) * Integrate what the vendor mappings taught the AI specification Mapping one information model onto eleven real systems was a natural experiment, and it found places where the model was unsatisfiable, unguarded or ambiguous. None of them needs a NodeSet change. AI-Invoke was unsatisfiable for every non-language model. The facet required Usage "populated on every response" while no clause imposed that obligation, and "empty" was unencodable: the three counts are UInt64 and the model declares no optional fields, so leaving them empty encodes as zero, indistinguishable from a metered zero. Five guides claimed the facet while documenting empty Usage. 8.2.3 now makes an empty UnitKind the not-metered sentinel, with the counts set to zero and clients forbidden from reading them as measurements. The unit carries the sentinel because the counts cannot. Residency did not compose across a federation hop. A payload leaves a deployment along exactly two modelled edges, FallsBackTo and Source, and only the first was guarded; EgressPermitted's only shall binds on InferenceLocation Cloud, so a cell-to-site EdgeOffServer hop escaped it. 9.5 states the members are end-to-end rather than next-hop, and obliges a Server federating to a peer to read its declarations and never publish anything more permissive, defaulting fail-safe where it cannot read them. This is the rule 12.3.2 already states for the other edge. Clause 13.1 described a plant MLOps node that "may never call Invoke at all" while AI-Base required at least one deployment. The facet's deployment requirements are now conditional on the Server exposing one. AI-OffServer cites 12.2's scheme requirement instead of restating it, so the two cannot drift. Three ambiguities are resolved where the guides had each invented an answer. ModelId carries the source's identifier verbatim, and Publisher names who produced the model rather than who serves it -- two Servers were reading owned_by into Publisher and publishing "azure" for a model Meta trained. AuthenticationKind classifies what is stored rather than the handshake performed, which is what makes SigV4 answerable without a new literal. ApiDialect classifies the contract this Server speaks, and a catalogue-only source is Proprietary with an EndpointDescriptionUri -- correct, not a shortcoming. The eleven guides are updated to cite these rules rather than derive them, and three that had softened 12.2's shall into an operator choice are corrected. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Release 0.3.0: state why a digest is absent, and reach a registry from an import Three changes the vendor mappings argued for that prose alone could not make. All three append; NodeId churn is 0 changed, 0 removed, 5 added. DigestProvenanceEnum, Mandatory on ModelType and Optional on ModelResourceType. Digest is Mandatory so that its absence is uniform and browsable, and that stays right -- seven of eleven systems cannot fill it, and Optional would make "no digest" indistinguishable from "does not implement digests". But empty then carried two meanings and populated carried three, and the missing answer was doing visible harm: five guides each prohibited a DIFFERENT wrong value -- a response fingerprint, a resource name, a storage entity tag, a manifest hash, a commit identifier -- and none could say what to publish instead. 12.1.1 states the prohibition once and supplies NotAvailable. Mandatory for the reason Digest is, which 6.2 already gives: clause 12 depends on it, and a rule that depends on an Optional member is one a conformant Server can silently not satisfy. A StatusCode cannot carry it -- DeclaredBySource and VerifiedOnStage are both Good. 12.1.1 also states that provenance does not strengthen by being forwarded, on the ordering NotAvailable < DeclaredBySource < ComputedByServer < VerifiedOnStage. Republishing an upstream peer's VerifiedOnStage would claim a check this Server did not perform, and the claim would be indistinguishable from one it had. Same composition argument as 9.5 residency, applied to the other thing a federated deployment forwards. ModelImportJobType.Registry, with 10.2 requiring exactly one of Source and Registry non-null. Source was Mandatory and typed ModelSourceType, so nothing connected an import job to a ModelRegistryType -- the edge the 4.4 and 5.1 diagrams draw. A Server importing from a catalogue had to invent a source wrapper around its own registry. Source keeps its Mandatory rule and takes null on the registry path, the idiom TargetDeployment already uses, so no existing member changes. ModelType.Name is constrained rather than retyped: its Text shall be the source's name carried across unchanged, translations may be added for display, and the Text is not reformatted. Retyping to String would have been cleaner and is breaking; the property wanted -- two Servers fetching one model from two mirrors produce the same string -- is obtainable by constraining the field. Version and PublicationDate bump to 0.3.0 / 2026-08-05, picked up by the vision overlays automatically because build_examples.py derives both from the AI generator rather than pinning them. The eleven guides state their DigestProvenance value and cite 12.1.1 instead of each re-arguing the prohibition. The index reads the member as the axis the set varies along: evidence tracks custody, which is why an embedded runtime -- a local file the Server can simply hash -- is the one arrangement here that produces evidence without vendor cooperation. Adds CHANGELOG.md, where this repository keeps release history so the specification does not have to narrate it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Stop sending a homeless identifier to a member that cannot hold it 12.1.1 correctly forbids a non-content identifier in Digest and then disposed of it into ArtifactUri or ProvenanceUri. Those are scalar String Properties on ModelType -- one artefact, one value. A serving configuration fingerprint is per-response and per-deployment, so the disposition is unimplementable for the case it was most needed in, and five guides were left telling an implementer not to publish a value the specification had just promised a home for. The narrowed rule says what is true: an identifier that LOCATES the artefact or its provenance record belongs in those members, and one that identifies something else has no member in this model. Recording that a datum has no home is better than filing it where a client reads it as an artefact digest. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1dab1302-19c5-4a9b-a50c-d97d389713aa * Release 0.4.0: model what eleven real systems publish and this had no member for The same eleven mappings, read with a different question. 0.3.0 asked which rules were wrong; this asks what these systems do that the model cannot represent at all. The answer had a consistent signature: a guide NAMES a vendor field and then maps it nowhere, and the omission is invisible because nothing is missing from the guide's own tables. Twelve appended Properties, no new DataTypes. NodeId churn is 0 changed, 0 removed, 12 added. A model had no time on it. Six of eleven return a vintage in the call a Server populates ModelType from, and every guide dropped it. The asymmetry made it plain: DatasetType.CreatedAt exists with 6.3 defending it, and a catalogue resource inherits CreatedAt/ModifiedAt from xRegistry, so a model known through a ca…
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Extracts the AI cluster out of OPC UA — Vision into a standalone specification, OPC UA — AI Model Management and Inference, and grows it into a model a Server can actually use rather than only describe.
Stacked on #47 — review that first, or read this diff against
robot-intent-spec. (#50 was squash-merged into this branch, so the AI work now lives here.)The three questions this answers
ModelType,DatasetType, the provenance chain (§6, §12)Invoke/InvokeAsynconDeploymentType(§8)ModelSourceType,FallbackPolicy, data residency (§9)Vision
The AI cluster leaves, joined back by a facet precondition rather than a
RequiredModel—InferencePipelineType.Deploymentwas already a plainNodeId, so a Server publishing cameras and verdicts without ever naming a model stays conformant toVIS-Base.Vision also gains
MechanicalInterface, fixing a defect the review found: its own eye-in-hand example labelled the flangeTooland contained no TCP at all, reproducing exactly the failure §5.8 warns about. The frame-role enumeration now agrees literal-for-literal with Robot Intent's, and both specs gain a mutual interop annex.The invariant clause 8 is built on
Not an aspiration — serving runtimes that run on a workstation and the hosted services they mirror already expose the same contract, differing only in addressing and authentication. The location changes the trust boundary and the latency, and nothing else.
The payload stays opaque; the envelope is fixed.
ModelUsedreports the model that actually answered, because a fallback or a followed reference moves it between the call and the read — making the deployment's current model wrong in the direction that looks plausible.What no vendor API models
FallbackPolicy— what the line does when the WAN drops, which an inference API can leave unanswered because it assumes its caller will wait.DataJurisdiction/EgressPermitted/RetainsInput— where the data goes, which encryption does not answer. And digest verification at the moment of staging, the one point where a substituted artefact enters.Vendor neutrality
A commercial AI platform's API surface was researched and is named nowhere. Only convergent practice was adopted — the
(publisher, name, version)triple, usage accounting, a finish reason, retry-after. Rejected: resource-manager URL patterns, vendor request-id headers, SKU strings, geography concepts. Version pinning is modelled structurally (immutable id vs mutable ref, as xRegistry does) rather than as a vendor upgrade-policy enum.Costs, stated plainly
ns=2. The dependency does not reach consuming specifications.Verification
Determinism byte-identical; all three tree validators, links, section refs and YAML/JSON green. Both validators now cross-check specification against model in both directions, which found 17 real gaps including a clause titled "The three purposes" against a four-literal enumeration.
Every validator addition is mutation-tested, including negative controls that must not fire. Guards cover: BrowseName namespace indices, xRegistry placeholder overriding, domain neutrality, Mandatory-member documentation, and the Part 10 job base.
Review feedback
All eleven threads addressed and resolved. Two were structural. 43 headings stated conclusions instead of naming topics, and each statement was restored as the opening sentence of its clause rather than discarded. And
Invoke'sByteStringpayload was bounded by limits this model does not choose, soBeginTransferandInferenceTransferTypenow carry large payloads over Part 5FileType-Invokeis the shortcut, the transfer path is the general one, and a response that outgrows the inline bound reportsTransferRequiredrather than failing work that has already run.A new informative clause 4 Scenarios gives eight supported arrangements, each with the flow that realises it, as a way into the normative clauses rather than a summary of them.
Since this description was written
Two things landed on this branch after the text above: PR #54 (squashed as
db79897), which itself carried PR #55, and a merge of therobot-intent-specbase.Eleven implementation guides, and what they taught the specification
metaverse-specs/extras/ai-model-management/examples/maps this model onto Microsoft Foundry, OpenAI, Bedrock, SageMaker, Vertex AI, NVIDIA NIM, NVIDIA Triton, KServe OIP, Hugging Face, embedded runtimes, and a peer OPC UA Server. They are informative, gated byvalidate_examples.py, and they turned out to be a natural experiment — a rule no real system can satisfy shows up as a mapping that cannot be written honestly.Release 0.3.0 fixed what the experiment showed was wrong:
AI-Invokewas unsatisfiable for every non-language model (Usagewas required on every response while no clause imposed it, and "empty" was unencodable); residency did not compose across a federation hop; clause 13.1 promised a Server shape 13.2 forbade; andPublisher,ModelId,AuthenticationKindandApiDialectwere each answering two questions. AddedDigestProvenanceEnumandModelImportJobType.Registry.Release 0.4.0 fixed what the model could not represent: model vintage and retirement dates, a large-payload path for asynchronous inference, a deployment's own payload contract, and serving-runtime identity — twelve appended Properties and three Method signature changes. Three defects found by reading the specification against itself came with it, including a
Degradedstate transition whose comparison input was not modelled.Profiles
Clause 13 (AI) and clause 12 (Robot Intent) have been titled "Profiles and conformance units" since 0.1.0 while defining only facets. Both now define four profiles and their URIs, with terminology entries for conformance unit, facet and profile that neither document had.
The base merge
robot-intent-specbrought the defects found by implementing Robot Intent in the OPC UA .NET Standard stack. The only conflict was both sides appending to that spec'sUnreleasedchangelog; both are kept. EveryRI-facet name the new profiles bundle was re-checked against the merged facet table, and all three generators rebuild byte-identical.The root README, and the release tool
README.mdexplained how to contribute well and what exists badly: the inventory was a list of single-paragraph bullets — the Data Channels one ran to ~1,900 characters — with no version, no status and no link to any specification document. It is now one table per folder prefix (core, cloud, metaverse, wot, companion) covering this repository and the privatespec-draftssubmodule together, each row giving what the specification is, why it exists, its status, and[Specification](.md) · [Word](.docx).Grouping by prefix is what makes wot visible at all: both its specifications are under OPC Foundation review and the tree has physically left, so a prefix-grouped list is the only place a reader learns they exist.
release/tools/release_spec.pymaintains that README — when a specification moves private it capsules the describing item with the original base64-encoded so a return restores it byte-for-byte. It understood list items and links, not table rows, so it gainedrepair_markdown_table_rows_release. It runs before the link pass (afterwards every row already holds a capsule and would be skipped), preserves the row's cell count (MD056), and only touches tables whose last two columns are Status and Documents. Round trips were verified across six specifications in four trees.Second base merge — reconciling two ways to declare conformance
robot-intent-specthen broughtIntentCapabilitiesType.SupportedFacets, which collided semantically with the profiles above: both are ways of declaring conformance, and left as two independent shalls they would be two sources of truth for one fact.They are not, and granularity is what separates them.
SupportedFacetsis onIntentCapabilitiesType, so it is stated per controller — a Server hosting two robots of different capability has two answers.ServerProfileArrayis on the Server object, so it is stated once per Server, which is the right level for a profile. §12.2 now says so, and requires the two to agree where both are published. Upstream had already reached for the same precedent, citingServerCapabilitiesType.ServerProfileArrayas whatSupportedFacetsmirrors.§12.3 adds that claiming a profile claims every facet in it on §12.2's terms — structural requirements a client checks by reading, behavioural ones the Server attests to under clause 9 — so a profile is a shorter way to say the same thing, not a weaker one.
Upstream added that Mandatory member without a changelog entry, so the merge records it in the terms of its own commit message; a Mandatory addition going unrecorded beside a prose-only change that is recorded would misrepresent the release.
All 31 facet names the profiles bundle were re-checked against the rewritten facet table, the generator rebuilds to 259 nodes with
SupportedFacetsati=6139and nothing renumbered, and all nine CI checks pass.