Capability Language Core

4.1. Operation (authorization side)

A concrete action request: CapabilityId + parameters.¶

{ "id": "std/database-v1:query:SELECT",
  "params": {"tables":["customers"], "limit":{"max":50}} }

Missing id → deny("missing_capability_id").¶

4.2. ObservedAction (evidence side)

The material action constructed by the effect boundary from executor-controlled facts. CLC-v1 defines the interface, not the construction algorithm.¶

An ObservedAction carries:¶

• action_type: the action type name declared by the relying-party-pinned type definition (the class this projection belongs to)¶

• material_fields: every field the type definition declares material¶

• digest: computed over the canonical material projection (below)¶

The material projection is deterministic and normative:¶

• The action type declares a material field set (required and optional-but-included). Only that set enters the digest.¶

• Canonical serialization is the JSON Canonicalization Scheme (JCS) [RFC8785]; the one suite defined in v1 is jcs-sha256 (Section 4.3).¶

• The projection identity is the language's own, not a CAID: clc-action:1:<type>:<suite>:<b64url>. A CAID [CAID] covers the complete Action Object under its own suite registry and identifies the action object, not an occurrence; this projection covers only the declared material set. The two are related by a relying-party-pinned Action-Mapping Profile (Section 6.4), never by treating the strings as interchangeable.¶

• A field the type does not declare as material MUST be excluded from the digest and MUST NOT affect Match: an ObservedAction carrying undeclared fields is not invalidated, but those fields carry no action identity.¶

• A type-declared material field that is missing makes the ObservedAction non-matchable: coverage MUST NOT be inferred, defaulted, or repaired (UNSATISFIED, Section 10). This is the evidence-side mirror of key closure (Section 6.2): the absence of a governing field is fail-closed, never fail-open.¶

The effect boundary MUST construct the ObservedAction from facts it controls. It MUST NOT copy a requester-supplied action digest without deriving or checking the corresponding fact.¶

4.3. Identity

Two identity levels, corresponding to the two Action forms:¶

A CapabilityId covers a class; an ActionId identifies the material content of one action. It does not identify an occurrence: ActionId binds the declared material content, and correlation to a particular occurrence additionally requires an occurrence discriminator defined and checked by the consuming profile. CAID-03 Section 4.6 carries such a discriminator as the optional occurrence_id of an action object; when a profile uses one, it MUST appear among the declared material fields for it to affect the digest. Allocating unique occurrences and proving one-time consumption or execution stay outside both documents (CAID-03 Section 7). Entailment checks class coverage; Match checks content binding.¶

6.1. Entailment (authorization binding)

Grant G covers operation O if:¶

1. Literal: G = O (byte-for-byte after normalization).¶

2. Trailing wildcard: G = scheme:prefix:* and O has at least one segment after scheme:prefix: (segment-boundary comparison, not lexical prefix).¶

6.2. Parameters

Boolean parameters are exact only. A boolean grant value is matched by exact equality (true covers true only). Booleans are not numbers: an implementation MUST NOT interpret true/false as 1/0 and MUST NOT run them through the numeric-bound rule (op ≤ grant). They also play no role in numeric comparisons or bounds. (Boolean GRANT-side bounds are rare in practice; the setting that matters — an operation-side boolean value under key closure — is pinned by undeclared-001.)¶

Table rows map to vectors: number → params-001/params-002; array scalar member → params-009 (holds) / params-010 (fails); array element-wise → params-011 (holds) / params-012 (fails); object recursion allow → params-015, deny-direction → params-005; categorical guard → params-014. Under the old (pre-v1.1) array-as-bound rule the object example read (does not hold); with the v1.1 enum rule the request-side element id is a member of the granted set, so the row is (holds) (see clc-v1-ambiguities.md Section 2).¶

Enum semantics of arrays (v1.1). An array-valued grant parameter is the set of allowed values, not an order. The request MAY supply a single scalar (must be a member of the set) or an array (every element must be a member). Members compare by exact equality: a number inside a granted array denotes that exact value, not a bound. This is what keeps categorical identifiers safe — grant {"station":[3]} does not cover station 2 (failure → deny("not_in_enum")). Scheme authors SHOULD encode categorical parameters (station, cell, batch, tool id) as arrays; a scalar number in the grant keeps upper-bound (bound) semantics for ordered quantities (max_rows, speed, angle).¶

An explicitly empty grant array [] denies the class (empty_bound_denies_class).¶

Grant with no params — or with an empty {} params object — covers any operation params (unconstrained). An absent params and "params":{} are semantically equivalent — consistent across entailment (Section 6.3) and intersection (Section 7 rule 6; Section 9.1).¶

A null parameter value is invalid in v1 → reject (invalid_params_null). Absent ≠ explicitly empty (see Section 8).¶

Key closure (Plan A). A bounded grant governs its declared keys: an operation carrying a parameter key the grant does not declare is rejected → deny("undeclared_param") (fail-closed, Section 9.1 layer 7 request side). An unconstrained grant (no params, or params:{}) accepts any operation params, so no key closure applies there. Within layer 7 the missing-key check (params_missing) resolves before the undeclared-key check (undeclared_param); both are key-level and run before the enum/bound value checks (layers 8–9).¶

Params representation and input normalization (v1.1). Before any Section 9.1 layer runs, the params object is normalized at the input boundary:¶

1. Canonical serialization. Params are normalized to the JSON Canonicalization Scheme form (JCS, RFC 8785): object members sorted by code unit, numbers in the ECMAScript Number::toString form, no insignificant whitespace. The original key order, number spelling and spacing are not preserved — canonicalization replaces them with the deterministic form (this is what the size cap in step 4 and the material digest are measured on). Evaluation never guesses; a lossy re-serialization (e.g. a map that drops duplicate keys) is not used for decisions.¶

2. Duplicate keys. A params object with a duplicate JSON key is rejected: deny("invalid_params_duplicate_key").¶

3. Number shape. A numeric param is rejected with deny("invalid_params_number") when it is non-finite or out of IEEE-754 range (e.g. 1e400, an exponent beyond the representable maximum — it is an overflow, not an over-precision case) or over-precision (more than 17 significant decimal digits, e.g. 1.0000000000000001). The digit count operates on the JSON token as received — the raw digit-character sequence at the input boundary, before it enters any storage / float / decimal representation — so float64 and decimal/bignum implementations MUST NOT diverge: the judged input is always the raw token text (params-* number probes in the corpus; near-limit forms such as 1.0000000000000001 extend the probes without changing the rule). Malformed params text that cannot be parsed as an object is refused with the same code (see step 7).¶

4. Size and depth. Params whose canonical length exceeds 512 UTF-8 octets — measured in octets, never in code points or UTF-16 code units (rev CLC-1.4) — or whose nesting depth exceeds 32, are rejected: deny("invalid_params_size"). Nesting depth counts both objects and arrays, with the outermost object as level 1 (31 nested arrays inside the top-level object therefore = depth 32).¶

5. Order of checks. Size/depth (4) precede duplicate keys (2), which precedes number shape (3); the first failing check wins. All five run before Section 9.1 layer 1, so normalized params are the only view the layers see. The size in step 4 is measured with every token in its JCS spelling (numbers re-spelled per ECMAScript Number::toString, strings per JCS Section 3.2.2.2) but without requiring key uniqueness, so it is defined even when a duplicate key makes full JCS undefined; this is why an over-limit input that also has a duplicate key reports invalid_params_size (params-025/params-026).¶

6. Decoded-object path. A caller that supplies params already decoded (no raw_params text) cannot reproduce the original byte stream; in that case the size check (4) applies to a canonical serialization (the JCS form of the decoded object: sorted keys, compact), and the depth check (4) applies to the decoded structure directly. Byte-exactness against a specific original text is guaranteed only for the raw path; but both entry points MUST reject the caps — an oversized/deep params object is denied whichever way it arrives.¶

7. Malformed Unicode is a property of the received text. A lone surrogate escape, or an octet that is not valid UTF-8, has no JCS form (Section 3.2.2.2): step 1 cannot normalize it, so the input is refused. The refusal reuses invalid_params_number (Section 9.2), whose scope is "the params input is not representable in canonical form" — a numeric param that is non-finite / over-precision or text that is not well-formed Unicode / not parseable as a JSON object. (One stable code, not one per malformation: introducing a second code would change the reason for inputs already pinned to invalid_params_number, which the additive rule forbids.) That check is defined over the octets as received and MUST run before any decoding step, because a general-purpose JSON decoder does not preserve the distinction. Go's encoding/json, for example, replaces both a lone surrogate escape and an invalid octet with U+FFFD, so {"s":"\ud800"}, {"s":"\ufffd"} and a literal invalid octet arrive at the decision function as the same value — {"s":"\ufffd"} — and the refusal cannot be recovered afterwards. Therefore:¶

   • the party that receives the input MUST run steps 1-5 on the received text, not on a re-serialization of a decoded value;¶

   • an implementation that exposes only a decoded-value entry point MUST NOT be described as refusing malformed Unicode: its verdict is defined over the value it was handed, which may already be a repaired one. The entry point that takes the text is the normative one, and an implementation SHOULD name the two so a caller cannot mistake one for the other;¶

   • two parties that must agree on the verdict MUST agree on the received text, or on a digest of it.¶

6.3. Algorithm

Entails(G, O) → bool:
  1. G.namespace ≠ O.namespace → false      (namespace = scheme + action Class, Section 9.1 layer 3)
  2. G.id doesn't cover O.id → false        (path coverage, Section 9.1 layer 4)
  3. G declares no key → true               (both `params` and `param_bounds` absent/empty
                                             → grant unconstrained, absent ≡ empty object)
  4. O.params absent → false                (bounded grant, request omits it → fail-closed,
                                             except a declared key marked `optional`, Section 6.5)
  5. params_subset(O.params, keys(params) ∪ keys(param_bounds), param_bounds)
                                            (compare declared set incl. Section 6.5 bounds, Section 9.1 layers 5–9)

Step 5 is the Section 9.1 layers 5–9 comparison over the grant's declared key set (keys(params) ∪ keys(param_bounds), Section 6.5): params values follow Section 6.2 value subset, and a param_bounds key additionally enforces its Bound (inclusive min/max, step, enum cardinality, optional, nested). A grant with no param_bounds reduces step 5 to the params-only comparison of earlier revisions. Steps 3 and 4 read the declared key set, so a grant whose only declarations are param_bounds is still "bounded" for presence purposes.¶

When more than one check fails, the reported reason follows the fixed resolved-reason ordering of Section 9.1. The remaining rules of this section are unchanged.¶

Rule for missing operation params: If the grant has a params bound (step 3 does not apply) and the operation has no params field at all (not merely a key missing, but the entire field absent), step 4 applies: Entails → false → deny("params_missing"). This covers both "operation omits the entire params object" and "operation omits a single bounded key" — both fail closed.¶

If a capability scheme declares a default value for a parameter, the implementation MUST apply that scheme default to O before step 4; absent such a declared default, step 4 denies.¶

Layer 6 (null) resolves before presence. If the grant's params carry a null value (or the operation's params do), the failure is invalid_params_null (Section 9.1 layer 6) and is reported even when the operation omits the params field entirely — i.e. layer 6 resolves before step 4's params_missing. This is the fixed Section 9.1 ordering; it shadows the literal step order of the algorithm above, which lists presence before the null checks.¶

6.4. Match (evidence binding)

Evidence E is bound to exact action A if:¶

1. E carries a valid ActionId in the language's projection form (clc-action:1:…, Section 4.3). A CAID is a different object and relates to it only through a pinned Action-Mapping Profile.¶

2. E's ActionId equals the recomputed ActionId of the ObservedAction.¶

3. The ActionId was computed under the relying-party-pinned suite and definition source.¶

Match is content correlation only. It does not validate a native artifact and does not authorize execution. It also does not identify an occurrence: correlation to a particular occurrence additionally requires an occurrence discriminator defined and checked by the consuming profile (CAID-03 Section 4.6), and a profile that uses one MUST pin how it is obtained and that the language sees it among the declared material fields.¶

Cross-format mapping (E's native format ≠ A's canonical form) uses an Action-Mapping Profile: a hash-identified projection pinned by the relying party, with results EQUIVALENT_UNDER_PROFILE, NOT_EQUIVALENT, or INDETERMINATE.¶

6.5. Extended parameter bounds (param_bounds)

params (Section 6.2) stays exactly as defined: a scalar number is an upper bound, an array is a membership set, an object recurses per key, and there is no lower bound, no step, no cardinality bound and no optional-key marker. This subsection adds those as a separate, optional grant field, param_bounds, so that no existing params input changes meaning: a grant without param_bounds behaves exactly as before, and every params verdict is unchanged.¶

Binding rule (one authoritative representation per key). A parameter key MUST be declared in at most one of params and param_bounds. Declaring the same key in both is rejected: deny("invalid_params_binding"). The declared key set of a grant is keys(params) ∪ keys(param_bounds); key closure (Section 9.1 layer 7) and the params:{}≡absent rule are read over that set.¶

Four distinct layers — do not collapse them in a decoder. A bare {} has different meaning at each layer, and an implementation must keep them separate before normalizing:¶

1. Container presence — "params" absent vs "params":{}. Both are unconstrained (no declared keys); {} is not "declares nothing and denies".¶

2. Declaration site — a key is declared via params or param_bounds (never both). The site decides which value algebra applies to the key.¶

3. Value constraint — inside params, an empty value is a restriction ({"tables":[]} denies the class; deny-when-declared, Section 6.2); inside param_bounds, an empty Bound {} declares the key with no value constraint (it only participates in key closure). Same {}, opposite reading, because the layer differs.¶

4. Request value — what O supplies (or a materialized default), evaluated per the key's family at layers 7–9.¶

A decoder that maps {}→"absent" or {}→"empty set" uniformly across these layers will disagree with the language on at least one of them.¶

Bound grammar (closed). param_bounds maps a key to a Bound object:¶

Bound = {                          // a closed JSON object, at most one family
  // numeric family
  "min":       <number>,           // inclusive lower bound
  "max":       <number>,           // inclusive upper bound
  "step":      <number > 0>,       // value must be an integer multiple of step
  // enum family
  "enum":      [ <scalar> ],       // allowed values (membership set)
  "min_items": <integer >= 0>,     // request cardinality lower bound
  "max_items": <integer >= 0>,     // request cardinality upper bound
  // nested family
  "nested":    { <key>: Bound },   // recursion for an object-valued key
  // orthogonal to all families
  "optional":  <boolean>           // request MAY omit the key (default false)
}

(Bound is JSON, not ASN.1: the members above are JSON keys and the comments are notation only.)¶

Every member is optional and the object is closed — a member outside this set is rejected (invalid_params_binding). A Bound carries at most one value family, plus optional which is orthogonal:¶

• numeric family — any of min, max, step;¶

• enum family — enum, and/or min_items/max_items;¶

• nested family — nested.¶

Mixing families (e.g. enum with max, or nested with min) is rejected (invalid_params_binding). An empty Bound {} declares the key with no value constraint (it still participates in key closure). min > max, step ≤ 0, min_items > max_items, or a negative min_items are rejected (invalid_params_binding). The whole param_bounds object is subject to the same input normalization as params (Section 6.2): canonical serialization, duplicate keys, number shape, size (512 octets) and depth (32), checked at layer 2.¶

Entailment semantics (grant G vs operation O).¶

• Presence (layer 7). A declared key with optional: true MAY be absent from O; a declared key with optional absent or false MUST be present (params_missing otherwise). An operation key not in the declared key set is undeclared_param. (Unchanged behavior for grants that declare no param_bounds, where every declared key is required.)¶

• Enum family (layer 8). If enum is declared, the request value must be a member (not_in_enum, unchanged rule): a scalar request must equal a member; an array request must have every element equal to a member. Equal here is JSON type-sensitive equality: two values are equal only when they have the same JSON type and the same value — true equals neither 1 nor 0 (the Section 6.2 rule that booleans are never numbers applies to set membership as well), and the string "1" equals neither the number 1 nor true. Numbers are compared after the Section 6.2 canonicalization of the input boundary (one IEEE-754 binary64 value, rendered per ECMAScript Number::toString under JCS [RFC8785]), so 1 and 1.0 — the same value in two spellings — are equal. The same equality is used by Section 6.2 array membership, by the Section 6.6 enum intersection, and by Section 13.4.3 enum narrowing; implementations MUST NOT substitute a host-language equality that coerces across JSON types (e.g. a language where true == 1). If min_items / max_items are declared, the request cardinality (an array's length; a scalar counts as 1) must satisfy min_items ≤ n ≤ max_items, else params_cardinality.¶

• Numeric family (layer 9). min/max are inclusive: a numeric request value must satisfy min ≤ v ≤ max (each bound, when declared), else params_out_of_range. step requires the request value to be an integer multiple of step, evaluated in IEEE-754 binary64 as let q = v / step in q == floor(q) && q * step == v (deterministic across implementations, since both operands arrive at the boundary as binary64), else params_not_multiple. A numeric-family bound applied to a non-number request value is fail-closed (params_exceed_grant).¶

• Nested family (layer 8/9). nested recurses the value comparison on an object-valued request key with the same rules, including symmetric key closure and optional at each depth. A nested bound applied to a non-object request value is fail-closed (params_exceed_grant).¶

Scheme defaults. A capability scheme (Section 3 scheme grammar; data/std/...) MAY declare param_defaults, a map from a parameter key to its default value. The consumer obligation of Section 6.3 is thereby made concrete: before evaluating Entails(G, O), an implementation MUST materialize, for every key O omits that the scheme declares a default for, that default into O's params; precedence is explicit operation value > scheme default > absent. A default is applied only when it is needed to satisfy a grant-declared key; it never adds a key the grant does not declare (the key-closure check is unchanged).¶

optional closes the default interaction (no recursion). The presence of the key is decided first, by the grant's optional marker, and only then is a default consulted — so there is no "is the default needed?" loop:¶

• a required declared key (no optional/optional:false) that O omits: materialize param_defaults[key] if the scheme declares one (the key is then present with that value), else deny("params_missing");¶

• an optional:true declared key that O omits: the default is not materialized — optional is the explicit "may be absent" marker and wins over the default, so the key is simply absent (and satisfies presence);¶

• either way, an explicitly supplied O value wins over the default.¶

Defaults are scheme configuration, not language semantics: the relation itself takes no scheme argument, and two consumers that load the same scheme reach the same verdict (a deployment that omits the scheme's defaults is a different input, and the difference is attributable to the input, not to Entails). In the containment relation a default is resolved before the grants are compared (Section 13.8.1 obligation 1), so containment compares resolved declared sets. A param_defaults entry is not part of a grant's declared set and does not enter the containment lattice: Contains narrows over keys(params) ∪ keys(param_bounds) and the optional markers alone, so a parent's default never widens or inverts the optional→required narrowing direction (Section 13.4.3).¶

Containment (Section 13). Section 13.4.3 narrows a child grant against its parent using this grammar: a param_bounds bound of the child must be within the parent's bound for the same key (numeric min raised or equal, max lowered or equal, step refined to an integer multiple, enum a subset, cardinality bounds tightened, optional not widened from required to optional, nested recursed). A parameter declared in one of params/param_bounds and not the other is a key-set difference and fails key closure (params_not_narrower).¶

6.6. Intersection of bounds (BoundMeet)

Intersect (Section 7) combines the param_bounds of its sources with a meet, over the same "value → authorization set" denotation Section 7 uses for params. The families are those of Section 6.5; the meet is defined per key declared in param_bounds by two or more sources.¶

• optional is orthogonal and combines by conjunction: the result key is optional only if every source marks it optional (optional := AND); a key required by any source stays required.¶

• numeric family (min/max/step): min is the greatest declared minimum, max the least declared maximum (undeclared means unbounded). step: if both declare one and one is an exact multiple of the other (the Section 6.5 multiple predicate), the meet's step is the coarser (larger) of the two — the coarser grid is a subset of the finer, so it is the meet. If neither declared step is an exact integer multiple of the other, the meet fails closed (invalid_params_binding). The two grids may still share values — the common grid of step:5 and step:7 is the set of multiples of 35, so the intersection is not empty — but the meet's step must be one of the two declared steps: neither 5 nor 7 is an integer multiple of the other, so neither declared grid is a subset of the other, and the language does not synthesize an undeclared grid (such as the least common multiple) — no single step member of the two Bounds denotes both grids. One declared step is carried through. min > max after combining → the meet is empty → no_overlap.¶

• enum family (enum/min_items/max_items): the enum member sets intersect (exact equality — the JSON type-sensitive equality Section 6.5 layer 8 defines, so 1, true and "1" are three distinct members); if both sources declare enum and the intersection is empty → no_overlap; min_items is the greatest declared value, max_items the least; max_items < min_items → no_overlap.¶

• nested family (nested): the two objects MUST have the same key set, else no_overlap (exactly as object-valued params, Section 7); the result recurses BoundMeet per key, with optional combining as above at every depth.¶

• numeric ∩ enum (either source order): refused — fails closed (invalid_params_binding). A sound meet would have to carry both the numeric side's shape constraint (min/max/step, which Section 6.5 layer 9 applies to numeric scalar request values only) and the enum side's member set (which Section 6.5 layer 8 applies to scalars and to arrays whose elements are all members) in one Bound — two families, which the closed Section 6.5 grammar deliberately does not express. Filtering the member list by the numeric bound (the rev CLC-1.14 rule, removed here) was broader than either source: for numeric {min:2,max:4} ∩ enum {enum:[1,3,5]} the filtered result enum{3} accepts the array [3] (Section 6.5 layer 8: every element is a member), while the numeric source fail-closes that same request (Section 6.5 layer 9: a numeric-family bound applied to a non-number request value is params_exceed_grant). Refusing the whole combination agrees with the rest of the language: Section 6.5 rejects declaring two families in one Bound ("Mixing families … is rejected (invalid_params_binding)"), and Section 13.4.3 rejects narrowing into a family the other side does not declare ("a child Bound that adds a family the parent does not declare … is params_not_narrower"). The refusal covers every numeric × enum pair — with or without a member list on the enum side (a cardinality-only enum is the same cross-family clash), and regardless of whether any member happens to fall inside the numeric range: the family clash is decided before any member or range math, and it is symmetric in the two sources.¶

• scalar ∩ nested (numeric or enum vs. nested), in either order: a cross-family meet, refused with invalid_params_binding before any value math — no single-family Bound can carry both a scalar shape (a value presence) and the object recursion; the refusal is symmetric in the sources and holds regardless of the nested side's contents, exactly like the numeric × enum case (design-notes D12). A CLC-1.14 draft read this pair as an empty meet (no_overlap, since no request value is both a scalar and an object); rev CLC-1.15 adjudicates it to the unrepresentable-meet code so that the empty-meet code stays reserved for genuinely empty meets within one value family.¶

• empty Bound {} is the identity for the value families ({} ∩ X = X); its optional still participates.¶

The result always carries at most one value family, so it is a valid Section 6.5 Bound. All failure modes are the Section 9.2 codes already associated with Intersect (no_overlap for an empty meet within one value family, such as min > max or disjoint enums; invalid_params_binding for an unrepresentable one — every cross-family pair in either order, including scalar ∩ nested, and incommensurable step grids); no new reason code is introduced.¶

Key site. A key's declaration site (params vs param_bounds) must agree across the sources of one Intersect. A key declared in params by one source and in param_bounds by another is refused (invalid_params_binding). This can only arise for independent authority sources, never for a delegation chain: Section 13.4.3 already requires the sites to match at every hop (a site difference is a key-set difference). A key that no source declares in param_bounds stays in params and follows the Section 7 params meet unchanged.¶

7.1. ConstraintUnion (derived projection)

A consumer that has established a delegation chain often needs the chain's whole constraint burden without computing an effective grant. That is exactly the constraint projection of chained Intersect (rule 3), exposed as a named function:¶

ConstraintUnion(chain) → string[]        // chain = ordered Grant[]

It returns the normalized union of every constraint string carried by the grants in chain — duplicates folded, result deterministically ordered. "Lexically sorted" is pinned to UTF-8 byte order: the normalized strings are compared octet by octet over their UTF-8 encodings. For well-formed Unicode text this equals code-point order, and it is identical in every implementation whatever the host language's native string representation is — notably it is not UTF-16 code-unit order, which places supplementary-plane characters (encoded as surrogate pairs, first unit U+D800–U+DBFF) before characters in U+E000–U+FFFF, so an emoji would sort before a private-use-area character although its code point is higher. This collation sits after Section 6.2 canonicalization, not instead of it: JCS [RFC8785] Section 3.2.3's UTF-16 code-unit order governs object member order inside a canonical serialization, while this section's UTF-8 byte order governs the emitted constraint-string list; the two artefacts keep their own pinned collations and neither re-orders the other. The union is the same normalization Intersect applies, so the two never disagree. The residual-obligation list of Section 8.4 (and the ordered Resolve output of Section 8.5) re-uses this same collation; the collation is defined here once, not restated there.¶

ConstraintUnion is a projection, not a meet: it does not compare identifiers or parameters, does not read or validate constraint values, and does not check containment. It asserts nothing about authority; the chain's per-hop Contains check (Section 13) and the operation's Authorize/Resolve (Section 9, Section 8.5) remain separate steps. Because it is not an effective-set computation, it carries no membership semantics of its own — an empty chain fails closed with absent_source (the same refusal Intersect gives over zero sources, Section 7 rule 5), so a caller that lost the chain cannot mistake "nothing to union" for "no constraints".¶

This function is why Contains stays pure (Section 13.4.4): containment answers "is the child's declared boundary inside the parent's?", and the union answers "what does the chain collectively require?". Folding the union into Contains would make the relation no longer a subset on the declared tuple and would let a null constraint check hide a broken boundary.¶

8.1. Authorization-side constraints

Limit how a capability may be used. Constraints use colon-notation triples: scheme:type[:params], where type is the second :-delimited segment (scheme : type, optionally followed by : and params):¶

• varwof/constraint-v1:max_rows:100 — type max_rows, param 100¶

• varwof/constraint-v1:time:window:[{"start":"00:00","end":"01:00"}] — type time, param window: array of UTC window segments (a single window = a one-element array). A scalar form (time:window:3600, the sliding-duration/freshness concept) is not a legal time:window value in v1 → invalid_constraint.¶

• varwof/constraint-v1:network:cidr:["10.0.0.0/8"] — type network, param cidr: JSON array (≤ 32 elements, each a legal IPv4/IPv6 CIDR string)¶

v1 core recognizes constraints by (scheme, type) pair, not by type name alone: the identity of a constraint is two things — the declaring scheme and the type. The core recognizes exactly these pairs:¶

varwof/constraint-v1 : max_rows
varwof/constraint-v1 : time
varwof/constraint-v1 : network

Any other (scheme, type) — including foo/database-v1:max_rows — is not core-recognized: it is rejected as unknown_constraint (fail-closed), never handed to a core evaluator. This kills cross-scheme semantic pollution: the type name alone never selects an evaluator, so a scheme that defines its own max_rows cannot have its semantics hijacked by Core's max_rows evaluator (§P7 define once, consume everywhere — scoped per declaring scheme). Scheme-defined constraint types belong to the v2 / profile layer (evaluated by the declaring scheme); core's non-recognition of them is fail-closed (unknown_constraint).¶

A recognized constraint MUST also conform to that type's value grammar (table below); a recognized type with a non-conforming value is rejected as invalid_constraint — never silently skipped, never passed through. Intersection itself neither evaluates nor validates constraint values (it only merges constraint strings; the Section 8.1 value grammar is enforced at the decision boundary, Section 9, and in the constraint merge rules below).¶

The core defines an evaluator for max_rows only; evaluation of time/network bounds is the declaring capability scheme's responsibility (the scheme evaluates, the core owns only what the Section 8.1 value grammar is, not whether a moment/address currently hits it; Section 11). A recognized-but-unevaluated constraint is carried on the decision's additive unresolved field — never silently dropped (Section 8.4). A non-recognized (scheme,type) → deny("unknown_constraint") (fail-closed).¶

The expressible window set has no empty window and no full-day window; a declaring scheme that needs such windows extends the grammar (Section 11).¶

Merge rules in v1: numeric → minimum wins; allowlist → intersection; unknown → deny. The allowlist is the array-enum set (Section 6.2); intersecting it takes the shared members. v1 core defines no denylist constraint — merging applies only to the varwof/constraint-v1 types the core itself evaluates; it does not define or merge scheme-defined types (Section 11). Constraint-set merging is always normalized and deterministically ordered (duplicate strings collapsed, result ordered) — the same input yields the same constraint sequence in any implementation. v1 does not tighten time/network bounds at intersection: intersection keeps only the constraint strings it encounters (no evaluation, no tightening, Section 8.4).¶

8.2. Evidence-side constraints

Require specific evidence properties: freshness, consumption, quorum, initiator-exclusion, etc.¶

These are structurally identical to authorization constraints — a type plus optional params — but evaluated against evidence artifacts rather than operation parameters.¶

8.3. Unified constraint grammar

constraint = scheme ":" type [ ":" params ]

Both sides use the same grammar. The validator (authorization) or evidence evaluator (evidence) interprets the type-specific params.¶

8.4. Recognized but not evaluated (residual-obligation channel)

A recognized constraint whose value conforms to its Section 8.1 value grammar but for which the v1 core defines no evaluator — v1: time, network; evaluation belongs to the declaring scheme (Section 11) — MUST NOT be silently dropped: it must appear in the decision's additive unresolved list (Section 9), and the verdict must be allow_unresolved (not allow):¶

Decision = { verdict: "allow"|"deny"|"allow_unresolved",
             reason, unresolved: string[] }

Fail-closed boundary: allow_unresolved is an independent enum value, never equal to allow. A consumer (PEP / profile / declaring scheme) MUST evaluate or confirm every unresolved constraint before allowing; if it cannot execute or confirm, it MUST deny (AAC Section 6.6: "when it cannot perform or confirm, it should be treated as deny"). A consumer that only writes if decision.verdict == "allow" cannot, on the literal enum, release a residual obligation as an already-satisfied allow — a path that leaves obligations unconfirmed must explicitly handle allow_unresolved to pass. "the caller is supposed to check unresolved" is not sufficient defense: the verdict itself must refuse the two-value short-circuit.¶

unresolved semantics and ordering: [] for deny and for fully evaluated allow; for allow_unresolved the normalized constraint strings with duplicates folded — the conditional collation order of Section 7.1 (#-separated, then by UTF-8 byte sequence), the same comparison the ConstraintUnion payload uses (rev CLC-1.15). The order is deterministic: the same input yields the same byte sequence in any implementation — in particular NOT the ECMAScript default string order (UTF-16 code-unit order); join the residual obligations across all sources and sort exactly once, before emitting the decision.¶

Combined obligations (consumer side): multiple unresolved constraints of the same (scheme,type) form a conjunction (AND) — satisfying A and B satisfies all; OR, any-one, first-wins, and ignoring some entries are all forbidden. Constraints of different (scheme,type) do not interact; each evaluates under its own declaring scheme (P11 composition narrows only: conjunction only narrows).¶

The core owns only the value grammar ("what it is"); "whether this window/CIDR currently forms a boundary" ("how to evaluate") belongs to the declaring scheme (Section 11) — but the boundary-moment semantics are part of the grammar (Section 8.1: half-open [start, end), single segment within one day, crossing split into segments), and a scheme MUST NOT change that interpretation, only evaluate on top of it.¶

8.5. Resolving residual obligations (Resolve)

Section 8.4 delivers residual obligations but leaves the consumer's feedback loop undefined. Resolve closes it: a consumer reports, per obligation, whether it is satisfied, violated, or still unknown, and the core collapses the result to a fresh decision.¶

Resolution = { constraint: string,
               status: "satisfied" | "violated" | "unknown" }
Resolve(decision, resolutions, now?) → Decision

decision is a Section 9 Decision; resolutions is an ordered list (possibly empty) of Resolution; now is an optional UTC instant (RFC3339, Z). now is the only input that lets the core tick a residual itself.¶

Algorithm, in order:¶

1. Terminal verdicts are fixed. If decision.verdict is deny or allow, Resolve returns decision unchanged and ignores resolutions: a deny is never revived and an allow carries nothing to discharge.¶

2. Malformed input fails closed. An entry that violates the grammar above (unrecognized status, empty/non-string constraint) → deny with invalid_resolution; a now that is not a valid instant → deny with invalid_timestamp.¶

3. Discharge on allow_unresolved. Let O = decision.unresolved (already normalized and sorted, Section 8.4). For each o ∈ O, a status in {satisfied, violated, unknown} is computed by combining the sources below under the order violated ≻ satisfied ≻ unknown (the most restrictive source wins — a consumer that reports violated is never overridden by a lenient one, and the core clock is never overridden by a lenient assertion):¶

   • Core clock — if o is a core-recognized varwof/constraint-v1:time obligation whose value is a Section 8.1 window array, and now is supplied, the core evaluates it: now inside a segment → satisfied; outside every segment → violated. This is the obligation's TTL: the discharge horizon is the end of the segment containing now, so re-invoking Resolve with a later now re-evaluates to violated once the window has passed — a cached allow does not outlive its window.¶

   • Consumer resolution — a Resolution for o contributes its status; the most restrictive of the two wins.¶

   • Absent everywhere → unknown.¶

4. Repeated entries for the same constraint combine under the same violated ≻ satisfied ≻ unknown order.¶

5. Unrelated resolutions are ignored. A Resolution whose constraint is not in O cannot widen the outcome; O is authoritative.¶

6. Result:¶

   • any o has status violated → deny, reason = that constraint's {type}:violated (time:violated for a core-clock violation; otherwise the type segment of the constraint string), unresolved = [];¶

   • every o is satisfied → allow, reason null, unresolved = [];¶

   • otherwise → allow_unresolved, reason null, unresolved = the still- unknown subset (normalized + sorted, Section 8.4).¶

Without now, the core attaches no TTL to a time:window obligation: a consumer may report it satisfied (its declaring scheme owns its clock), but that discharge is only as fresh as the call, and a consumer that needs a core-enforced horizon MUST pass now.¶

Acting on a result (caching rule). Resolve returns a plain decision; it does not carry an expiry field, so a core-clock discharge is only valid for the instant of the call. A consumer that acts on a Resolve result involving a core-evaluated time:window obligation MUST either re-invoke Resolve with a current now immediately before acting, or not cache the result beyond the current segment's end (the discharge horizon, Section 8.5 step 3) — it MUST NOT hold a cached allow past that horizon. Equivalently: a suite that needs a mechanically enforceable "valid until" value derives it from the segment end itself, not from the returned Decision. (The obligation carried on an allow_unresolved decision remains the Section 8.4 object a consumer evaluates; this rule is only about not outliving a clock-based discharge.)¶

Resolve is deterministic and fail-closed; it is idempotent (Resolve(Resolve(d, r, now), r, now) = Resolve(d, r, now)) and monotone (adding a violated never turns a deny into an allow; removing one never turns an allow into a deny). It neither invents nor drops obligations. It subsumes the coarser identity-level consumer gate (the reference implementations' Discharge, which only answers "do I understand and commit to every obligation?"): confirming an obligation is the satisfied case. It defines no policy about how the consumer evaluates an obligation (P2) — that is the declaring scheme's (Section 11).¶

9.1. Resolved Reason Ordering (normative)

When more than one condition fails for a grant/operation pair, the resolved reason (the single code reported) is the first applicable layer in this fixed order. It applies to Entails (Section 6.3), Intersect (Section 7) and Authorize (this section).¶

Notes:¶

• Namespace is scheme:action_class (the first two :-delimited segments). Identifiers in the same namespace differ only below the Class; such mismatches are path-level (literal_mismatch / wildcard_requires_trailing_segment), not different_namespace.¶

• Params normalization fires at the input boundary: duplicate keys, over-precision/non-finite numbers, and size/depth overruns (Section 6.2) are detected before any grant-vs-operation comparison and therefore before every other layer of this table.¶

• Deny-when-declared: layer 5 is evaluated on the grant/intersection side — an explicitly empty [] or {} param value denies the class regardless of the request, before any member or bound check.¶

• params:{} ≡ absent: the params constraint looks only at the set of declared param names, independent of carrier form — an absent params and "params":{} both mean "no param names declared" = no param constraint (consistent across entailment and intersection; the same representation cannot have different semantics in different functions). Therefore:¶

  • Direct grant: a grant with params:{} allows an op carrying any params (.{x:1} does not trigger undeclared_param);¶

  • Intersection: a params:{} source contributes no param constraint ({limit:50} ∩ {} = {limit:50});¶

  • Key closure (next bullet) applies only when the grant declares a non-empty set of param names.¶

• Layer 7 key closure runs both directions: granted keys must be present in the operation (params_missing) and operation keys must be declared by the grant (undeclared_param); the missing-key check resolves first, and both precede the layer 8–9 value checks. (Applies only to a non-empty set of declared names, see the bullet above.)¶

• Layer 11 runs last by construction: constraints are evaluated only after coverage and parameters pass.¶

• Multi-grant aggregation (normative): Authorize operates on a ordered list of grants, not a single grant. Authorization semantics are order-independent; only reason selection (rule 4) uses the input order. Rules:¶

  1. Any one covering-and-allowing grant allows (∃ g: Entails(g,op) ∧ no params-layer rejection ∧ no constraint-layer rejection);¶

  2. Residual obligations = unresolved union across the covering grants that allow (normalized + sorted). A covering grant rejected at the params/constraint layer contributes none — it does not authorize, so its residuals are not carried (they are never silently dropped from a decision it does not produce);¶

  3. No grant covers → capability_not_authorized; op layer-1 errors always precede any coverage/aggregation decision;¶

  4. Some grant covers but all covering grants reject at the params/constraint layer → deny, reason = the layer 5–11 rejection reason of the first covering grant in canonical order (deterministic). Canonical order = the appearance order in the input grant list (the capability-record body order); an implementation MUST NOT choose the reason by internal hash/iteration order. Counter-examples pinned (forbidden): NOT any-one-allows — otherwise, with multiple grants held, a narrow grant would wrongly deny the legal operation of a broad grant; NOT first-match-wins — otherwise grant order would change the authorization outcome; NOT all-must-pass — synonymous with "any-one-covers authorizes", letting a narrow grant's existence invalidate a broad grant.¶

• Op-ID validation errors propagate their specific layer-1 code (missing_capability_id / unsupported_wildcard / invalid_capability_id), never capability_not_authorized and never an invented catch-all: step 1 reports the very code that describes the operation id. Only coverage failures (layers 3–4 and 10) collapse to capability_not_authorized.¶

• Layer 1 validates the operation id only. A malformed id in a grant makes that grant non-matching for every operation: Entails reports the specific layer-1 code as its false reason, and Authorize folds the non-match into coverage (capability_not_authorized) — the grant's own code is not surfaced by the decision.¶

• An absent/empty effective grant drops straight to layer 10 (capability_not_authorized); the evaluator MUST return this decision rather than raising. An absent operation drops to layer 1 (missing_capability_id).¶

• A language revision mismatch (Section 12.1) is resolved before any layer and reports unsupported_language_revision (fail-closed, no downgrade).¶

• Resolve (Section 8.5) is post-decision, not a layer. It consumes a Decision and never re-runs Authorize; only invalid_resolution / invalid_timestamp (Section 9.2) and a {type}:violated obligation result are introduced by it, and only on an allow_unresolved input.¶

9.2. Reason Codes (normative)

Reason codes are stable identifiers. v1 defines:¶

Canonical code = everything before the first :. An implementation MAY append : <detail> (e.g. the offending parameter name) as a diagnostic suffix; the canonical code is unchanged. All tooling and compatibility checks MUST compare the canonical prefix only.¶

Other schemes MAY define additional codes, but MUST NOT redefine these.¶

12.1. Language Revision

Every implementation declares a language revision CLC-<major>.<minor> — this document declares CLC-1.15. A capability input (grant, operation, or OCM) SHOULD carry the revision it was authored against; an input without a declared revision is treated as CLC-1.0.¶

• Compatible reading: an implementation MAY evaluate an input whose declared major equals its own AND whose declared minor is ≤ its own (so an implementation of CLC-1.3 reads a CLC-1.0/1.1/1.2/1.3 input, but not CLC-1.4 or CLC-2.0).¶

• CLC-1.2 is additive: it adds the unresolved field to the Decision shape and the invalid_constraint reason code without changing v1 verdicts on existing inputs; a CLC-1.1 implementation MAY claim CLC-1.1 against this document but is not CLC-A conformant (Section 12) until it exposes unresolved and rejects non-conforming recognized-type values.¶

• CLC-1.3 is additive, with one verdict value re-scoped: it adds the allow_unresolved verdict value, closes the decision loop for residual obligations, and re-scopes allow to mean "fully enforced" only; allow/deny outputs on inputs with no residual obligations do not change. A CLC-1.2 implementation MAY claim CLC-1.2 against this document but is not CLC-A conformant (Section 12) until it emits the allow_unresolved value and applies the Section 8.1 (scheme,type) identity and cross-midnight window grammar.¶

• CLC-1.9 is additive: it adds the containment relation and conformance class CLC-D (Section 13) without changing any CLC-A verdict, reason code or vector. A CLC-1.8 implementation that does not claim CLC-D MAY claim CLC-1.8 against this document and remains CLC-A conformant; an implementation that claims CLC-D MUST pass containment-vectors.json (Section 12).¶

• CLC-1.10 is additive with a minor gate: it adds the optional param_bounds field and its four reason codes (Section 6.5). Every input that declares no param_bounds is unchanged, so a CLC-1.10 implementation reads every CLC-1.x input. An input that uses param_bounds MUST declare CLC-1.10 or later; an implementation that does not implement Section 6.5 MUST refuse such an input through the minor gate (unsupported_language_revision) and MUST NOT ignore the field — silently dropping bounds would grant more than the input declares (fail-closed).¶

• CLC-1.11 is additive: it adds the Resolve function (Section 8.5) and its two input-error reason codes (invalid_resolution, invalid_timestamp) without changing any Authorize verdict, reason code or vector. A CLC-1.10 implementation that does not implement Resolve MAY claim CLC-1.10 against this document and remains CLC-A conformant; Resolve is exercised only when a consumer feeds a decision back, so no input shape is reinterpreted. A time:window obligation is still delivered as allow_unresolved (Section 8.4) — the core clock evaluator of Section 8.5 runs only inside Resolve with a supplied now.¶

• CLC-1.12 is additive: it adds the derived function ConstraintUnion (Section 7.1) without changing any other relation, verdict, reason code or vector. The function is exactly the constraint projection of Intersect rule 3, so Intersect's output is unchanged; an implementation that does not implement ConstraintUnion MAY claim CLC-1.11 against this document and remains CLC-A conformant.¶

• CLC-1.13 is additive and CLC-D-scoped: it adds AuthorizeWithChain (Section 13.11), a CLC-D function that fixes the order of Contains and Authorize over an effective-chain Intersect. It changes no CLC-A verdict, reason code or vector; an implementation claiming only CLC-A is unaffected, and a CLC-D implementation adds it to its CLC-1.9-era Contains surface.¶

• CLC-1.14 is additive: it defines the intersection of param_bounds (BoundMeet, Section 6.6) so that Intersect can combine a grant carrying the bounds Section 6.5 defines. It changes no verdict, reason code or vector for an input without param_bounds; it changes the refusal of an input with param_bounds from invalid_params_binding to the correct meet or empty-meet result. An implementation that does not implement Section 6.6 MUST refuse a param_bounds input through the minor gate rather than intersect it wrongly. Honest scope of that change (noted in rev CLC-1.15). One subset of inputs does not evaluate identically across the CLC-1.10→1.14 minor range: the inputs that declare param_bounds and reach a relation that meets them — Intersect (Section 7) or AuthorizeWithChain step 3 (Section 13.11) — with two or more sources declaring a Bound for the same key. On that subset the direction of the change is deny → allow: what CLC-1.10–1.13 uniformly refused (invalid_params_binding) becomes the correct meet result (usually an allow-side effective grant); where the meet is empty, the denial's reason changes from invalid_params_binding to no_overlap. Entailment against a single grant (Entails/Authorize), containment, and every input without param_bounds are verdict-stable across the whole 1.x range. The compatible-reading rule above is therefore intact — it governs readability, not verdict stability — but verdict stability across minor revisions does not hold for that one subset, and a consumer MUST NOT assume it. (Rev CLC-1.15 moves the same subset again, in the opposite direction, for cross-family meets only; see its entry below.)¶

• CLC-1.15 is a corrective revision (review-driven; see the Revision History): the cross-family numeric ∩ enum meet exception of CLC-1.14 is removed, so every numeric × enum meet refuses with invalid_params_binding in either source order (Section 6.6); enum membership equal is defined as JSON type-sensitive equality (Section 6.5 layer 8); ConstraintUnion's deterministic ordering is pinned to UTF-8 byte order (Section 7.1); delegation_mode_not_narrower is attributed to the binding profile's mode pre-check and moved out of the core reason commitments (Section 13.4.5, Section 13.5, Section 13.6, Section 13.11); Contains antisymmetry is stated on semantic equivalence classes (Section 13.3); and AuthorizeWithChain states the caller's complete-authenticated-root-first-chain obligation (Section 13.11). It changes no verdict, reason code or vector for an input without param_bounds. On the Section 6.6 meet subset the direction partly reverses CLC-1.14: a cross-family numeric × enum intersection that CLC-1.14 reduced to a filtered enum — an allow-side effective grant — now refuses (allow → deny, invalid_params_binding), because the filtered enum was broader than either source (Section 6.6); same-family meets are unchanged. The same review adjudicated the scalar × nested pair (numeric or enum vs. object, either order) to the same cross-family refusal: that pair was already denied in CLC-1.14 (as no_overlap), so the direction there changes the reason code only (→ invalid_params_binding), not the verdict (Section 6.6, design-notes D12). The Section 8.4 residual-obligation list and the Resolve output re-use the Section 7.1 UTF-8 byte-order collation; an implementation whose native default ordering is UTF-16 code-unit order MUST apply the pinned comparison explicitly. An implementation that does not apply this revision MUST declare CLC-1.14 or earlier and let the minor gate (Section 12.1) resolve any input that relies on the corrected behavior.¶

• CLC-A conformance and the minor gate are the two sides of one rule. Claiming CLC-A (this section) means implementing the CLC-A-relevant semantics of the revision claimed — so an implementation that advertises CLC-1.15 MUST implement param_bounds (grammar and the Section 6.6 meet), Resolve, ConstraintUnion and the Section 6.2 canonicalization, not merely tolerate their inputs. The minor gate is the complement for an implementation that lags: it declares an older revision and refuses any input that uses a field or function introduced after it. The two MUST agree — an implementation MUST NOT claim a revision higher than it implements (which would silently evaluate newer inputs), nor claim CLC-A while refusing a well-formed input of its own declared revision.¶

• Incompatible reading MUST fail closed with deny("unsupported_language_revision"). An implementation MUST NOT silently evaluate under a different revision — no downgrade, no warning-then-allow.¶

• The revision check resolves before any Section 9.1 layer and yields the single resolved reason code unsupported_language_revision.¶

Vectors: revision-001 (input CLC-1.0 against an implementation declaring CLC-1.3 → eval normally, allow); revision-002 (input CLC-2.0 → deny unsupported_language_revision).¶

13.1. Motivation

The two relations the core defines answer different questions:¶

• Entailment (Section 6.1): does an operation fit inside a grant?¶

• Intersection (Section 7): what is the effective set when several grants cover one authority?¶

Neither answers the question a delegation chain asks of every hop: is the child's declared grant inside the parent's declared grant? Intersection delivers a set that is necessarily common to the sources, but a result fitted to two grants proves nothing that one of the grants' boundaries would not also authorize on its own — it reasons about the combined set, not about a child that must be a subset of a specific parent.¶

The AIC ecosystem needs the child-parent question at two concrete boundaries:¶

1. Delegation (DelegationAuthTBS vs. a principal's grant): a sub-agent's requested capabilities, constraints and delegation mode must lie inside what the principal authorized. Without a shared relation this obligation is the profile's job and is re-implemented per profile, so two profiles can differ on the same sub-agent grant.¶

2. Publication bound (rule signing): a rule a certificate holder publishes must not exceed the holder's own grant. This section states the general relation; register/ruleexec already applies the same idea in one instance (RuleWithinSignerGrant), and is a candidate early adopter.¶

Containment is intentionally additive, not a CLC-v2 feature: it does not change any CLC-A verdict, does not touch the CLC-A corpus, and can be adopted by any implementation that claims CLC-A without breaking compatible reading of existing inputs.¶

13.2. Terminology and Notation

Grant and Operation are as defined in Section 2/Section 5 (identifier per Section 3, parameters per Section 6.2, constraints per Section 8). Contains(GP, GC) names the relation parent GP × child GC.¶

• Declared set — the parameters a grant carries as constraints on operations (Section 6.2 value semantics: numbers bind as upper bounds, arrays as membership sets, objects recursively per key, explicit empty []/{} deny the class, {}≡absent).¶

• Bound — a declared constraint value as interpreted by Section 6.2/Section 8.1 value semantics.¶

• Narrower — a child grant is narrower than its parent when every value it declares is within the parent's declared bounds and its key set is closed by the parent's. Where the carrier defines a delegation mode, the child's mode must not widen the parent's either — that half is the binding profile's pre-check, not part of the language relation (Section 13.4.5).¶

• Mode lattice — an abstract carrier-defined order over delegation modes, exercised by the binding profile's pre-check (Section 13.4.5), never by Contains; the AIC-JWT ordering is pinned in Section 13.8.¶

13.3. Relation Signature

Contains(GP: Grant, GC: Grant) -> ContainmentResult

ContainmentResult = {        // JSON object (not ASN.1)
  "contains": <boolean>,     // false <=> one of the Section 13.4 layers failed
  "reason":   <string>       // resolved reason code (core Section 9.2 code)
}

• contains is true only when every layer of Section 13.4 passes.¶

• reason on success is empty; on failure it carries the first failing layer's reason code, per Section 13.4 layer order (deterministic: input order of the two grants never influences which layer reports first).¶

• The relation is antisymmetric on semantic equivalence classes, not on Grant objects: Contains(A,B) and Contains(B,A) both hold exactly when A and B fall in the same class — they denote the same identifier coverage, the same declared parameter key set and the same bounds under the Section 6.2/Section 6.5 value semantics, with surface-equivalent spellings identified (params:{} ≡ absent, Section 6.2). Two syntactically different Grant objects in one class (an equivalence, not an identity of JSON text) therefore contain each other; containment of grants in two distinct classes in both directions is a contradiction and MUST NOT be reported. Delegation modes are not part of the relation (Section 13.4.5), so mode equality is neither required nor observable here — where a carrier binds modes, the profile's pre-check owns that comparison.¶

13.4. Containment Algorithm

The relation resolves layers strictly in order; the first failure determines the reason code. Every layer is fail-closed: any doubt yields false.¶

13.5. Reason Codes

CLC-D registers exactly three child-level reason codes; two of them are returned by the relation, and everything else a Contains result carries reuses CLC-A codes. The third is produced only by the binding-profile delegation-mode pre-check (Section 13.4.5): the relation takes no mode argument and MUST NOT return it. An implementation MAY collapse child_exceeds_parent for identifier failures into the core's capability_not_authorized at a boundary that must not reveal policy shape (Section 11), but MUST NOT collapse params_not_narrower; a profile that maps a mode-carrying carrier MUST NOT collapse delegation_mode_not_narrower either.¶

There is deliberately no constraint reason code: constraints are not part of the relation (Section 13.4.4).¶

13.6. Conformance Class CLC-D

CLC-D is an optional conformance class stacked on CLC-A. A conforming implementation:¶

• MUST implement Contains (Section 13.4) and the relation's two Section 13.5 reason codes, and pass the CLC-D corpus (Section 13.7); where the implementation also ships a binding profile for a mode-carrying carrier, that profile owns the delegation_mode_not_narrower pre-check (Section 13.4.5);¶

• MUST (rev CLC-1.13) implement AuthorizeWithChain (Section 13.11) and pass the authorize-chain-vectors.json corpus, so the one-call chain check is exercised by the same class that owns containment;¶

• MUST NOT alter any CLC-A verdict, reason code, or the CLC-A corpus — this section is strictly additive;¶

• MUST treat containment as declared-set comparison: it declares no consequence about execution lifecycle, time windows after the fact, or post-hoc bounds; where a binding profile cannot establish containment at delegation time, the profile MUST NOT authorize.¶

An implementation claiming CLC-A does not claim CLC-D. A delegation profile (a binding profile (Section 13.8), an AIC-JWT DA validator, a certificate-issuance stack) that needs the boundary check SHOULD require CLC-D of the module it delegates to, and MUST NOT substitute intersection (Section 7) for containment.¶

Implementation status (single-author parity). Contains is implemented in all three reference implementations (Go: register/semantics.Contains; Python: aic-capability-demo/clc_semantics.py contains; TypeScript: ts/clc_semantics.ts contains) and mirrors the cases this section pins. Agreement between implementations that share an author is a regression test for this text, not independent validation — the Section 12 honesty rule applies unchanged to CLC-D (see Section 13.7).¶

13.7. Corpus

Because CLC-D is a new relation, its corpus is new and independent of the CLC-A suites (vectors.json / property-cases.json / crosswalk-vectors.json / evidence-vectors.json). The corpus ships as capability/data/_vectors/clc-d/containment-vectors.json (64 vectors) and a forward-closure property file capability/data/_vectors/clc-d/containment-property-cases.json (784 cases × 39 shared operations, generated by capability/scripts/gen-contain-property-cases.py), plus a cross-walk corpus capability/data/_vectors/clc-d/containment-crosswalk-vectors.json (44 vectors) that maps a carrier's native representation (AIC-JWT DA, OAuth RAR, UCAN, delegation chain, and the adjacent agent drafts ATN, AAT, AIP, AAE, AOA, AEGIS) to a grant on each side and asserts Contains (Section 13.9.3). Rev CLC-1.13 adds capability/data/_vectors/clc-d/authorize-chain-vectors.json (15 vectors) pinning the fused AuthorizeWithChain relation (Section 13.11). The vectors cover:¶

• identifier coverage (layer 2): trailing-wildcard coverage, namespace mismatch, depth mismatch, same-length literal mismatch, unsupported_wildcard kept stable, wildcard-requires-a-trailing-segment;¶

• parameter narrowing (layer 3): number upper bound at/under/over, enum subset / element-absent / scalar-member, empty child enum under non-empty parent, parent empty set deny-class, key-closure violation in both directions (child omits, child adds), nested object recursion and nested key closure, child {} under bounded parent, child null (layer-1 grammar), unconstrained parent {};¶

• constraint non-participation (Section 13.4.4): a tighter, wider, added, dropped, or differently-identified child constraint, and a child constraint the parent lacks — every one MUST leave the verdict unchanged (all assert contains);¶

• validity (layer 1): malformed parent/child identifiers, null params;¶

• symmetry: both-directions containment identity, antisymmetry probe pair (contain-040/041), a fully-narrower combined grant.¶

The delegation-mode lattice is not part of the language-level corpus: the relation Contains(GP, GC) takes no mode, so a profile that binds a carrier mode (the AIC-JWT DA validator, Section 13.8) exercises it itself. The language corpus therefore ships no mode vectors; a carrier adopting CLC-D MUST add mode vectors to its own profile corpus.¶

The property the property corpus checks is forward closure: for every (parent P, child C) and every operation o in the shared sample, Contains(P, C) MUST NOT raise, and Contains(P, C) ∧ Entails(C, o) ⟹ Entails(P, o). This is the declared-set consequence that makes a delegation boundary sound, and the reason the Section 13.5 collapse of layer-2 failures into child_exceeds_parent cannot weaken the boundary. On the shipped corpus the Go and Python/TS runs report the same 120 contained pairs and 30576 operation checks with zero violations.¶

The parity bar and the "independence of implementations" honesty rule of Section 12 apply unchanged to CLC-D: until two independent implementations agree, the corpus is evidence that this text is implementable, not that it has been independently interpreted.¶

13.8. AIC-JWT / AIC Certificate Binding

This subsection is a cross-walk profile of the relation, not part of the language. At the AIC delegation boundary the parent grant is produced from the principal's authorization and the child grant from the DelegationAuthTBS/AIC-JWT DA capabilities:¶

• Parent grant GP: the principal's capability entry (scheme:id params), plus principal-level authorizationConstraints projected as parent constraints, plus the principal's own delegation mode.¶

• Child grant GC: the sub-agent's requested capability (Capability.SchemeId:CapabilityId, Parameters), its authorizationConstraints, and its DelegationMode.¶

• Boundary result: P_effective = P_principal ∩ C_agent ∩ P_gateway keeps its intersection meaning — intersection determines the effective set; containment (Section 13.4) is the per-child admission predicate that runs before the intersection is composed, on each (parent-capability, child-capability) pair. The child's constraints are not compared by containment; they are carried forward by the intersection's union (Section 13.4.4), so the principal's constraints remain in force in P_effective.¶

• A sub-agent that requests a capability the principal did not grant fails at layer 2 (child_exceeds_parent); a sub-agent whose requested params exceed the principal's declared bounds fails at layer 3; a sub-agent that widens the carrier's delegation mode fails the lattice (Section 13.4.5). Binding profiles MUST surface the reason code into their audit trail, and MUST compose the intersection so the principal's constraints stay in force.¶

13.9. Related Work and Positioning

This subsection is informative and carries no requirements. It records why a language-level containment relation is needed at all, how CLC relates to the authorization work already in flight, and what the adoption risks are.¶

13.10. Open Issues

Section 13.10 records the consciously-deferred gaps surfaced in review; the items already landed as core revisions are marked closed, the rest are recorded for later discussion. Items marked candidate v1.x are candidates for the core language to adopt without breaking CLC-A inputs; items under "CLC-D" would extend containment itself.¶

13.11. AuthorizeWithChain (fused chain authorization)

Contains is a declared-set comparison and Authorize is an operation-time decision; a delegating consumer that has a chain often wants both in one call. AuthorizeWithChain is that convenience, defined at the CLC-D layer:¶

AuthorizeWithChain(chain, op) → Decision      // chain = ordered Grant[], root first

1. An empty chain fails closed: deny("absent_source") (Section 7 rule 5).¶

2. For each adjacent pair (chain[i], chain[i+1]), evaluate Contains (Section 13.4). The first hop that is not contained ends the call with deny(reason), where reason is that hop's Section 13.5 code — child_exceeds_parent or params_not_narrower, the two codes the relation can return; delegation_mode_not_narrower never appears here, because the chain gate calls Contains, which takes no mode argument (Section 13.4.5). This chain gate runs before op validation: a broken chain is reported even when the operation is also absent, because the chain is the subject of this function.¶

3. Otherwise compute the effective chain grant G = Intersect(chain...) (Section 7). Because constraints are outside containment (Section 13.4.4), this step is what brings every ancestor's params and constraints into force — authorizing against the leaf grant alone would let an operation pass that violates an ancestor's constraints (the union axis is not in Contains). An Intersect refusal (no_overlap, empty_bound_denies_class, invalid_params_binding) is returned as deny(reason).¶

4. Return Authorize(G, op) (Section 9) unchanged — allow / allow_unresolved / deny with its own Section 9 reason codes.¶

Caller obligation. AuthorizeWithChain evaluates the chain as presented: the caller MUST supply the complete, authenticated, root-first chain. The function fetches no missing link, verifies no signature or trust anchor, and detects no truncation or reordering — a verdict over a truncated, reordered or unauthenticated chain is a verdict about the presented sequence, not about the delegation it does not carry (authentication is the carrier's concern, Section 11). This obligation adds no decision rule: the steps above are unchanged by it.¶

AuthorizeWithChain is a CLC-D function: it is not part of CLC-A, and an implementation claiming only CLC-A is unaffected. It introduces no new core semantics — it fixes the order of two existing relations and refuses fail-closed at each step. A chain carrying param_bounds is authorizable: step 3's Intersect(chain...) combines the hops' bounds with the Section 6.6 meet, so an ancestor's bound (e.g. max:100) stays in force over a narrower child (e.g. max:50). Because Section 13.4.3 requires the declaration site of every key to match at each hop, a valid chain never presents the cross-site case Section 6.6 refuses. The two-grant form AuthorizeWithChain(parent, child, op) named in Section 13.10.4 is the degenerate case chain = [parent, child].¶

13.12. Revision and Governance

Containment is folded into this document's revision stream: its changes are recorded in the Revision History and its conformance class CLC-D is declared in Section 12.1 in step with the language revision (this revision is CLC-1.15; CLC-D first appeared in CLC-1.9, folded from EXT-00 rev 0).¶

• A CLC-A input is unaffected by the addition of CLC-D; compatible reading of CLC-A inputs is the floor.¶

• CLC-D adoption is per-implementation: an implementation may claim CLC-A without claiming CLC-D.¶

• The corpus (64 containment vectors, 784 property cases, 44 cross-walk vectors, 15 AuthorizeWithChain vectors) is a draft snapshot; the README in capability/data/_vectors/clc-d/ maintains the live count and the date the snapshot was generated.¶

17.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC7493]

Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/rfc/rfc7493>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

17.2. Informative References

[AIC-JWT]

Wei, J., "AI Agent Identity Certificate (AIC) JSON Web Token Profile", September 2026, <https://datatracker.ietf.org/doc/draft-wei-aic-jwt/>.

[EMILIA-AEB]

Schrock, I., "The Action Evidence Boundary for Consequential Agent Effects", Work in Progress, Internet-Draft, draft-schrock-action-evidence-boundary-07, September 2026, <https://datatracker.ietf.org/doc/draft-schrock-action-evidence-boundary/>.

[AEC]

Schrock, I., "Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence (EP-AEC)", Work in Progress, Internet-Draft, draft-schrock-ep-authorization-evidence-chain-06, September 2026, <https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-evidence-chain/>.

[BCR]

Schrock, I., "Bounded Capability Receipts and Durable Spend Control for Agent Actions", Work in Progress, Internet-Draft, draft-schrock-ep-bounded-capability-receipts-06, September 2026, <https://datatracker.ietf.org/doc/draft-schrock-ep-bounded-capability-receipts/>.

[PAP]

Baur, T., "Principal Agent Protocol (PAP)", Work in Progress, Internet-Draft, draft-baur-pap-02, June 2026, <https://datatracker.ietf.org/doc/draft-baur-pap/>.

[ASOR]

Asor, R., "Verifiable Attenuated Delegation for AI Agent Chains", Work in Progress, Internet-Draft, draft-asor-wimse-agent-delegation-chain-01, September 2026, <https://datatracker.ietf.org/doc/draft-asor-wimse-agent-delegation-chain/>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[CAID]

Schrock, I., "The Canonical Action Identifier (CAID)", Work in Progress, Internet-Draft, draft-schrock-canonical-action-identifier-03, September 2026, <https://datatracker.ietf.org/doc/draft-schrock-canonical-action-identifier/>.

[ATN]

"Agent Trust Negotiation", n.d., <https://datatracker.ietf.org/doc/draft-somoza-dmsc-atn-agent-trust-negotiation/>.

[AAT]

"OAuth 2.0 Attenuating Agent Tokens", n.d., <https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/>.

[AIP]

"Agent Identity Protocol", n.d., <https://datatracker.ietf.org/doc/draft-prakash-aip/>.

[AAE]

"Agentic Trust Agent Authorization Envelope", n.d., <https://datatracker.ietf.org/doc/draft-kroehl-agentic-trust-aae/>.

[AOA]

"Agent Operation Authorization", n.d., <https://datatracker.ietf.org/doc/draft-liu-agent-operation-authorization/>.

[EVC]

"External Verifier Contract", n.d., <https://datatracker.ietf.org/doc/draft-kondoju-evc/>.

[CLC-CORPUS]

Wei, J., "Capability Language Core -- conformance corpus, schemas and working documents", September 2026, <https://github.com/varwof/capability/tree/b15b51b8f94125b7a00aa281f98405806e6ea95c>.

[AEGIS]

"AEGIS Governance (AIAM-1 v0.1)", n.d., <https://github.com/aegis-initiative/aegis-governance>.

B.1. Syntax (9 vectors)

B.2. Entailment (8 vectors)

B.3. Params (39 vectors)

B.4. Intersection (10 vectors)

Shorthand: params shown compact; constraints use colon notation.¶

B.5. Decision (34 vectors)

B.6. Combined (11 vectors)

Total: 123 vectors¶

• Decisions D17–D28 are the corpus pin for the residual-obligation channel unresolved / allow_unresolved, the Section 8.1 (scheme,type) identity, the invalid_constraint value grammar and the Section 9.1 multi-grant aggregation. decide-025/-026 and syntax-007/-008 pin the Section 3 scheme grammar; decide-021/-022, decide-019/-024 pin Section 8.1 time/network value shapes; decide-019 pins the no-cross-midnight rule; decide-028/-029/-030 pin Section 9.1 ({}≡absent, any-allow union, deterministic deny reason); decide-035 (D29) pins multi-grant residual-obligation union across covering grants; decide-031/-032/-033/-034 (D31–D34) pin the Section 8.1 max_rows request-side value domain (rev CLC-1.4); decide-018 (D30) pins Section 3 wildcard-shape detection ahead of the base grammar.¶

• The corpus additionally carries 6 scheme stress-test vectors (clinical-001/-002, payments-001/-002, data-001/-002) exercised against std/{clinical,payments,data}-v1: their enum/bound outcomes follow the grouping rules above (→ B.3 params semantics), and payments-002 additionally exercises Section 8 fail-closed unknown_constraint for a scheme-scoped constraint type. These vectors add no new normative rule; they exist to record the v2 requirements evidence, not to extend v1. undeclared-001/-002 (→ B.5 D13/D14) pin the Section 6.2 key-closure rule. params-006/params-013 (→ B.3 P6/P13) close two previously-unmapped rows; params-020/021 (→ P20/P21) are the positive boundary cases of params-018/019; decide-016/017 (→ D15/D16) pin the Section 9.1 pre-check and layer-1 paths for absent/empty grant and id-less operation; intersect-007..010 (→ I7..I10) pin Section 7 rules 5–6 including empty-params sources, order independence, and a params-free identifier comparison; intersect-011/-012/-013 (rev CLC-1.15) are the cross-type audit pins of Section 7 rule 6 (string × number merge refusal, type-sensitive enum-member equality, 1.0 ≡ 1) and sit outside the B.1–B.6 tables, taking the corpus total to 123. B.5 row labels Dn are semantic row numbers, not corpus ids (D15/D16 ↔ decide-016/-017, D29 ↔ decide-035); D10 (absent/empty grant, operation present) has no dedicated vector — the pre-check path is pinned by decide-016 (D15).¶

B.7. Containment (external corpus)

The delegation-containment relation (Section 13) is pinned by a separate corpus at capability/data/_vectors/clc-d/: containment-vectors.json (64 vectors, groups: identifier coverage, parameter narrowing, constraint non-participation, validity, symmetry), containment-property-cases.json (784 forward-closure cases over 39 shared operations) and containment-crosswalk-vectors.json (44 cross-vendor vectors). It is not re-tabulated here; the corpus README maintains the live count and the snapshot date.¶

B.8. Extended parameter bounds (external corpus)

The Section 6.5 param_bounds grammar is pinned by capability/data/_vectors/clc-v1/param-bounds-vectors.json (43 vectors, groups: numeric interval/step, enum cardinality, optional keys, nested recursion, the binding rule, malformed bounds, scheme defaults), with param-bounds-vectors.schema.json. It is not re-tabulated here. These vectors exercise a CLC-1.10 field; a CLC-1.9 or earlier implementation refuses them through the Section 12.1 minor gate rather than ignoring the bounds. The JSON type-sensitive enum equality of Section 6.5 layer 8 (rev CLC-1.15) is pinned by the companion file param-bounds-equality-vectors.json in the same directory.¶

B.9. Resolve (external corpus)

The Section 8.5 Resolve function is pinned by capability/data/_vectors/clc-v1/resolve-vectors.json (26 vectors, groups: terminal pass-through, all-satisfied → allow, partial → allow_unresolved, violated → deny, the time:window core clock in and out of window, TTL re-evaluation, bare assertion without now, conflict precedence and malformed input), with resolve-vectors.schema.json. Vectors that exercise the core clock carry now; a CLC-1.10 implementation that does not implement Resolve is unaffected by this corpus.¶

B.10. ConstraintUnion (external corpus)

The Section 7.1 derived ConstraintUnion projection is pinned by capability/data/_vectors/clc-v1/constraint-union-vectors.json (12 vectors: union over one/many grants, duplicate folding across sources, deterministic ordering, empty constraints, and the empty-chain absent_source refusal), with constraint-union-vectors.schema.json. The UTF-8 byte-order collation pinned in rev CLC-1.15 (Section 7.1) — where UTF-16 code-unit order would diverge — is exercised by the companion file constraint-union-collation-vectors.json in the same directory.¶

B.11. AuthorizeWithChain (external corpus)

The Section 13.11 fused chain check is pinned by capability/data/_vectors/clc-d/authorize-chain-vectors.json (15 vectors: empty chain, broken identifier/parameter hop, a broken hop reported before op validation, the degenerate two-grant form, ancestor-constraint enforcement via the effective intersection, the param_bounds refusal, and pass-through of allow / allow_unresolved / operation-layer deny), with authorize-chain-vectors.schema.json.¶

B.12. BoundMeet (external corpus)

The Section 6.6 intersection of param_bounds is pinned by capability/data/_vectors/clc-v1/param-bounds-meet-vectors.json (groups: numeric min/max/step meet including the coarser-grid and fail-closed step cases, enum intersection and tightened cardinality, optional conjunction, nested recursion, the empty meets (min>max, disjoint enums — empty within one value family), the unrepresentable crosses (numeric∩enum in either order and scalar∩nested, refused since rev CLC-1.15; cardinality-only enum, incommensurable steps → invalid_params_binding), the identity empty Bound, and the cross-site refusal), with param-bounds-meet-vectors.schema.json. The rev CLC-1.15 meet invariant — every successful meet authorizes only what every source authorizes — is exercised by param-bounds-meet-property-cases.json in the same directory.¶

C.1. Vocabulary

C.2. Failure-code mapping

Carrier failure codes collapse onto CLC-D's three codes. The mapping is many-to-one and is therefore not reversible without the carrier recording which of its own codes applied before mapping.¶

The collapse is visible in the right column: child_exceeds_parent is reached by both AIP scope and AIP depth failures and by an ATN digest mismatch, and params_not_narrower by every carrier's bound-widening. A carrier that needs its own code back must keep it alongside the CLC-D reason; CLC-D guarantees the stable language-level reason, not the carrier's.¶

C.3. Profile obligations exercised by the corpus

Two of the Section 13.8.1 obligations are visible in the pinned vectors:¶

• Identity dimensions the language cannot carry fail closed. ATN's schema digest is carried as an identifier segment (ccx-043) rather than dropped, so a digest mismatch is child_exceeds_parent instead of a silent match.¶

• Semantics the relation cannot see are a profile limitation, not a CLC gap. AEGIS's allowed_roles/environment/risk_level and AAE's validity have no CLC field; the profile leaves them to the carrier and asserts nothing about them. They are not modelled here, and a profile MUST NOT claim containment of a dimension the relation cannot see.¶