{"schema":"thingdaddy.pilot-learning/1","revision":"20261101-learning-r5","reviewedAt":"2026-11-01","audience":"public","status":"LOCAL_CANDIDATE_NOT_AWS_DEPLOYMENT","deploymentEligible":false,"executionAuthorized":false,"identity":{"value":null,"state":"UNASSIGNED","gapCode":"LEARNING_DOCUMENT_ID_NOT_ASSIGNED","recordKeysAreIdentities":false},"distinctions":["source-assertion","existing-issued-identity","private-proposal","inactive-invalid-assertion","identity-gap"],"authority":{"publicationAuthorizesExecution":false,"companyAdoptionAsserted":false,"physicalUnitsVerifiedByGuide":false,"identityIssuancePerformed":false},"pages":[{"key":"learn","path":"/learn","audience":"public","eyebrow":"ThingDaddy · Learn","title":"Give intelligence a physical context.","intro":"Start with the In-Context ID. Connect what a thing is, what it can do, how it works with others, where it operates and the evidence behind every claim.","sections":[{"key":"platform","title":"One platform. Distinct ThingSites.","paragraphs":["ThingDaddy.com is the agent-first identity and five-pillar platform. A ThingSite is a customer-specific deployment of that platform—not merely a company profile or a document folder.","The registry-and-builder journey helps a customer find, inspect and manage its context. It does not give ThingDaddy ownership of a company prefix, allocation authority or permission to operate equipment."],"sourceRefs":["platform-rules","builder-rules"]},{"key":"value","title":"Carry context into every decision.","paragraphs":["An agent should be able to inspect the exact instrument, its driver and limits, the selected protocol and materials, and the governing evidence before proposing a next step. Humans inspect the same distinctions in readable views.","A model name cannot stand in for an installed unit. A convenient picture cannot replace source records, unresolved conflicts or history."],"sourceRefs":["village-vision"]},{"key":"start","title":"A short path through the platform","paragraphs":["Learn the identity model, then follow the five pillars. Detailed village and experiment guidance belongs behind the pilot’s exact access boundary. This local candidate is not an AWS launch announcement."],"sourceRefs":["platform-rules"],"links":[{"href":"/learn/in-context-id","label":"Understand In-Context IDs"},{"href":"/learn/five-pillars","label":"Explore the five pillars"}]}],"diagram":"pillars"},{"key":"in-context-id","path":"/learn/in-context-id","audience":"public","eyebrow":"P1 · The enduring anchor","title":"Name the thing. Preserve its context.","intro":"An In-Context ID uses the applicable standard identity and semantic key type. Meaning comes from attributed records and relationships—not from guessing what an identifier’s characters mean.","sections":[{"key":"role","title":"The role determines the key.","paragraphs":["An individual asset can use a GIAI; a document can use a GDTI; product, serialized-unit and lot contexts use their applicable trade-item representations. A location, component or service relationship keeps its own semantic type.","Keep a protocol family, protocol version and selected configuration as separate document identities. A GSRN service relationship and its SRIN service-instance or run binding do not replace those document versions."],"sourceRefs":["platform-rules","village-vision"]},{"key":"evidence","title":"Identity status is a fact of each record.","paragraphs":["Retained source identifiers, existing issued identities, private proposals, inactive invalid assertions and identity gaps remain distinguishable. Not every displayed ID is a proposal, and a correctly formatted identifier is not proof of a physically verified unit.","Use the exact evidenced prefix and preserve separate prefix records. A regulatory source assertion is not automatically a GS1 licence determination. ThingDaddy may issue governed private proposal IDs under its rules; client validation, adoption and certification are separate states."],"sourceRefs":["builder-rules","village-vision"]},{"key":"bond","title":"Installation adds a relationship—not a replacement.","paragraphs":["Preserve the supplier asset identity, its installed component context and the parent instrument identity. Removal ends a relationship’s active interval; replacement adds a new bond and event. Earlier identities and sources survive.","A URL locates content, a hash binds bytes, and an internal record key addresses storage. None substitutes for an established standard identity. These educational diagrams contain no assigned asset IDs."],"sourceRefs":["builder-rules"]}],"diagram":"bonds"},{"key":"five-pillars","path":"/learn/five-pillars","audience":"public","eyebrow":"The connected solution stack","title":"Five pillars. One accountable system.","intro":"Each pillar adds context to the same exact participants. P5 makes their evidence and relationships traversable; it is more than the picture on a screen.","sections":[{"key":"P1","title":"In-Context Identity","paragraphs":["Which exact thing?","Keep the applicable standard identity, source assertion, vocabulary and assignment state. A model, a physical unit and a proposal are different records."],"sourceRefs":["platform-rules"],"pillar":"P1"},{"key":"P2","title":"Capabilities · MHS/SiLA","paragraphs":["What can it do?","Connect documents, limits, components and MHS/SiLA descriptions, whatever the underlying transport. A description is not a qualified driver."],"sourceRefs":["platform-rules"],"pillar":"P2"},{"key":"P3","title":"Protocols & workflows","paragraphs":["How do things work together?","Reference exact participants, BOM choices, steps and Allotrope model context. Record validation separately from a proposed method."],"sourceRefs":["platform-rules"],"pillar":"P3"},{"key":"P4","title":"Cloud & edge","paragraphs":["Where and under which controls?","Record versioned environment and adapter bindings. Cloud resource names do not replace In-Context IDs; a proposed binding is not a deployment."],"sourceRefs":["platform-rules"],"pillar":"P4"},{"key":"P5","title":"Graph & MCP","paragraphs":["What is the evidence?","Expose P1–P4, relationships, original sources, assessments, conflicts and history to authorized agents and people."],"sourceRefs":["platform-rules"],"pillar":"P5"},{"key":"boundaries","title":"Keep the gates separate.","paragraphs":["Identity assignment, source attribution, compatibility checks, customer adoption, publication, commissioning and physical/cloud execution are different decisions. Publishing a document or resolving an ID does not open the next gate.","Both MHS and SiLA representations are required by ThingDaddy regardless of transport. Held artifacts, interface evidence, software tests and commissioned hardware remain different maturity states.","Allotrope vocabulary/model mapping and structural checks are not automatically formal conformance. AWS SDKs connect to AWS services; native instrument semantics require explicit, tested adapters."],"sourceRefs":["platform-rules","village-vision"]}],"diagram":"pillars"}],"pillars":[{"code":"P1","name":"In-Context Identity","question":"Which exact thing?","description":"Keep the applicable standard identity, source assertion, vocabulary and assignment state. A model, a physical unit and a proposal are different records."},{"code":"P2","name":"Capabilities · MHS/SiLA","question":"What can it do?","description":"Connect documents, limits, components and MHS/SiLA descriptions, whatever the underlying transport. A description is not a qualified driver."},{"code":"P3","name":"Protocols & workflows","question":"How do things work together?","description":"Reference exact participants, BOM choices, steps and Allotrope model context. Record validation separately from a proposed method."},{"code":"P4","name":"Cloud & edge","question":"Where and under which controls?","description":"Record versioned environment and adapter bindings. Cloud resource names do not replace In-Context IDs; a proposed binding is not a deployment."},{"code":"P5","name":"Graph & MCP","question":"What is the evidence?","description":"Expose P1–P4, relationships, original sources, assessments, conflicts and history to authorized agents and people."}],"diagrams":{"pillars":{"kind":"conceptual-not-source-graph","title":"Five pillars, one connected context","description":"P1 identity anchors P2 capabilities, P3 protocols and P4 environment. P5 exposes all of them and their provenance. The drawing illustrates requirements, not verified installations.","labels":["P1 · In-Context Identity","P2 · Capabilities · MHS/SiLA","P3 · Protocols & workflows","P4 · Cloud & edge","P5 · Graph & MCP"]},"bonds":{"kind":"conceptual-not-source-graph","title":"Context connects; identity survives","description":"A supplier asset remains separately identified when linked to an installed component context and a parent instrument. Documents, materials and location retain their own identities. Installation, removal and replacement append history.","labels":["Supplier asset · GIAI","Installed component · CPID","Parent instrument · GIAI","Documents · GDTI","Materials · GTIN context","Location · SGLN"]}},"sources":[{"key":"platform-rules","audience":"public","title":"ThingDaddy connected five-pillar requirements","kind":"project-requirement","revision":"2026-10-30","sha256":"df3ef7a1b3a2903639514117b10b2c14bc1b83a30a7bf89ffcea1b7654f9d479","qualification":"Architecture and policy, not proof of deployed capability."},{"key":"builder-rules","audience":"public","title":"ThingDaddy registry and customer-builder requirements","kind":"project-requirement","revision":"2026-10-30","sha256":"3785b8e9c14ab1adbfe56bf9ac1c47f198d2c1c381c2f71eb7462916edaf2d4b","qualification":"Namespace authority, source preservation and scoped editing requirements."},{"key":"village-vision","audience":"public","title":"Digital civilization vision and identity-bond requirements","kind":"project-requirement","revision":"2026-10-30","sha256":"fb9fdb86346030f9f479be8541ed23b272d8906d8bc9a436c0c2a8f9a5dea131","qualification":"Exact participants and measured feedback; roadmap is not an operational claim."}]}