INPUT-LD v0.1.0

The first functional LD profile — extending CORE-LD with input semantics for representing requests, intents, parameters, constraints, and context.

Status: Draft Extends: CORE-LD v0.1.0 Constitutional dependencies: URS v0.1.0 → CORE-LD v0.1.0 Spec family: Functional Profile (see CORE-LD §6.1 — Composition Rules) Dimension registry prefix: INPUT-LD Canonical @context: https://specs.initialcore.net/ns/input-ld.jsonld

1. Preamble

INPUT-LD is the first functional profile extending CORE-LD. It defines how requests, intents, parameters, constraints, and context are expressed as CORE-LD entities with standardised input semantics.

What INPUT-LD is:

A set of entity types and properties specialised for representing inputs
A request/intent model: what is being asked, with what parameters, under what constraints, in what context
A standard envelope for any system that receives structured input from an external actor

What INPUT-LD is not:

Not a protocol — INPUT-LD defines representation, not transport
Not an API specification — it defines the semantic payload, not the endpoint contract
Not a replacement for CORE-LD — INPUT-LD inherits all CORE-LD invariants and adds its own

1.1 Composition rule

INPUT-LD = CORE-LD + Request + Intent + Parameter + Constraint + InputContext

Any conforming INPUT-LD implementation MUST also conform to CORE-LD at the same conformance level. An encoded INPUT-LD binding (e.g., JSON-INPUT-LD) MUST preserve both CORE-LD and INPUT-LD invariants.

2. Entity Types

INPUT-LD extends the CORE-LD kind set with the following entity types:

2.1 Request

A Request represents a structured invocation — an intent to cause some computation, retrieval, or transformation.

{
  "@context": "https://specs.initialcore.net/ns/input-ld.jsonld",
  "@id": "_:req1",
  "@type": "Request",
  "intent": "query",
  "target": "_:resource1",
  "parameters": [ ... ],
  "constraints": [ ... ],
  "context": { ... }
}

Property	Type	Required	Description
`intent`	String	Yes	The purpose: `query`, `mutate`, `invoke`, `observe`, `delegate`
`target`	Entity ref	Yes	The entity or resource this request acts upon
`parameters`	Array of Parameter	No	Named values configuring the request
`constraints`	Array of Constraint	No	Constraints governing the request
`context`	InputContext object	No	Surrounding context for the request

2.2 Intent

An Intent captures the semantic purpose of a Request — what the requesting actor fundamentally wants, independent of how it is achieved.

{
  "@id": "_:int1",
  "@type": "Intent",
  "purpose": "retrieve",
  "domain": "identity",
  "priority": "high"
}

Registered intent purposes:

Purpose	Meaning
`query`	Retrieve information without side effects
`mutate`	Create, update, or delete state
`invoke`	Trigger a computation or action
`observe`	Monitor, watch, or subscribe
`delegate`	Forward to another system for handling

Registered intent domains: identity, representation, governance, storage, memory, reasoning, trust, agent, workflow, generic

2.3 Parameter

A named input value providing configuration for a request.

{
  "@id": "_:p1",
  "@type": "Parameter",
  "name": "maxResults",
  "value": 100,
  "type": "integer"
}

Property	Type	Required	Description
`name`	String	Yes	Parameter name (CORE-LD @context-defined term or extension)
`value`	Any	Yes	Parameter value
`type`	String	No	Semantic type hint (`integer`, `string`, `iri`, `entity`, `boolean`, `dateTime`)

2.4 Constraint

A restriction on what constitutes a valid response or execution of a request.

{
  "@id": "_:c1",
  "@type": "Constraint",
  "field": "provenance.Representer",
  "operator": "equals",
  "value": "did:icore:admin"
}

Property	Type	Required	Description
`field`	String	Yes	Path expression identifying the constrained field
`operator`	String	Yes	Constraint operator
`value`	Any	Yes	Constraint value
`severity`	String	No	`required` (default), `preferred`, `forbidden`

Registered constraint operators: equals, notEquals, greaterThan, lessThan, in, notIn, contains, matches, exists, notExists

2.5 InputContext

Surrounding context that frames a request — who is asking, from where, with what state.

{
  "session": "_:session1",
  "actor": "did:icore:user:alice",
  "channel": "studio.initialcore.net",
  "workflow": "spec-design",
  "state": "review"
}

Property	Type	Required	Description
`session`	Entity ref	No	Reference to a Session entity
`actor`	IRI	Yes	DID or IRI identifying the requesting actor
`channel`	String	No	Originating channel or surface
`workflow`	String	No	Workflow identifier if request is part of a process
`state`	String	No	Current state within the workflow

3. Request Lifecycle

A Request entity traces through a defined lifecycle. Implementations MAY represent the lifecycle state explicitly.

Draft → Submitted → Received → Accepted → Rejected → Processing → Completed → Failed → Responded

State	Meaning
`Draft`	Being composed, not yet submitted
`Submitted`	Sent by the requesting actor
`Received`	Acknowledged by the processing system
`Accepted`	Determined valid and actionable
`Rejected`	Determined invalid or impossible
`Processing`	Work is underway
`Completed`	Work finished successfully
`Failed`	Work finished with error
`Responded`	Output delivered to requesting actor

4. Invariants

INPUT-LD inherits all 23 CORE-LD invariants (I1–I23) as its conformance criteria. The following INPUT-LD-specific invariants are ADDITIONAL:

4.1 Request invariants (I-INPUT-1 through I-INPUT-5)

ID	Invariant	Check
I-INPUT-1	Every Request has an intent	`intent` field present and non-empty
I-INPUT-2	Intent purpose is registered	`purpose` ∈ {query, mutate, invoke, observe, delegate}
I-INPUT-3	Every Request has a target	`target` IRI resolves to an entity in the graph or is a known external resource
I-INPUT-4	Constraint operator is registered	`operator` ∈ {equals, notEquals, greaterThan, lessThan, in, notIn, contains, matches, exists, notExists}
I-INPUT-5	InputContext has an actor	`actor` present when InputContext is provided

4.2 Parameter invariants (I-INPUT-6 through I-INPUT-7)

ID	Invariant	Check
I-INPUT-6	Every Parameter has a name and value	`name` and `value` both present
I-INPUT-7	Parameter name is a defined term	`name` resolves through the active @context

4.3 Constraint invariants (I-INPUT-8 through I-INPUT-10)

ID	Invariant	Check
I-INPUT-8	Every Constraint has field, operator, value	All three present
I-INPUT-9	Constraint severity is valid	`severity` ∈ {required, preferred, forbidden} or absent (defaults to required)
I-INPUT-10	Constraint field path is resolvable	`field` is a dot-separated path that could reference a valid entity property

4.4 Session invariants (I-INPUT-11 through I-INPUT-12)

ID	Invariant	Check
I-INPUT-11	Session entity has start timestamp	Session entity carries `startedAt` timestamp
I-INPUT-12	Session entity has an actor reference	Session entity references an actor via `actor` property

5. INPUT-LD @context Extension

The INPUT-LD @context extends the CORE-LD @context with the following term mappings:

{
  "@context": {
    "Request": "https://specs.initialcore.net/ns/input#Request",
    "Intent": "https://specs.initialcore.net/ns/input#Intent",
    "Parameter": "https://specs.initialcore.net/ns/input#Parameter",
    "Constraint": "https://specs.initialcore.net/ns/input#Constraint",
    "InputContext": "https://specs.initialcore.net/ns/input#InputContext",
    "Session": "https://specs.initialcore.net/ns/input#Session",

    "intent": "https://specs.initialcore.net/ns/input#intent",
    "parameters": {
      "@id": "https://specs.initialcore.net/ns/input#parameters",
      "@container": "@set"
    },
    "constraints": {
      "@id": "https://specs.initialcore.net/ns/input#constraints",
      "@container": "@set"
    },
    "context": "https://specs.initialcore.net/ns/input#context",
    "target": "https://specs.initialcore.net/ns/input#target",
    "purpose": "https://specs.initialcore.net/ns/input#purpose",
    "domain": "https://specs.initialcore.net/ns/input#domain",
    "priority": "https://specs.initialcore.net/ns/input#priority",
    "name": "https://specs.initialcore.net/ns/input#name",
    "value": "https://specs.initialcore.net/ns/input#value",
    "type": "https://specs.initialcore.net/ns/input#type",
    "field": "https://specs.initialcore.net/ns/input#field",
    "operator": "https://specs.initialcore.net/ns/input#operator",
    "severity": "https://specs.initialcore.net/ns/input#severity",
    "channel": "https://specs.initialcore.net/ns/input#channel",
    "workflow": "https://specs.initialcore.net/ns/input#workflow",
    "state": "https://specs.initialcore.net/ns/input#state",
    "session": {
      "@id": "https://specs.initialcore.net/ns/input#session",
      "@type": "@id"
    },
    "actor": {
      "@id": "https://specs.initialcore.net/ns/input#actor",
      "@type": "@id"
    },
    "startedAt": {
      "@id": "https://specs.initialcore.net/ns/input#startedAt",
      "@type": "xsd:dateTime"
    }
  }
}

6. Composition Examples

INPUT-LD composes with CORE-LD as the base. Further composition with encoding and addressing is additive.

6.1 Pure INPUT-LD (abstract graph)

INPUT-LD = CORE-LD + input semantics
Conforms to: CORE-LD (I1–I23) + INPUT-LD (I-INPUT-1 through I-INPUT-12)

6.2 JSON-INPUT-LD

JSON-INPUT-LD = INPUT-LD + JSON encoding
Conforms to: CORE-LD I1–I23 + INPUT-LD I-INPUT-x + JSON deterministic serialization
@context: core-ld.jsonld + input-ld.jsonld

6.3 DAG-JSON-INPUT-LD

DAG-JSON-INPUT-LD = INPUT-LD + JSON + DAG addressing
Adds: canonical hash per URS Canonicalization, content-address invariants C1–C5

7. Conformance

7.1 Implementation requirements

A conforming INPUT-LD implementation MUST: 1. Satisfy all CORE-LD conformance requirements (§9 of CORE-LD) 2. Parse the INPUT-LD @context extension (§5) in addition to the CORE-LD @context 3. Validate all 12 INPUT-LD invariants (I-INPUT-1 through I-INPUT-12) 4. Reject documents that violate any CORE-LD or INPUT-LD invariant 5. Accept any valid CORE-LD document that does not use INPUT-LD entity types as also valid at the CORE-LD level (INPUT-LD is additive, not restrictive)

7.2 Conformance levels

Level	Requirements
L1 Structural	CORE-LD L1 + I-INPUT-1, I-INPUT-3, I-INPUT-6, I-INPUT-8 (basic request shape)
L2 Complete	CORE-LD L2 + all 12 INPUT-LD invariants
L3 Constitutional	CORE-LD L3 + all 12 INPUT-LD invariants + provenance on constitutional requests

8. Examples

8.1 Minimal query request

{
  "@context": [
    "https://specs.initialcore.net/ns/core-ld.jsonld",
    "https://specs.initialcore.net/ns/input-ld.jsonld"
  ],
  "@id": "_:query1",
  "@type": "Request",
  "intent": "query",
  "target": "_:entity1",
  "parameters": [
    { "@id": "_:p1", "@type": "Parameter", "name": "maxResults", "value": 50 }
  ],
  "context": {
    "actor": "did:icore:user:alice",
    "channel": "studio.initialcore.net"
  }
}

8.2 Constrained mutation request

{
  "@context": [
    "https://specs.initialcore.net/ns/core-ld.jsonld",
    "https://specs.initialcore.net/ns/input-ld.jsonld"
  ],
  "@id": "_:mut1",
  "@type": "Request",
  "intent": "mutate",
  "target": "_:entity1",
  "parameters": [
    { "@id": "_:p1", "@type": "Parameter", "name": "name", "value": "UpdatedName" }
  ],
  "constraints": [
    {
      "@id": "_:c1",
      "@type": "Constraint",
      "field": "provenance.Representer",
      "operator": "equals",
      "value": "did:icore:admin",
      "severity": "required"
    }
  ],
  "context": {
    "actor": "did:icore:admin",
    "session": "_:s1",
    "workflow": "entity-update"
  }
}

8.3 Delegate request with explicit provenance

{
  "@context": [
    "https://specs.initialcore.net/ns/core-ld.jsonld",
    "https://specs.initialcore.net/ns/input-ld.jsonld"
  ],
  "@id": "_:del1",
  "@type": "Request",
  "intent": "delegate",
  "target": "_:agent1",
  "parameters": [
    {
      "@id": "_:p1",
      "@type": "Parameter",
      "name": "originalRequest",
      "value": "_:originalReq"
    }
  ],
  "provenance": {
    "Representer": "did:icore:gateway",
    "Timestamp": "2026-07-30T12:00:00Z",
    "Authority": { "authorityType": "granted", "mayDelegate": true },
    "RepresentationContext": "urn:icore:delegation:v1"
  },
  "context": {
    "actor": "did:icore:gateway",
    "channel": "studio.initialcore.net"
  }
}

9. Relationship to Other Profiles

INPUT-LD is the first functional profile and shares the following relationship rules with future profiles:

Profile	Relationship	Rule
MEMORY-LD	INPUT-LD can query MEMORY-LD stores	Requests target memory entities; memory responses are not inputs
POLICY-LD	INPUT-LD carries constraints; POLICY-LD defines valid constraints	Constraint operators registered in a shared registry
TRUST-LD	INPUT-LD requests may carry trust assertions	Trust attestations are parameters, not INPUT-LD entity types

10. Future Considerations

Idempotency tokens: A standard parameter for request deduplication
Pagination parameters: `offset`, `limit`, `cursor` as standard Parameter entries
Request bundling: Multiple requests in a single INPUT-LD document (a "batch" mode)
Structured error responses: Standardised error entity type for response payloads (may belong in a companion OUTPUT-LD profile)

INPUT-LD v0.1.0 — July 30, 2026. Draft. Extends CORE-LD v0.1.0. First functional profile in the DAG--LD specification family.*