Skip to content

The connected solution stack

Five pillars. One accountable system.

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.

General introduction · no private company records. Local candidate, not an AWS deployment. Reading or publishing context never authorizes physical execution.

Conceptual map · not source graph data. 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.

Read the diagram as text

P1 · In-Context Identity
P2 · Capabilities · MHS/SiLA
P3 · Protocols & workflows
P4 · Cloud & edge
P5 · Graph & MCP

In-Context Identity

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.

Source and scope

ThingDaddy connected five-pillar requirements · 2026-10-30
Architecture and policy, not proof of deployed capability.
SHA-256: df3ef7a1b3a2903639514117b10b2c14bc1b83a30a7bf89ffcea1b7654f9d479

Capabilities · MHS/SiLA

What can it do?

Connect documents, limits, components and MHS/SiLA descriptions, whatever the underlying transport. A description is not a qualified driver.

Source and scope

ThingDaddy connected five-pillar requirements · 2026-10-30
Architecture and policy, not proof of deployed capability.
SHA-256: df3ef7a1b3a2903639514117b10b2c14bc1b83a30a7bf89ffcea1b7654f9d479

Protocols & workflows

How do things work together?

Reference exact participants, BOM choices, steps and Allotrope model context. Record validation separately from a proposed method.

Source and scope

ThingDaddy connected five-pillar requirements · 2026-10-30
Architecture and policy, not proof of deployed capability.
SHA-256: df3ef7a1b3a2903639514117b10b2c14bc1b83a30a7bf89ffcea1b7654f9d479

Cloud & edge

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.

Source and scope

ThingDaddy connected five-pillar requirements · 2026-10-30
Architecture and policy, not proof of deployed capability.
SHA-256: df3ef7a1b3a2903639514117b10b2c14bc1b83a30a7bf89ffcea1b7654f9d479

Graph & MCP

What is the evidence?

Expose P1–P4, relationships, original sources, assessments, conflicts and history to authorized agents and people.

Source and scope

ThingDaddy connected five-pillar requirements · 2026-10-30
Architecture and policy, not proof of deployed capability.
SHA-256: df3ef7a1b3a2903639514117b10b2c14bc1b83a30a7bf89ffcea1b7654f9d479

Keep the gates separate.

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.

Source and scope

ThingDaddy connected five-pillar requirements · 2026-10-30
Architecture and policy, not proof of deployed capability.
SHA-256: df3ef7a1b3a2903639514117b10b2c14bc1b83a30a7bf89ffcea1b7654f9d479

Digital civilization vision and identity-bond requirements · 2026-10-30
Exact participants and measured feedback; roadmap is not an operational claim.
SHA-256: fb9fdb86346030f9f479be8541ed23b272d8906d8bc9a436c0c2a8f9a5dea131