Separate service relationships, run bindings and document versions

Why this matters

An agent must know which exact configuration a service instance concerns.

Versioning a document must not overwrite a service relationship or turn a file hash into a GS1 identity.

Step by step

1. 01

   Inspect the service relationship

   Screen or control: GSRN · Service relationship

   Why: A relationship identity does not by itself authorize an operator.

   How: Choose GSRN in P1. Record the operator relationship urn, assignment state and source assertion pointer.

   What you should see: The retained GSRN is urn:epc:id:gsrn:0614141.4343434343, non-issued with authority evidence absent.

   Verify: Do not infer employment, competence or execution permission from this record.

2. 02

   Inspect the document identities

   Screen or control: GDTI · Retained assignment · Public package link

   Why: Family, version and configuration documents have separate purposes.

   How: In the GDTI assignment menu inspect configurationGdti and serviceBindingGdti. Open the public package link below to inspect protocolFamilyGdti and candidate_workflow_gdti under P3; those two are not entries in this P1 assignment menu.

   What you should see: Four separate document references remain available through their actual screen and package locations; selecting one does not replace the others.

   Verify: Compare #/P3/protocolTemplates/0 protocolFamilyGdti and candidate_workflow_gdti with #/P1/configurationGdti and #/P1/serviceBindingGdti in package JSON.

3. 03

   Follow the exact version lineage

   Screen or control: Protocol-version focused graph · Original direct relationships

   Why: An explicit version-of edge is stronger than a similar title.

   How: Open the protocol-version graph link and inspect version-of-protocol-family, then open its family destination.

   What you should see: The version urn:epc:id:gdti:0614141.00011.1 points to family urn:epc:id:gdti:0614141.42424.42 through relationship GDTI 00900.9.

   Verify: Record #/P5/edges/8 and keep family/version IDs separate. No version is inferred from the display name.

4. 04

   Inspect the missing run-instance boundary

   Screen or control: Service-binding focused graph · Inspect exact JSON · Public package link

   Why: The binding-document GDTI must not be misreported as an SRIN.

   How: Open the binding graph link and inspect the relationship to the exact configuration. Check the public package for an actual SRIN field; note that none is supplied.

   What you should see: The binding document urn:epc:id:gdti:0614141.00013.1 references configuration urn:epc:id:gdti:0614141.01200.1, but the public record does not assign an SRIN value.

   Verify: Write “SRIN binding value not exposed in this public fixture”. Do not generate an urn:epc:id:srin address or invent a run.

What is happening under the surface

A GSRN addresses a service relationship; SRIN qualifies a particular instance of that relationship using AI 8019. SRIN is not a standalone invented EPC Pure Identity scheme.

The family, exact protocol version, configuration design and service-binding document have separate GDTIs in this sample.

The public anonymous package exposes the binding-document GDTI but does not expose an assigned SRIN value or a service-instance AI 8019 field. Treat that absence as a visible implementation boundary, not a hidden allocation.

Common mistakes

• A GDTI identifying a binding document is not the SRIN itself.
• A configuration hash binds bytes but does not replace a typed document identity.
• One relationship may have many run instances; do not overwrite its GSRN to represent a new run.

The records an agent needs

The graph retains document and service-link structure. For a future authorized run, the SRIN must qualify its parent GSRN and reference the exact configuration; it does not replace either protocol/configuration GDTI. No new key or run is created in this lesson.

Pointers locate records; hashes pin bytes; lesson numbers locate teaching material. None substitutes for an applicable assigned GS1 identity.

Apply what you learned

Produce a five-purpose identity map and mark the missing public run-instance field.

Prepare these outputs

• GSRN, family GDTI, version GDTI, configuration GDTI and binding-document GDTI.
• Two exact directed lineage relationships.
• A distinct row for SRIN purpose with public value not exposed.

Review your work against these checks

• Each identity keeps its own purpose.
• The SRIN row does not contain an invented EPC scheme or number.
• All existing examples remain non-issued, with no recorded experiment execution claimed.

Source and current boundaries

Screen basis: the anonymous public educational fixture at /api/demo/pillars, namespace 0614141. No private company record is read by this course.

Pinned assessed package SHA-256: b06ee255d0943a048511092595db4b98281b9b761d1910d19e6c3dba82591d94. Its complete graph contains 329 nodes and 231 directed relationships; original excluded assertions remain separately retained provenance. Lesson locators are educational numbers, not issued GS1 keys.

Scope: fictional authored records, non-issued identity proposals, unknown authority, no physical command, assay validation, cloud deployment or execution authorization.

Reading, answering a question and opening a diagram do not issue identifiers, validate a scientific method, establish company authority, commission an environment or authorize physical action.