Lexicon Reference
Lexicon identifiers under the network.tulpa namespace fall into two groups, and the difference matters: the wire messages below are INK protocol, and the repository records above them are not.
Deployment records
These are AT Protocol record schemas one deployment (Tulpa) defined for its own use. None of them is INK protocol. No INK specification references one, no conformance category covers one and an implementation MUST NOT require one of a counterparty. Identity in INK is rooted in key material, never in a record fetched from a repository. See Identity & Binding.
| Lexicon ID | Description |
|---|---|
network.tulpa.agentLink | Owner-linkage record naming an agent and its key material. One optional pipeline for the advisory owner signal |
network.tulpa.focusSignal | Status signal a deployment publishes about its own user |
network.tulpa.connection | Connection record one deployment keeps for its own relationship state |
network.tulpa.autonomyPolicy | Agent autonomy configuration. See Autonomy & Policy |
network.tulpa.trustAttestation | Reputation claim a deployment stores locally. INK defines no reputation mechanism, and a receiver is under no obligation to accept one |
INK Wire Messages
These lexicons define INK protocol messages transmitted via HTTPS.
The paths below are the reference deployment’s spelling, not part of the protocol. INK reserves no inbound path: a receiver publishes the one it serves as the endpoint of its Agent Card, and that path is what a sender signs into the signature base. The exception is the card discovery path, GET <base>/ink/v1/<agentId>/agent.json, which is pinned because a sender has to reach the card first.
| Lexicon ID | Wire Type | Example endpoint |
|---|---|---|
network.tulpa.ink.intent | network.tulpa.intent | POST /ink/v1/intent |
network.tulpa.ink.challenge | network.tulpa.challenge | POST /ink/v1/challenge |
network.tulpa.ink.rejection | network.tulpa.rejection | POST /ink/v1/rejection |
network.tulpa.ink.resolution | network.tulpa.resolution | POST /ink/v1/resolution |
network.tulpa.ink.encrypted | network.tulpa.encrypted | POST /ink/v1/intent |
network.tulpa.ink.receipt | network.tulpa.receipt | POST /ink/v1/receipt |
network.tulpa.ink.auditQuery | network.tulpa.audit_query | POST /ink/v1/audit |
network.tulpa.ink.auditResponse | network.tulpa.audit_response | Response to audit query |
network.tulpa.ink.auditSubmit | network.tulpa.audit_submit | POST /ink/v1/audit/submit |
network.tulpa.ink.auditInclusion | network.tulpa.audit_inclusion | Response to audit submit |
This table covers the lexicon-mapped subset. The full set of registered suffixes, including the card-query, key-rotation, discovery and authorization types, is in ink-protocol.md §6, which is the authority. Build a router from that registry.
The intent envelope has no type field. The network.tulpa.intent entry is a registered §6 suffix, but an intent message carries the action in its intent field rather than stamping a type. Only protocol messages carry a type.
Every registered suffix except two also has a network.ink. spelling that a conforming receiver MUST accept. See Wire Types for the dual-accept rule, the two exclusions and the naming convention.