POLICY-LD v0.1.0

The functional LD profile for constitutional constraints, rules, and reasoning — extending CORE-LD with policy semantics for representing permissions, obligations, prohibitions, conditions, and rule evaluation.

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: POLICY-LD Canonical @context: https://specs.initialcore.net/ns/policy-ld.jsonld

1. Preamble

POLICY-LD is the functional profile for constitutional constraints, rules, and reasoning. It defines how permissions, obligations, prohibitions, conditions, and rule evaluation are expressed as CORE-LD entities with standardised policy semantics.

What POLICY-LD is:

A set of entity types and properties specialised for representing policies
A rule model: antecedent → consequence, with support for conflict resolution
A policy evaluation model: how rules are matched, resolved, and applied
A standard envelope for any system that enforces constitutional or operational constraints

What POLICY-LD is not:

Not a logic engine — POLICY-LD defines the representation, not the inference mechanism
Not a legal framework — it defines formal rule structures, not jurisprudence
Not a replacement for CORE-LD — POLICY-LD inherits all CORE-LD invariants and adds its own

1.1 Composition rule

POLICY-LD = CORE-LD + Policy + Rule + Condition + Permission + Obligation + Prohibition + PolicySet + EvaluationReport

Any conforming POLICY-LD implementation MUST also conform to CORE-LD at the same conformance level. An encoded POLICY-LD binding MUST preserve both CORE-LD and POLICY-LD invariants.

1.2 Policy as the reasoning complement

POLICY-LD completes the functional triad with INPUT-LD and MEMORY-LD:

Aspect	INPUT-LD	MEMORY-LD	POLICY-LD
Role	What is asked	What is known	What is permitted
Lifetime	Transient	Persistent	Constitutional
Structure	Imperative	Declarative	Prescriptive
Output	Response	Recall	Decision

INPUT-LD provides the question. MEMORY-LD provides the facts. POLICY-LD provides the rules that determine what should happen.

2. Entity Types

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

2.1 Policy

A Policy is a named collection of rules governing a specific domain or set of entities.

{
  "@context": "https://specs.initialcore.net/ns/policy-ld.jsonld",
  "@id": "_:pol1",
  "@type": "Policy",
  "name": "ConstitutionalUpdatePolicy",
  "description": "Governs who may update constitutional entities",
  "jurisdiction": "urn:icore:governance:v1",
  "rules": [ "_:rule1", "_:rule2" ],
  "conflictStrategy": "deny-overrides",
  "version": "1.0.0"
}

Property	Type	Required	Description
`jurisdiction`	IRI	Yes	The scope within which this policy is effective
`rules`	Array of Entity ref	Yes	References to Rule entities
`conflictStrategy`	String	No	How conflicting rules are resolved
`version`	String	No	Semantic version of the policy
`priority`	Integer	No	Priority when multiple policies apply (higher wins)

Registered conflict strategies:

Strategy	Meaning
`deny-overrides`	Any prohibition outweighs any permission
`permit-overrides`	Any permission outweighs any prohibition
`priority`	Rule with highest numeric priority wins
`first-applicable`	First matching rule in order is applied

2.2 Rule

A Rule is a single conditional statement: when conditions are met, a consequence applies.

{
  "@id": "_:rule1",
  "@type": "Rule",
  "name": "AdminMayUpdateConstitutional",
  "description": "Administrators may update constitutional entities",
  "conditions": [ "_:cond1", "_:cond2" ],
  "consequence": "permit",
  "effect": "_:effect1",
  "priority": 100
}

Property	Type	Required	Description
`conditions`	Array of Entity ref	Yes	Conditions that must all be satisfied
`consequence`	String	Yes	`permit`, `deny`, `obligate`, `waive`
`effect`	Entity ref	No	The action or entity affected by the rule
`priority`	Integer	No	For conflict resolution (default 0)
`immutable`	Boolean	No	If true, rule cannot be overridden

2.3 Condition

A Condition is a Boolean expression evaluated against a request, entity, or state.

{
  "@id": "_:cond1",
  "@type": "Condition",
  "field": "intent",
  "operator": "equals",
  "value": "mutate"
}

Property	Type	Required	Description
`field`	String	Yes	Path expression to the value being tested
`operator`	String	Yes	Comparison operator
`value`	Any	Yes	Value to compare against

Registered condition operators: equals, notEquals, greaterThan, lessThan, in, notIn, contains, matches, exists, notExists, and, or, not

Conditions may be nested (compound conditions using and/or/not operators with a conditions array for sub-conditions).

Compound condition example:

{
  "@id": "_:condCompound",
  "@type": "Condition",
  "operator": "and",
  "conditions": [
    { "@id": "_:condA", "@type": "Condition", "field": "actor", "operator": "in", "value": ["did:icore:admin", "did:icore:moderator"] },
    { "@id": "_:condB", "@type": "Condition", "field": "intent", "operator": "equals", "value": "mutate" }
  ]
}

2.4 Permission

A Permission is a rule whose consequence grants the right to perform an action.

{
  "@id": "_:perm1",
  "@type": "Permission",
  "action": "update",
  "resource": "_:entity1",
  "actor": "did:icore:admin",
  "conditions": [ "_:cond1" ]
}

Property	Type	Required	Description
`action`	String	Yes	The action permitted (`query`, `mutate`, `invoke`, `delegate`, `observe`)
`resource`	Entity ref	Yes	The entity or resource to which the permission applies
`actor`	IRI	No	Specific actor granted the permission (if absent, any actor meeting conditions)
`conditions`	Array of Entity ref	No	Additional conditions that must be met

2.5 Obligation

An Obligation is a rule that requires a specific action to be performed.

{
  "@id": "_:obl1",
  "@type": "Obligation",
  "action": "log",
  "details": "Record all mutation requests for audit",
  "trigger": "on-mutate",
  "deadline": "immediate"
}

Property	Type	Required	Description
`action`	String	Yes	The required action
`details`	String	No	Human-readable description
`trigger`	String	Yes	When the obligation activates
`deadline`	String	No	`immediate`, `before-response`, `within-duration`

2.6 Prohibition

A Prohibition is a rule that forbids a specific action or state.

{
  "@id": "_:pro1",
  "@type": "Prohibition",
  "action": "mutate",
  "resource": "_:constitutionalEntity1",
  "conditions": [ "_:cond1" ]
}

Property	Type	Required	Description
`action`	String	Yes	The forbidden action
`resource`	Entity ref	Yes	The entity or resource protected
`conditions`	Array of Entity ref	No	Conditions under which the prohibition applies

2.7 PolicySet

A PolicySet groups multiple policies—resolving conflicts across them at the set level.

{
  "@id": "_:ps1",
  "@type": "PolicySet",
  "name": "ICoreGovernance",
  "policies": [ "_:pol1", "_:pol2" ],
  "conflictStrategy": "deny-overrides",
  "combiningAlgorithm": "policy-priority"
}

Property	Type	Required	Description
`policies`	Array of Entity ref	Yes	References to Policy entities
`conflictStrategy`	String	No	May override individual policy strategies
`combiningAlgorithm`	String	No	How policy results are combined

Registered combining algorithms: policy-priority, policy-first-applicable, permit-unless-prohibited, deny-unless-permitted

2.8 EvaluationReport

An EvaluationReport captures the result of evaluating a policy against a request or state.

{
  "@id": "_:eval1",
  "@type": "EvaluationReport",
  "request": "_:req1",
  "policy": "_:pol1",
  "decision": "permit",
  "matchedRules": [ "_:rule1" ],
  "obligations": [ "_:obl1" ],
  "timestamp": "2026-07-30T16:00:00Z"
}

Property	Type	Required	Description
`request`	Entity ref	Yes	The request being evaluated
`policy`	Entity ref	Yes	The policy evaluated
`decision`	String	Yes	`permit`, `deny`, `indeterminate`, `not-applicable`
`matchedRules`	Array of Entity ref	No	Rules that matched
`obligations`	Array of Entity ref	No	Obligations triggered by the decision
`prohibitions`	Array of Entity ref	No	Prohibitions that caused denial
`timestamp`	ISO 8601	Yes	When the evaluation occurred

3. Policy Evaluation Lifecycle

Request → Collect Policies → Match Rules → Evaluate Conditions → Resolve Conflicts → Render Decision

Step	Description
1. Collect	Gather all policies whose jurisdiction covers the request
2. Match	Identify rules whose conditions match the request context
3. Evaluate	Test each condition against the request entity and available context
4. Resolve	Apply conflict strategy when rules produce contradictory consequences
5. Decide	Produce final decision: permit, deny, obligate, or combination

4. Invariants

POLICY-LD inherits all 23 CORE-LD invariants (I1–I23). The following POLICY-LD-specific invariants are ADDITIONAL:

4.1 Policy invariants (I-POL-1 through I-POL-4)

ID	Invariant	Check
I-POL-1	Every Policy has a jurisdiction	`jurisdiction` IRI present and non-empty
I-POL-2	Policy contains at least one rule	`rules` array present with at least one entry
I-POL-3	Conflict strategy is registered	`conflictStrategy` ∈ {deny-overrides, permit-overrides, priority, first-applicable} or absent
I-POL-4	Policy rules are resolvable	Every entry in `rules` resolves to a Rule entity

4.2 Rule invariants (I-POL-5 through I-POL-8)

ID	Invariant	Check
I-POL-5	Every Rule has a consequence	`consequence` ∈ {permit, deny, obligate, waive}
I-POL-6	Rule has at least one condition	`conditions` array present and non-empty
I-POL-7	Rule conditions are resolvable	Every entry in `conditions` resolves to a Condition entity
I-POL-8	Immutable rules cannot reference mutable resources	If `immutable: true`, `effect` targets a constitutional entity

4.3 Condition invariants (I-POL-9 through I-POL-11)

ID	Invariant	Check
I-POL-9	Every Condition has an operator	`operator` present and non-empty
I-POL-10	Condition operator is registered	`operator` ∈ {equals, notEquals, ...} ∪ {and, or, not}
I-POL-11	Compound conditions have sub-conditions	If `operator` ∈ {and, or, not}, `conditions` array must be present

4.4 Permission, Obligation, Prohibition invariants (I-POL-12 through I-POL-15)

ID	Invariant	Check
I-POL-12	Every Permission has an action and resource	Both `action` and `resource` present
I-POL-13	Permission action is registered	`action` ∈ {query, mutate, invoke, delegate, observe}
I-POL-14	Every Obligation has an action and trigger	Both `action` and `trigger` present
I-POL-15	Every Prohibition has an action and resource	Both `action` and `resource` present

4.5 Evaluation invariants (I-POL-16 through I-POL-19)

ID	Invariant	Check
I-POL-16	Every EvaluationReport has a request and policy ref	Both `request` and `policy` present
I-POL-17	Decision is a valid outcome	`decision` ∈ {permit, deny, indeterminate, not-applicable}
I-POL-18	Evaluation timestamp is present	`timestamp` is valid ISO 8601
I-POL-19	PolicySet has at least one policy	`policies` array present and non-empty

5. POLICY-LD @context Extension

{
  "@context": {
    "Policy": "https://specs.initialcore.net/ns/policy#Policy",
    "Rule": "https://specs.initialcore.net/ns/policy#Rule",
    "Condition": "https://specs.initialcore.net/ns/policy#Condition",
    "Permission": "https://specs.initialcore.net/ns/policy#Permission",
    "Obligation": "https://specs.initialcore.net/ns/policy#Obligation",
    "Prohibition": "https://specs.initialcore.net/ns/policy#Prohibition",
    "PolicySet": "https://specs.initialcore.net/ns/policy#PolicySet",
    "EvaluationReport": "https://specs.initialcore.net/ns/policy#EvaluationReport",

    "jurisdiction": "https://specs.initialcore.net/ns/policy#jurisdiction",
    "rules": { "@id": "https://specs.initialcore.net/ns/policy#rules", "@container": "@set" },
    "conflictStrategy": "https://specs.initialcore.net/ns/policy#conflictStrategy",
    "combiningAlgorithm": "https://specs.initialcore.net/ns/policy#combiningAlgorithm",
    "version": "https://specs.initialcore.net/ns/policy#version",
    "priority": "https://specs.initialcore.net/ns/policy#priority",

    "conditions": { "@id": "https://specs.initialcore.net/ns/policy#conditions", "@container": "@set" },
    "consequence": "https://specs.initialcore.net/ns/policy#consequence",
    "effect": { "@id": "https://specs.initialcore.net/ns/policy#effect", "@type": "@id" },
    "immutable": "https://specs.initialcore.net/ns/policy#immutable",

    "field": "https://specs.initialcore.net/ns/policy#field",
    "operator": "https://specs.initialcore.net/ns/policy#operator",

    "action": "https://specs.initialcore.net/ns/policy#action",
    "resource": { "@id": "https://specs.initialcore.net/ns/policy#resource", "@type": "@id" },
    "actor": { "@id": "https://specs.initialcore.net/ns/policy#actor", "@type": "@id" },
    "details": "https://schema.org/description",
    "trigger": "https://specs.initialcore.net/ns/policy#trigger",
    "deadline": "https://specs.initialcore.net/ns/policy#deadline",

    "permit": "https://specs.initialcore.net/ns/policy#permit",
    "deny": "https://specs.initialcore.net/ns/policy#deny",
    "obligate": "https://specs.initialcore.net/ns/policy#obligate",
    "waive": "https://specs.initialcore.net/ns/policy#waive",

    "request": { "@id": "https://specs.initialcore.net/ns/policy#request", "@type": "@id" },
    "decision": "https://specs.initialcore.net/ns/policy#decision",
    "matchedRules": { "@id": "https://specs.initialcore.net/ns/policy#matchedRules", "@container": "@set" },
    "obligations": { "@id": "https://specs.initialcore.net/ns/policy#obligations", "@container": "@set" },
    "prohibitions": { "@id": "https://specs.initialcore.net/ns/policy#prohibitions", "@container": "@set" },
    "indeterminate": "https://specs.initialcore.net/ns/policy#indeterminate",
    "not-applicable": "https://specs.initialcore.net/ns/policy#not-applicable"
  }
}

6. Composition Examples

6.1 Policy evaluation of an INPUT-LD request

{
  "@context": [
    "https://specs.initialcore.net/ns/core-ld.jsonld",
    "https://specs.initialcore.net/ns/input-ld.jsonld",
    "https://specs.initialcore.net/ns/policy-ld.jsonld"
  ],
  "@id": "_:eval1",
  "@type": "EvaluationReport",
  "request": "_:req1",
  "policy": "_:pol1",
  "decision": "permit",
  "matchedRules": [ "_:rule1", "_:rule2" ],
  "obligations": [ "_:obl1" ],
  "timestamp": "2026-07-30T16:00:00Z",
  "provenance": {
    "Representer": "did:icore:engine",
    "Timestamp": "2026-07-30T16:00:01Z",
    "Authority": { "authorityType": "inherent" },
    "RepresentationContext": "urn:icore:policy:eval:v1"
  }
}

6.2 Constitutional policy with compound conditions

{
  "@context": [
    "https://specs.initialcore.net/ns/core-ld.jsonld",
    "https://specs.initialcore.net/ns/policy-ld.jsonld"
  ],
  "@id": "_:constitutionalPolicy",
  "@type": "Policy",
  "name": "ConstitutionalEntityProtection",
  "jurisdiction": "urn:icore:governance:constitutional",
  "conflictStrategy": "deny-overrides",
  "rules": [ "_:protectRule" ],
  "provenance": {
    "Representer": "did:icore:foundation",
    "Timestamp": "2026-07-30T00:00:00Z",
    "Authority": { "authorityType": "inherent" },
    "RepresentationContext": "urn:icore:constitution:v1"
  }
}

{
  "@id": "_:protectRule",
  "@type": "Rule",
  "name": "ProtectConstitutionalEntities",
  "consequence": "deny",
  "conditions": [ "_:condIsConstitutional", "_:condNotAdmin" ],
  "priority": 1000,
  "immutable": true
}

{
  "@id": "_:condIsConstitutional",
  "@type": "Condition",
  "operator": "and",
  "conditions": [
    { "@id": "_:c1", "@type": "Condition", "field": "target.identifier.isConstitutional", "operator": "equals", "value": true },
    { "@id": "_:c2", "@type": "Condition", "field": "intent", "operator": "equals", "value": "mutate" }
  ]
}

{
  "@id": "_:condNotAdmin",
  "@type": "Condition",
  "field": "context.actor",
  "operator": "notIn",
  "value": ["did:icore:admin", "did:icore:foundation"]
}

6.3 PolicySet with combining strategy

{
  "@context": [
    "https://specs.initialcore.net/ns/core-ld.jsonld",
    "https://specs.initialcore.net/ns/policy-ld.jsonld"
  ],
  "@id": "_:govSet",
  "@type": "PolicySet",
  "name": "ICoreGovernancePolicySet",
  "policies": [ "_:identityPolicy", "_:storagePolicy", "_:memoryPolicy" ],
  "combiningAlgorithm": "deny-unless-permitted",
  "provenance": {
    "Representer": "did:icore:foundation",
    "Timestamp": "2026-07-30T00:00:00Z",
    "Authority": { "authorityType": "inherent" },
    "RepresentationContext": "urn:icore:constitution:policy-set:v1"
  }
}

7. Conformance

7.1 Implementation requirements

A conforming POLICY-LD implementation MUST: 1. Satisfy all CORE-LD conformance requirements (§9 of CORE-LD) 2. Parse the POLICY-LD @context extension (§5) in addition to the CORE-LD @context 3. Validate all 19 POLICY-LD invariants (I-POL-1 through I-POL-19) 4. Evaluate any set of Policy entities against any Request entity and produce an EvaluationReport 5. Support at least the deny-overrides and permit-overrides conflict strategies 6. Reject documents that violate any CORE-LD or POLICY-LD invariant

7.2 Conformance levels

Level	Requirements
L1 Rule Definition	CORE-LD L1 + I-POL-1 through I-POL-11 (policies, rules, conditions parse and validate)
L2 Access Control	L1 + I-POL-12 through I-POL-15 (permissions, obligations, prohibitions)
L3 Full Constitutional	L2 + I-POL-16 through I-POL-19 + evaluation engine + provenance on constitutional policies

8. Relationship to Other Profiles

Profile	Relationship
INPUT-LD	POLICY-LD evaluates INPUT-LD requests. Permissions and prohibitions govern `intent` and `target`.
MEMORY-LD	Policies may be stored and retrieved via MEMORY-LD. Evaluation reports may be recorded as Episodes.
TRUST-LD	Policy decisions depend on trust attestations. TRUST-LD provides the verification substrate.
CORE-LD	Conditions reference entity fields from any CORE-LD document. All invariants inherited.

9. Future Considerations

Derived permissions: Policies that automatically generate sub-permissions based on role hierarchy
Policy versioning: Immutable policy history with rollback semantics
Delegated evaluation: Cross-system policy evaluation where jurisdiction is distributed
Temporal conditions: Conditions that reference time windows, schedules, or deadlines
Policy as data: Storing policies as MEMORY-LD KnowledgeAtoms for audit and analysis
Constitutional amendment: Workflow for modifying constitutional policies with provenance chain

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