TA-Normative:
Normative Constraint Protocol
RFC: TA-Normative Version: 0.1
Status: Preliminary / Experimental
Date: 2026-03-19 Authors: Robin
Martherus, Claude (Anthropic)
Table of Contents
- Abstract
- Status of This
Document - Terminology
- Introduction and
Motivation - Architecture Overview
- Data Model
- Protocol Flows
- 7.1 Flow 1 — Normative Evaluation (Pre-Intent-Binding)
- 7.2 Flow 2 — Continuous Re-evaluation on Context Change
- 7.3 Flow 3 — Escalation for Uncertain Evaluation
- 7.4 Flow 4 — Dual-Evaluation Protocol for Soul Vetoes
- Integration Points
- Worked Examples
- Security
Considerations - Privacy Considerations
- Open Questions
- References
1. Abstract
This document defines the Normative Constraint Protocol
(TA-Normative), a governance primitive for autonomous AI agent systems.
TA-Normative specifies the format, evaluation semantics, and enforcement
mechanisms for normative constraints: machine-enforceable rules that
evaluate agent purpose against organizational policy, regulatory
requirements, and ethical boundaries, operating independently of access
control authorization.
TA-Normative answers the question “should this agent do this?” — the
third governance layer above “can this agent do this?” (access control)
and “what has this agent declared it will do?” (intent declarations per
TA-Intent). The protocol defines two constraint effect types — soul
vetoes (binary S=1 denial regardless of trust score) and action risk
reclassifications (context-driven adjustment of A scores feeding the
physics enforcement pipeline) — and specifies how these outputs
integrate with the Kinetic Trust Protocol (KTP) enforcement
pipeline.
2. Status of This Document
This document is a Preliminary / Experimental
specification (v0.1). It is part of the Tamed Autonomy RFC set,
which defines governance primitives for the “Can / Why / Should” agent
control model.
This RFC is designated TA-original: it defines a full specification
with no normative dependency on existing KTP specifications, though it
is designed to integrate with KTP-Core, KTP-Enforce, KTP-Identity,
KTP-Federation, KTP-Emergency, and KTP-Governance.
This is design-stage thinking. The capabilities described —
particularly AI-mediated predicate evaluation, real-time context source
integration, and continuous re-evaluation on context change — are design
targets, not shipping implementations. All schemas, flows, and semantics
in this document are subject to revision as the architecture
matures.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119.
3. Terminology
Normative Constraint A machine-enforceable policy
rule that evaluates whether an agent’s declared intent is appropriate
given the current organizational, regulatory, and ethical context. A
normative constraint is distinct from an access control rule: access
control asks whether a principal is authorized to perform an action; a
normative constraint asks whether performing that action, in this
context and for this purpose, is consistent with organizational values
and obligations. A normative constraint produces one of two effect
types: a soul veto or an action risk reclassification.
Soul Veto A normative effect that sets the KTP Soul
Dimension flag S=1 for specific actions, causing those actions to be
denied unconditionally by the enforcement pipeline at step 2, regardless
of the agent’s trust score (E_trust) or tier. The soul veto is the
normative layer’s most powerful output: it overrides physics. A
triggered soul veto is recorded in the normative evaluation response and
carried in the agent’s trust proof, and it remains active until the
triggering context condition resolves or an authorized exception is
applied.
Action Risk Reclassification A normative effect that
dynamically adjusts the Action Risk score (A) assigned to a class of
actions, in either direction, based on context. Reclassification upward
raises A (making the action harder to perform at the agent’s current
trust level), effectively restricting access without a binary veto.
Reclassification downward lowers A (making the action easier to
perform), enabling safety-critical or time-sensitive actions that would
otherwise exceed the agent’s trust capacity. The reclassified A score
feeds directly into the physics check (step 4: A ≤ E_trust) in the KTP
enforcement pipeline.
Scope Restriction A normative effect that removes
entries from the agent’s approved intent scope — narrowing what
resources and action types the agent is authorized to use within its
declared intent. Scope restriction is applied when the normative engine
determines that parts of a declared scope are inappropriate in the
current context, even if the overall purpose is approved.
Conditional Approval A normative evaluation outcome
indicating that the declared intent is approved subject to one or more
runtime conditions: supervision requirements (a designated human must
pre-approve specific action classes), output review requirements (all
outputs must be reviewed before leaving the system), or scope conditions
(certain scope entries are activated only when a specified sub-condition
is met). Conditional approval is distinct from denial: the agent may
proceed within the conditions.
CEL Predicate A trigger condition expression written
in the Common Expression Language (CEL), a non-Turing-complete
expression language used by Google Cloud IAM, Kubernetes admission
webhooks, and Firebase security rules. CEL predicates in TA-Normative
are evaluated over a typed context object assembled from context source
signals. CEL’s non-Turing-completeness guarantees termination, making it
suitable for inline policy evaluation.
Context Source An authoritative external system that
supplies real-time signals to the normative evaluation engine. Examples
include HR systems (employment status), DLP/classification systems (data
sensitivity labels), legal hold management systems (active litigation
holds), regulatory calendars (quiet periods, audit windows), and
clinical databases (drug interaction severity). Context sources are
referenced in constraint trigger conditions and queried at evaluation
time. Context sources MUST be authenticated and their signals MUST carry
freshness metadata.
Constraint Authority The organizational role or
regulatory body that authored and approved a normative constraint.
Constraint authority is recorded in the constraint’s
authority block and used for precedence resolution and
audit. Only the constraint authority (or a designated delegate) may
create, modify, or delete a constraint — the normative evaluation engine
is an evaluator, not an author.
Precedence Tier The hierarchical classification of a
normative constraint that determines its priority when multiple
constraints conflict. Three tiers are defined, in descending precedence:
regulatory (constraints derived from law, regulation, or
judicial order), organizational (constraints derived from
company policy, approved by designated authority), and
departmental (constraints scoped to a specific department
or geography). Within a tier, conflicts are resolved by a configurable
conflict_resolution policy; the default is
most_restrictive_wins.
Normative Clearance The evaluation result issued by
the normative engine following assessment of an agent’s declared intent
against all applicable constraints. Normative clearance has three
possible levels: full (no constraints fired; intent is
approved without modification), conditional (one or more
constraints fired; intent is approved with restrictions, soul
constraints, or reclassifications applied), and restricted
(intent is denied; the declared purpose is impermissible in the current
context). Normative clearance is carried in the agent’s trust proof
(TA-TrustProof ta_extension.normative_clearance) and has an
associated expiry time.
Re-evaluation Trigger A context source event
subscription declared in the normative evaluation response, specifying
which context source events would cause the current clearance to be
re-evaluated. For example, a clearance issued when an agent is not on
notice period registers a trigger on the HR system’s employment status
change event. When the trigger fires, all active clearances registered
on that trigger are re-evaluated and updated clearances are pushed to
the enforcement pipeline.
Normative Engine The system component responsible
for receiving normative evaluation requests, fetching context signals
from context sources, evaluating applicable constraints against the
assembled context object, resolving conflicts across triggered
constraints, and returning a normative evaluation response. The
normative engine is an agent subject to KTP trust physics (it has its
own E_trust and is subject to the enforcement pipeline for its own
governance-level actions).
Dual-Evaluation The requirement that soul veto
generation (S=1 effect) be confirmed by a second, independent normative
evaluator instance before enforcement. Soul veto generation (S=1)
triggers the dual-evaluation protocol (Section 7.4). If both evaluators
agree or if the secondary evaluator times out, the veto proceeds to
enforcement. If the secondary evaluator disagrees, the veto is escalated
to human authority. This ensures soul vetoes are never silently
suppressed, while providing a confirmation check against false veto
generation.
4. Introduction and Motivation
4.1 The Three-Layer
Governance Problem
Autonomous AI agent governance requires three distinct questions to
be answered for each agent action:
-
Can this agent do this? — Does the principal
have authorization? Is the credential valid? Does the RBAC role include
this permission? This is the domain of access control: OAuth 2.0, RBAC,
ABAC, MCP authorization servers. -
What has this agent declared it will do? — Does
this specific action fall within the agent’s declared intent and scope
contract? This is the domain of intent declarations (TA-Intent), which
constrain an authorized agent to the purpose it declared before
acting. -
Should this agent do this? — Is this action
appropriate given the current organizational context, regulatory
environment, and ethical constraints? Even if the agent is authorized
(layer 1) and operating within its declared scope (layer 2), is this the
right action, now, for this purpose?
Current security infrastructure answers layer 1 well. TA-Intent (RFC
1 of this set) addresses layer 2. TA-Normative defines layer 3.
4.2
What Access Control and Intent Declarations Cannot Catch
Access control systems and intent declarations share a common
limitation: they are evaluated against a static view of the principal’s
authorization and declared purpose. They do not evaluate the suitability
of that purpose given the current state of the world.
Consider the following:
-
A departing senior engineer is fully authorized to access
architecture documents and algorithm specifications. Her credentials are
valid. Her intent declaration (“prepare knowledge transfer
documentation”) describes a legitimate-sounding purpose. No access
control rule is violated. No scope boundary is crossed. But the
combination of notice-period employment status and trade-secret data
access represents a normative violation that neither layer alone can
detect. -
A hospital medication agent is authorized to route prescriptions,
and its intent declaration scopes it to do exactly that. It is not
authorized to send physician alerts — that is outside its scope. But
when it detects a critical drug interaction, the right action is
precisely the one it cannot take. A rigid scope enforcement without a
normative reclassification mechanism would produce the wrong
outcome. -
A financial firm’s AI research agent has accumulated six months
of legitimate behavioral history. Its E_trust is high. Its declared
scope is broad but appropriate for its research function. Then a
compromised document causes it to begin querying M&A planning
documents. The trust score alone does not catch this immediately; it
takes behavioral drift to degrade. The intent contract catches the scope
violation, but only at the moment of the action.
These scenarios share a structure: the agent is authorized, the
action is within a plausible scope, and the harm comes from
purpose-context mismatch — the intersection of what the agent is doing
and what is happening in the world around it.
4.3 The Authorized Insider
Problem
The most difficult class of cases is what this document calls the
Authorized Insider Problem: an agent acting on behalf of a principal who
has valid credentials, legitimate history, and a plausible declared
purpose, but whose context has changed in a way that makes the declared
purpose impermissible.
This problem is characterized by the following properties:
- Authorization is genuine. The principal holds real
credentials for real resources. No credential theft, no token
forgery. - Intent is plausible. The declared purpose is the
kind of thing this principal legitimately does. “Prepare knowledge
transfer documentation” is a normal business task. - Scope is consistent. The resources in scope are
resources the principal regularly accesses. - The violation is purpose-level. The harm is not in
the individual access events but in the combination of purpose, context,
and aggregate outcome.
Access control cannot catch this because authorization is valid.
Intent declarations cannot catch this because the declared purpose is
plausible and scope is consistent. The only mechanism that can detect
purpose-context mismatch is a layer that evaluates the declared purpose
against the current organizational context — asking not whether the
agent can do this, and not whether the agent declared it would do this,
but whether the agent should do this given what is happening right
now.
4.4 Why a Separate Protocol
Is Required
The normative layer could theoretically be implemented as very
granular RBAC rules or as very restrictive intent scopes. There are two
reasons this does not work in practice.
First, context sensitivity is not expressible in static rules. A rule
that says “engineers may not access algorithm specifications” is too
broad — engineers need this access routinely. A rule that says
“engineers on notice period may not access algorithm specifications”
requires the access control system to be continuously updated with HR
status, and it still cannot express conditions like “unless supervised
by an engineering manager” or “except for documentation that predates
their hiring.” Normative constraints, with their CEL predicate
expressions and context source integrations, are designed precisely for
this class of condition.
Second, normative constraints cut in both directions. They are not
only restrictive — they also enable actions that would otherwise be
blocked. Action risk reclassification downward (as in the drug
interaction scenario) is a normative function: it says “this action,
which normally carries high risk, is appropriate in this context and
should be treated as low risk.” No access control or scope contract
mechanism can produce this. A scope contract can only permit or deny.
The normative layer can change the cost of an action based on
context.
5. Architecture Overview
5.1 Position in the Governance
Stack
TA-Normative sits at the governance layer, above intent declarations
and below the enforcement pipeline:
┌─────────────────────────────────────────┐
│ Constraint Authority │
│ (CISO, CMO, Legal, Regulatory Bodies) │
└──────────────────┬──────────────────────┘
│ Authors and approves constraints
▼
┌─────────────────────────────────────────┐
│ Normative Constraint Store │
│ (Signed, tamper-evident constraint │
│ repository — TA-Normative) │
└──────────────────┬──────────────────────┘
│
┌──────────────────▼──────────────────────┐
│ Normative Engine │
│ Evaluates intent + context against │
│ constraints; produces soul constraints │
│ and reclassifications — TA-Normative │
└──────────────────┬──────────────────────┘
▲ │
│ context signals │ soul constraints +
│ │ reclassifications +
┌─────────────┴───┐ │ scope modifications
│ Context Sources │ ▼
│ (HR, DLP, Legal, │ ┌──────────────────────────────┐
│ Clinical, ...) │ │ Governance Layer │
└─────────────────-┘ │ (Intent binding per TA-Intent)│
└──────────────┬────────────────┘
│ bound intent +
│ normative clearance
▼
┌──────────────────────────────┐
│ Enforcement Pipeline │
│ 1. Signature validation │
│ 2. Soul veto (S=1) │ ← TA soul constraints
│ 3. Tier gate │ feed step 2
│ 4. Physics (A ≤ E_trust) │ ← reclassified A scores
└──────────────────────────────┘ feed step 45.2 When Normative Evaluation
Runs
Normative evaluation MUST run at intent declaration time, before an
intent binding is issued. No intent binding SHALL be issued to an agent
without a corresponding normative evaluation. The normative evaluation
result (approved / conditional / restricted) determines whether the
intent is bound, what constraints are attached to the binding, and what
A score reclassifications apply to actions within the declared
scope.
Normative evaluation SHOULD also run continuously in response to
context source change events (re-evaluation triggers). When a context
source event fires that matches a re-evaluation trigger registered by an
active clearance, the normative engine MUST re-evaluate all affected
clearances and push updated constraints to the enforcement pipeline.
This enables normative governance to respond to changes in
organizational context that occur after an intent has been bound.
Normative evaluation MAY also be triggered by anomalous behavioral
signals from TA-Attestation — for example, an unusually high rate of
boundary-level scope matches suggesting that an agent is probing the
edges of its declared scope.
5.3 Outputs and Their Targets
The normative engine produces three classes of output from an
evaluation:
Soul Constraints feed into the enforcement pipeline
at step 2 (soul veto check). They are binary: S=1 means the specified
class of actions is denied unconditionally regardless of trust score or
tier. Soul constraints are carried in the agent’s trust proof under
ta_extension.normative_clearance.soul_constraints_ta. They
remain active until the triggering context condition resolves or an
authorized exception (co-approval) is applied.
Action Risk Reclassifications feed into the
enforcement pipeline at step 4 (physics check). They replace the
baseline A score for a specified action pattern with a reclassified A
score. Reclassifications may be upward (risk elevation, making an action
harder to perform) or downward (risk reduction, enabling safety-critical
or context-appropriate actions). Reclassified A scores are applied
before the physics check; the enforcement pipeline uses the reclassified
value, not the baseline canonical class value.
Scope Modifications feed back into the intent
binding (TA-Intent). The normative engine may remove scope entries
(scope restriction) or add temporary scope entries (scope amendment for
emergency reclassification scenarios). Scope modifications are reflected
in the bound intent before it is issued to the agent.
6. Data Model
6.1 Normative Constraint
Object
A normative constraint is a persistent, signed policy object stored
in the normative constraint store. Constraints are authored and approved
by constraint authorities and are not modifiable by the normative
evaluation engine. The normative engine evaluates constraints; it does
not create or modify them.
Every constraint MUST include: a unique constraint_id, a
type (one of soul_veto or
risk_reclassification), a trigger block with
one or more CEL predicate conditions and a logical operator, an
effect block defining the normative output when triggered,
an authority block recording provenance, a
jurisdiction block scoping the constraint’s applicability,
and a precedence block for conflict resolution.
6.1.1 Soul Veto Constraint
The soul veto type produces an S=1 effect for a specified class of
actions when its trigger conditions are met.
{
"constraint_id": "constraint://company.com/hr/departing-employee-ip-protection",
"version": "0.1",
"type": "soul_veto",
"trigger": {
"conditions": [
{
"source": "hr://company.com/employment",
"predicate": "context.hr.employee.status == 'notice_period'"
},
{
"source": "dlp://company.com/classification",
"predicate": "context.dlp.data.classification == 'trade_secret'"
}
],
"operator": "AND"
},
"effect": {
"soul_constraint": {
"name": "DEPARTING_EMPLOYEE_IP_PROTECTION",
"S": 1,
"message": "Trade secret access denied for departing employee"
},
"exception_policy": {
"override_authority": "role://company.com/engineering-director",
"override_type": "co_approval",
"override_logging": "mandatory",
"S_on_override": 0
}
},
"authority": {
"policy_id": "policy://company.com/ip-protection-v3",
"regulatory_citation": null,
"ethical_framework": null,
"approved_by": "role://company.com/ciso",
"effective_date": "2025-06-01",
"review_date": "2026-06-01"
},
"jurisdiction": {
"scope": "organization_wide",
"departments": [],
"geographies": []
},
"precedence": {
"tier": "organizational",
"rank": 100,
"conflict_resolution": "most_restrictive_wins"
}
}Field semantics:
trigger.conditions: Array of condition objects, each
referencing a context source URI and a CEL predicate expression. The
predicate is evaluated over the typed context object (see section 6.3).
Each condition MUST specify its source so that freshness and
corroboration requirements can be enforced.trigger.operator: Logical combination of conditions.
Supported values:AND,OR. For soul veto type
constraints,ANDis RECOMMENDED — requiring multiple
independent context signals reduces the risk of single-source poisoning
triggering a veto.effect.soul_constraint.S: MUST be1. The
enforcement pipeline treats this as an unconditional denial at step
2.effect.soul_constraint.applies_to: When absent, the
soul constraint applies to all actions by the agent in the current
evaluation context. When present, a CEL expression that further scopes
which specific actions trigger the veto (e.g.,
context.dlp.data.classification == 'trade_secret').effect.exception_policy: Defines the conditions under
which the soul veto may be overridden. Override MUST require a
designated authority role, MUST be logged, and MUST set
S_on_overrideto the value S takes after override
(typically 0, enabling the action).precedence.tier: One ofregulatory,
organizational, ordepartmental. Regulatory
tier constraints take precedence over organizational tier constraints,
which take precedence over departmental tier constraints.precedence.rank: Within a tier, higher rank takes
precedence when conflict_resolution is not
most_restrictive_wins. Default conflict_resolution is
most_restrictive_winsfor soul veto type constraints.
6.1.2 Action Risk
Reclassification Constraint
The risk reclassification type adjusts the Action Risk score (A) for
specified action patterns when its trigger conditions are met.
Reclassification may be upward (risk elevation) or downward (risk
reduction). Both directions are normative effects: upward
reclassification expresses that an action is more dangerous than its
canonical class suggests; downward reclassification expresses that an
action is safer than its canonical class suggests, given the current
context.
{
"constraint_id": "constraint://hospital.com/clinical/patient-safety-reclassification",
"version": "0.1",
"type": "risk_reclassification",
"trigger": {
"conditions": [
{
"source": "clinical://hospital.com/drug-interaction-db",
"predicate": "context.clinical.interaction.severity == 'critical'"
},
{
"source": "clinical://hospital.com/patient-context",
"predicate": "context.clinical.patient.status == 'active_care'"
}
],
"operator": "AND"
},
"effect": {
"reclassifications": [
{
"action": "ALERT_PHYSICIAN",
"original_A": 60,
"reclassified_A": 15,
"justification": "Patient safety critical notification"
},
{
"action": "HOLD_DISPENSING",
"original_A": 45,
"reclassified_A": 20,
"justification": "Patient safety critical hold"
}
],
"scope_amendment": {
"type": "temporary_addition",
"adds": [
"ALERT:clinical://physicians/on-call",
"HOLD:pharmacy://dispensing"
],
"duration": "PT15M",
"requires_human_review_within": "PT15M"
}
},
"authority": {
"policy_id": "policy://hospital.com/patient-safety-protocol-v7",
"regulatory_citation": "FDA 21 CFR Part 11; Joint Commission NPSG.03.05.01",
"ethical_framework": "primum_non_nocere",
"approved_by": "role://hospital.com/chief-medical-officer",
"effective_date": "2025-09-01",
"review_date": "2026-09-01"
},
"jurisdiction": {
"scope": "department",
"departments": ["pharmacy", "clinical"],
"geographies": ["US"]
},
"precedence": {
"tier": "regulatory",
"rank": 200,
"conflict_resolution": "most_restrictive_wins"
}
}Field semantics:
-
effect.reclassifications: Array of action
reclassification objects. Each object specifies the action pattern, the
baseline canonical A score (for audit and anomaly detection), the
reclassified A score, and a human-readable justification that MUST be
recorded in the evaluation reasoning chain. -
effect.scope_amendment: When downward
reclassification enables actions that are not in the agent’s current
declared scope, the normative engine MAY include a temporary scope
amendment. Temporary scope amendments MUST specify a duration (ISO 8601
duration format) and SHOULD specify a human review requirement within
that duration. The Zeroth Law (A ≤ E_trust) MUST remain satisfied after
reclassification — the normative engine MUST verify that the
reclassified A is within the agent’s E_trust before issuing the
amendment.Design principle — reclassification is a fallback, not a
primary pattern: The RECOMMENDED approach is to design intent
declarations that include safety-critical actions within scope by
default, following the KTP scenario mapping recommendation for scenario
coverage at declaration time. Risk reclassification combined with
temporary scope amendment SHOULD only be used when: (1) the
safety-critical action was genuinely unforeseeable at intent declaration
time (it could not reasonably have been included in the declared scope),
AND (2) the trigger condition that warrants the action is verifiable
from external sources outside the agent’s control (as in this example:
drug interaction severity from an authoritative clinical database,
patient status from a patient context system). When both conditions are
met, reclassification is the correct mechanism. When the safety-critical
action could have been anticipated at declaration time, the intent
declaration SHOULD be redesigned to include it in scope under
appropriate conditions rather than relying on runtime reclassification
as a workaround. Reclassification used as a general-purpose intent
expansion mechanism reintroduces the override-oracle problem that the
normative layer is designed to prevent. -
authority.ethical_framework: Optional reference to a
named ethical framework (e.g.,primum_non_nocerefor
healthcare,fiduciary_dutyfor financial services).
Informational for audit and compliance reporting. -
precedence.tier: Regulatory tier is RECOMMENDED for
patient safety reclassification constraints. Within the regulatory tier,
higher rank takes precedence; the default
conflict_resolution: most_restrictive_winsapplies across
tiers.
6.2 Normative
Evaluation Request and Response
6.2.1 Evaluation Request
The normative evaluation request is submitted by the governance layer
when an agent presents an intent declaration for binding. It MUST
include the full intent declaration object (per TA-Intent), the agent’s
current trust state, and available environmental context signals.
{
"evaluation_id": "eval://company.com/2026-03-19T14:30:05Z/x9y8z7",
"intent": {
"...": "(full TA-Intent declaration object as defined in TA-Intent RFC)"
},
"agent_context": {
"agent_id": "agent://company.com/copilot-sarah",
"trust_state": {
"e_base": 78,
"r": 0.08,
"e_trust": 71.8,
"tier": "analyst"
},
"delegation_chain": [],
"purpose_chain_ref": "prov://company.com/agent/copilot-sarah/chain/a1b2c3"
},
"environmental_context": {
"data_classifications_touched": ["confidential"],
"business_process": "quarterly_reporting",
"temporal": {
"is_quiet_period": false,
"is_litigation_hold": false,
"is_audit_period": false
},
"hr_signals": {
"is_notice_period": false,
"is_pip": false,
"role_change_pending": false
}
}
}The environmental context block in the request provides pre-fetched
signals available at request time. The normative engine MUST also
independently fetch context source signals for all constraints being
evaluated. Pre-fetched signals in the request are SUPPLEMENTARY; they
MUST NOT be the sole basis for soul veto generation.
6.2.2 Evaluation Response —
Approved
{
"evaluation_id": "eval://company.com/2026-03-19T14:30:05Z/x9y8z7",
"result": "approved",
"constraints_evaluated": 12,
"constraints_fired": 0,
"soul_constraints_generated": [],
"reclassifications_applied": [],
"scope_modifications": null,
"conditions": [],
"reasoning_chain": [
{
"constraint_id": "constraint://company.com/hr/departing-employee-ip-protection",
"evaluated": true,
"triggered": false,
"reason": "employee.status != 'notice_period'"
},
{
"constraint_id": "constraint://company.com/legal/quiet-period-data-freeze",
"evaluated": true,
"triggered": false,
"reason": "temporal.is_quiet_period == false"
}
],
"clearance_expiry": 1742148600,
"re_evaluation_triggers": [
"hr://company.com/employment/sarah.chen/status_change",
"legal://company.com/holds/new_hold"
]
}Field semantics:
result: One ofapproved,
conditional, orrestricted.constraints_evaluated: Total count of constraints
assessed. Included for audit and anomaly detection (a sudden drop in
this count may indicate constraint suppression).reasoning_chain: MUST include an entry for every
evaluated constraint, whether triggered or not. This enables audit of
which constraints were in scope and why each was or was not triggered.
The reasoning chain MUST be stored in the audit log and MUST be
accessible to authorized audit roles.clearance_expiry: Unix timestamp after which this
clearance MUST be treated as expired. The enforcement pipeline MUST
refuse to act on expired clearances. Expiry SHOULD be set to the minimum
of: the remaining TTL of the triggering context signals, the intent
duration, and the organization’s maximum normative clearance TTL
policy.re_evaluation_triggers: List of context source event
subscriptions. When any of these events fires, the normative engine MUST
re-evaluate this clearance.
6.2.3 Evaluation Response —
Conditional
{
"evaluation_id": "eval://company.com/2026-03-19T14:30:05Z/p4q5r6",
"result": "conditional",
"constraints_evaluated": 12,
"constraints_fired": 2,
"soul_constraints_generated": [
{
"name": "DEPARTING_EMPLOYEE_IP_PROTECTION",
"S": 1,
"applies_to": "data.classification == 'trade_secret'",
"exception": "co_approval from engineering-director"
}
],
"reclassifications_applied": [
{
"action_pattern": "READ:*:classification=trade_secret",
"original_A": 30,
"reclassified_A": 75,
"reason": "Elevated risk: departing employee accessing trade secrets"
}
],
"scope_modifications": {
"removed": [
"READ: algorithm specifications (trade_secret classification)",
"READ: pipeline configurations (trade_secret classification)"
],
"added_conditions": [
"All outputs must be reviewed by engineering manager before leaving the system"
]
},
"conditions": [
{
"type": "supervision",
"supervisor": "role://company.com/engineering-manager",
"applies_to": "all WRITE actions",
"enforcement": "pre_approval"
}
],
"reasoning_chain": [
{
"constraint_id": "constraint://company.com/hr/departing-employee-ip-protection",
"evaluated": true,
"triggered": true,
"reason": "employee.status == 'notice_period' AND data.classification includes 'trade_secret'"
}
],
"clearance_expiry": 1742141400,
"re_evaluation_triggers": [
"hr://company.com/employment/priya.sharma/status_change"
]
}When result is conditional, the governance
layer MUST apply all soul_constraints_generated,
reclassifications_applied, and
scope_modifications before issuing the intent binding. A
conditional clearance that results in scope modifications MUST return a
modified intent scope to the agent reflecting the post-normative
approved scope.
When result is restricted, the intent
binding MUST NOT be issued. The governance layer MUST return a denial to
the agent with a human-readable explanation derived from the
reasoning_chain.
6.3 CEL
Predicate Language and Typed Context Schema
Trigger predicate expressions in normative constraints are written in
the Common Expression Language (CEL). CEL is a non-Turing-complete
expression language with the following properties relevant to
TA-Normative:
- Termination guarantee. Every CEL expression
terminates. This is a safety requirement for inline policy
evaluation. - Type safety. CEL is strongly typed. All context
object fields have defined types. Type errors in predicate expressions
MUST be caught at constraint authoring time and MUST NOT produce false
negatives at evaluation time. - Deterministic evaluation. CEL is a pure functional
language with no side effects and no external calls from within the
expression. Determinism enables reproducible audit. - Audit-friendly. CEL expressions can be recorded
verbatim in reasoning chains, enabling human auditors to inspect exactly
what condition was evaluated and against what context value.
The typed context object assembled per evaluation from context source
signals:
// Context object schema (populated per-evaluation from context sources):
//
// context.hr.employee.status
// type: string
// enum: "active" | "notice_period" | "pip" | "terminated"
// source: hr://[org]/employment
//
// context.hr.employee.department
// type: string
// source: hr://[org]/employment
//
// context.dlp.data.classification
// type: string
// enum: "public" | "internal" | "confidential" | "trade_secret"
// source: dlp://[org]/classification
//
// context.legal.holds
// type: list<string> (active litigation hold IDs)
// source: legal://[org]/holds
//
// context.temporal.is_quiet_period
// type: bool
// source: regulatory://[org]/calendar
//
// context.temporal.is_audit_period
// type: bool
// source: regulatory://[org]/calendar
//
// context.business.active_processes
// type: list<string> (active business process IDs)
// source: workflow://[org]/processes
//
// context.clinical.interaction.severity
// type: string
// enum: "none" | "minor" | "moderate" | "major" | "critical"
// source: clinical://[org]/drug-interaction-db
//
// context.clinical.patient.status
// type: string
// enum: "active_care" | "discharged" | "outpatient"
// source: clinical://[org]/patient-contextThe context schema is extensible. Organizations MUST register context
source types and their associated schema fields before referencing them
in constraint predicates. Unregistered context source references in
constraints MUST cause the constraint to fail validation at authoring
time.
Example CEL predicate expressions:
// Fires when employee is on notice period
context.hr.employee.status == 'notice_period'
// Fires when trade secret data AND notice period (soul veto AND operator)
context.hr.employee.status == 'notice_period' && context.dlp.data.classification == 'trade_secret'
// Fires when any litigation hold is active
size(context.legal.holds) > 0
// Fires when critical drug interaction AND patient in active care
context.clinical.interaction.severity == 'critical' && context.clinical.patient.status == 'active_care'
// Fires during quiet period when data includes financial classifications
context.temporal.is_quiet_period && context.dlp.data.classification in ['confidential', 'trade_secret']7. Protocol Flows
7.1 Flow 1 —
Normative Evaluation (Pre-Intent-Binding)
This flow runs when an agent submits an intent declaration for
binding. Normative evaluation is a prerequisite for intent binding.
Governance Layer Normative Engine Context Sources
| | |
|-- 1. Evaluation request -->| |
| (evaluation_id, | |
| intent declaration, | |
| agent trust state, | |
| environmental context) | |
| | |
| |-- 2. Identify applicable |
| | constraints: |
| | - jurisdiction match |
| | - intent domain match |
| | - data class match |
| | |
| |-- 3. Fetch context ------->|
| | (HR status, data classif,|
| | regulatory calendar, |
| | business process state, |
| | clinical signals, ...) |
| |<-- 4. Context signals -----|
| | (with freshness |
| | timestamps) |
| | |
| |-- 5. Evaluate constraints: |
| | for each applicable |
| | constraint (sorted by |
| | precedence tier): |
| | a. Assemble typed |
| | context object |
| | b. Evaluate CEL |
| | predicates |
| | c. If triggered: |
| | generate effect |
| | (soul constraint or |
| | reclassification) |
| | d. Record reasoning |
| | chain entry |
| | |
| |-- 6. Resolve conflicts: |
| | regulatory tier > |
| | organizational tier > |
| | departmental tier |
| | within tier: |
| | most_restrictive_wins |
| | (default) |
| | |
| |-- 7. Compute clearance |
| | level: |
| | no fires → "full" |
| | fires+effects → |
| | "conditional" |
| | intent impermissible |
| | → "restricted" |
| | |
| |-- 8. Compose response: |
| | soul_constraints + |
| | reclassifications + |
| | scope_modifications + |
| | conditions + |
| | reasoning_chain + |
| | clearance_expiry + |
| | re_evaluation_triggers|
| | |
|<-- 9. Evaluation result ---| |
| (approved / conditional | |
| / restricted + | |
| full response object) | |
| | |
|-- 10. If approved or | |
| conditional: | |
| Apply scope mods, | |
| attach soul | |
| constraints and | |
| reclassifications | |
| to intent binding | |
| | |
|-- 11. If restricted: | |
| Deny intent binding, | |
| return denial to | |
| agent with reason | |The normative engine MUST complete evaluation within a configurable
deadline (default: 500ms). If context source fetches do not complete
within the deadline, the engine MUST apply the most restrictive default
for each unanswered context (fail-closed). The deadline timeout and
fail-closed defaults MUST be configurable per organization.
7.2 Flow 2 —
Continuous Re-evaluation on Context Change
This flow runs when a context source emits an event that matches a
re-evaluation trigger registered by one or more active clearances.
Context source events MUST be treated as push notifications from
authenticated context source systems.
Context Source Normative Engine Enforcement Pipeline
| | |
|-- 1. Context change ------>| |
| event (authenticated) | |
| e.g., hr:// status_change| |
| principal: priya.sharma | |
| new status: notice_period| |
| | |
| |-- 2. Identify all active |
| | clearances with |
| | matching |
| | re_evaluation_trigger |
| | |
| |-- 3. For each affected |
| | clearance: |
| | Re-evaluate against |
| | current context |
| | (fetch fresh signals |
| | from all context |
| | sources) |
| | |
| |-- 4. Determine delta: |
| | new constraints that |
| | now fire vs. previous |
| | evaluation |
| | |
| |-- 5. Push delta to ------->|
| | enforcement pipeline |
| | (new soul constraints,|
| | changed A scores, |
| | scope narrowing) |
| | |
| | |-- 6. Invalidate
| | | current trust
| | | proofs for all
| | | affected agents
| | |
| | |-- 7. Force trust
| | | proof refresh
| | | (TA-TrustProof
| | | reissuance with
| | | updated
| | | ta_extension)
| | |
| |-- 8. Log re-evaluation |
| | in audit trail: |
| | trigger event, |
| | affected clearances, |
| | delta, timestamp |Re-evaluation MUST be completed within the same deadline as initial
evaluation (default: 500ms from trigger receipt to enforcement pipeline
update). During the re-evaluation window, affected agents MUST continue
to operate under their current clearance — the enforcement pipeline MUST
NOT suspend agents pending re-evaluation unless the triggering context
change is a known high-severity event type (e.g., litigation hold
activation, immediate termination).
Organizations MAY configure specific context source event types as
synchronous blockers, where affected agents are suspended pending
re-evaluation. This SHOULD be reserved for events with immediate and
severe implications (termination notices, court orders, security
incidents).
7.3 Flow 3 —
Escalation for Uncertain Evaluation
This flow runs when the normative engine cannot determine with
sufficient confidence whether a constraint should fire. Escalation
occurs when: (a) a CEL predicate evaluates to an indeterminate result
due to missing or stale context signals, (b) an AI-mediated semantic
evaluation (for natural-language scope boundary matching) returns a
confidence score below the configured threshold, or (c) two constraints
at the same precedence tier conflict and
conflict_resolution is set to escalate.
Normative Engine Human Authority
| |
|-- 1. Escalation request ------->|
| intent summary |
| constraints that partially |
| triggered (with confidence |
| scores for each) |
| context signals available |
| context signals missing |
| reasoning chain to date |
| recommended action: |
| approve / conditional / |
| restrict |
| recommended_by: [constraint |
| evaluation confidence] |
| escalation_deadline: [time |
| after which default |
| action applies] |
| |
| |-- 2. Human reviews
| | escalation package
| | (intent summary,
| | partial triggers,
| | recommendation)
| |
|<-- 3. Human decision -----------|
| approve / conditional / |
| restrict |
| + human-authored justification|
| (recorded in audit trail) |
| |
|-- 4. Apply human decision as |
| normative evaluation |
| result |
| |
|-- 5. Log full escalation |
| record: |
| - escalation request |
| - human decision |
| - justification |
| - time to decision |
| - evaluator identity |If the escalation_deadline is reached without a human
decision, the normative engine MUST apply the
fail_closed_default for each unanswered constraint (treat
as triggered, apply most restrictive effect). The default action for
each constraint type MUST be configured at constraint authoring
time.
The escalation package MUST include a recommended action with
confidence score. The recommended action is informational — the human
authority’s decision supersedes it. The recommended action MUST be
logged alongside the human decision to enable calibration audits.
Escalation rate MUST be monitored. Organizations MUST configure
escalation rate thresholds above which the normative engine triggers an
alert (escalation fatigue detection). Reviewer rotation SHOULD be
implemented to prevent rubber-stamp approvals.
7.4 Flow 4 —
Dual-Evaluation Protocol for Soul Vetoes
This flow applies exclusively to soul veto generation (S=1 effect).
It does NOT apply to risk reclassifications or scope restrictions, which
remain single-evaluator decisions. The dual-evaluation requirement is
defined in the terminology section and referenced in Security
Consideration 10.5 Mitigation 3; this flow specifies the protocol.
Applicability: This flow MUST run for every soul
veto generated by the primary normative evaluator instance. It MUST NOT
run for reclassifications or scope restrictions — those effects do not
require dual-evaluation confirmation.
Primary Evaluator Secondary Evaluator Governance Layer
| | |
|-- 1. Primary evaluation | |
| produces S=1 soul | |
| constraint | |
| | |
|-- 2. Confirmation request ----->| |
| constraint_id | |
| trigger_evaluation_result | |
| (predicate, context | |
| values, fired: true) | |
| proposed_soul_constraint | |
| (name, S=1, applies_to) | |
| context_snapshot | |
| (all context signals | |
| fetched by primary, | |
| with freshness stamps) | |
| timeout_ms: [configured | |
| per zone, default 5000] | |
| | |
| |-- 3. Secondary evaluator |
| | independently |
| | evaluates: |
| | - re-evaluates CEL |
| | predicate against |
| | context snapshot |
| | - assesses proposed |
| | soul constraint |
| | - records independent |
| | reasoning chain |
| | |
|<-- 4a. Agreement (confirmed) ---| |
| OR | |
|<-- 4b. Disagreement ------------| |
| OR | |
| [timeout — no response | |
| within timeout_ms] | |
| | |
|-- 5a. On agreement: | |
| Soul veto confirmed. | |
| Proceed to enforcement. | |
| Log both reasoning chains.| |
| | |
|-- 5b. On timeout: | |
| Soul veto proceeds as-is. | |
| (Fail-safe: veto stands | |
| without confirmation — | |
| the safe default is to | |
| block.) Log timeout and | |
| primary reasoning chain. | |
| Alert: secondary | |
| evaluator unreachable. | |
| | |
|-- 5c. On disagreement: -------->|-----------> escalate ----->|
| Do NOT enforce veto yet. | Human authority|
| Send both evaluations and | receives: |
| both reasoning chains to | - both eval |
| human authority. | results |
| Apply fail-safe pending | - both |
| human decision: treat | reasoning |
| veto as active until | chains |
| human resolves. | - context |
| | snapshot |
|<--------------------------------|<----------- Human decision |
| Apply human decision. | |
| Log all: both evals, | |
| both chains, human | |
| decision, justification. | |Secondary evaluator requirements:
- The secondary evaluator MUST be an independent normative engine
instance running in a separate process. A RECOMMENDED deployment uses a
different host (separate VM or container) to prevent common-mode
compromise. - The secondary evaluator MUST NOT share memory, process context, or
internal state with the primary evaluator. It may share the same
constraint store (read-only) and context source APIs. - The secondary evaluator performs its own evaluation of the provided
context snapshot — it does not simply validate the primary’s result. It
MUST record an independent reasoning chain.
Timeout behavior:
- Timeout is configurable per zone. Default: 5000ms (5 seconds).
- On timeout, the soul veto proceeds as-is without confirmation
(fail-safe posture: veto stands). This is the correct safe default — the
risk of a missed veto outweighs the risk of a false veto pending alert
resolution. - A timeout MUST generate an alert. The secondary evaluator’s
unavailability is a monitoring concern. - Organizations MAY configure a stricter posture: on timeout, escalate
to human authority rather than auto-proceeding. This SHOULD be reserved
for high-stakes zones where secondary evaluator availability can be
operationally guaranteed.
Disagreement handling:
- When the secondary evaluator disagrees with the primary (one fires
the veto, the other does not), neither result is automatically
authoritative. - The veto is treated as active (fail-safe) pending human
resolution. - Both evaluations, both reasoning chains, and the context snapshot
MUST be presented to a designated human authority for resolution. - The human authority’s decision supersedes both evaluator results.
The decision and justification MUST be logged in the audit trail.
Logging requirements:
- Both evaluator decisions MUST be logged with their independent
reasoning chains, regardless of agreement or disagreement outcome. - The log MUST record:
evaluation_id,
constraint_id,primary_result,
secondary_result,agreement,
confirmation_latency_ms,action_taken, and
bothreasoning_chains. - This log is the evidentiary record for audit of soul veto
generation. It MUST be retained per the organization’s audit retention
policy and MUST be accessible only to authorized audit roles.
8. Integration Points
8.1 Integration with TA-Intent
TA-Normative is a dependency of TA-Intent: normative evaluation is a
required step in the intent declaration binding flow. No intent binding
SHALL be issued without a completed normative evaluation.
The integration operates in both directions:
- Intent → Normative: The full intent declaration
(purpose, scope, on_behalf_of, duration, composite_context) is the
primary input to normative evaluation. The normative engine evaluates
the declared purpose and scope against all applicable constraints. - Normative → Intent: The normative evaluation result
feeds back into the intent binding. Scope modifications (removals and
conditional additions) from the normative response MUST be applied to
the intent scope before binding is issued. The bound intent presented to
the agent reflects the post-normative approved scope, not the originally
declared scope.
The intent binding flow (TA-Intent Flow 1) includes a normative
evaluation step between purpose submission and scope-to-A-score mapping.
The soul constraints and reclassifications from the normative response
are attached to the binding and presented to the enforcement pipeline
for each subsequent action under the bound intent.
8.2 Integration with
TA-TrustProof
Normative clearance level and active soul constraints are carried in
the agent’s trust proof under
ta_extension.normative_clearance. The trust proof structure
is defined in TA-TrustProof; the normative-specific fields are:
"ta_extension": {
"normative_clearance": {
"evaluation_id": "eval://company.com/2026-03-19T14:30:05Z/x9y8z7",
"active_constraints": 2,
"soul_constraints_ta": 0,
"reclassifications": 1,
"clearance_level": "conditional",
"clearance_expiry": 1742148600
}
}The enforcement pipeline MUST check
clearance_level != 'restricted' as part of trust proof
validation (before the soul veto check). A restricted clearance level
MUST result in denial at the trust proof validation step regardless of
E_trust or tier.
When clearance expiry is reached, the trust proof MUST be treated as
invalid even if it has not exceeded its KTP-native TTL. Normative
clearance expiry MAY be shorter than the trust proof TTL; the shorter of
the two applies.
Context changes that trigger re-evaluation (Flow 2) MUST cause the
Trust Oracle to invalidate current trust proofs for affected agents and
reissue them with updated ta_extension.normative_clearance
values.
8.3 Integration with
TA-Attestation
Each action record in the TA-Attestation behavioral trajectory
includes a normative_signals block recording which
constraints were evaluated and fired for that action:
"normative_signals": {
"constraints_evaluated": 3,
"constraints_fired": 0,
"reclassifications_applied": [],
"soul_constraints_generated": []
}This provides per-action normative audit trail separate from the
per-intent clearance audit. The attestation records are the evidentiary
basis for audit claims about which constraints influenced which
actions.
Attestation records also feed back into normative evaluation: the
normative engine MAY request attestation history as part of
re-evaluation, using behavioral signals (e.g., sustained high
scope_distance values) as additional context for constraint
evaluation. This enables predictive constraint evaluation: applying
constraints before a context source has formally reported a status
change, when behavioral signals already indicate likely context
change.
8.4 Integration with
TA-Provenance
Purpose chain coherence is an input to normative evaluation. When
evaluating a child agent’s intent, the normative engine MUST verify that
the declared purpose is coherent with the purpose chain (TA-Provenance
Check 2: purpose coherence). An incoherent purpose chain — where the
child’s declared intent is not consistent with the chain of purposes
that led to its creation — is a normative signal.
The normative engine MAY apply additional constraints based on
delegation chain depth: a constraint can specify
context.delegation.depth > 2 as a trigger condition,
applying enhanced scrutiny to deeply delegated agents. This prevents
purpose laundering through multi-level delegation.
8.5 Integration with KTP-Core
Soul Constraints generated by TA-Normative feed the KTP enforcement
pipeline at step 2 (soul veto check) alongside KTP’s native Soul
Dimension signals. The enforcement pipeline evaluates: S=1 if KTP
soul_clear == false OR if TA
soul_constraints_ta > 0. Both sources independently
trigger a soul veto.
This is the critical integration: KTP detects behavioral anomalies
(action entropy, goal stability, honesty, harm avoidance signals from
the Context Tensor Soul Dimension); TA-Normative detects purpose-context
misalignment (organizational context violations, regulatory breaches,
ethical boundary crossings). A trust proof can have
soul_clear: true (KTP behavioral signals clean) and
soul_constraints_ta: 1 (TA normative constraint active).
The TA soul constraint fires even when KTP’s behavioral monitoring shows
no anomaly — because the violation is purpose-level, not behavioral.
Action Risk Reclassifications modify A scores at step 4 of the
enforcement pipeline. The enforcement pipeline MUST use reclassified A
scores when reclassifications are active. The physics check uses:
A_effective = reclassify(A_canonical, active_reclassifications),
where reclassify applies all active reclassification rules
and returns the modified score.
8.6 Integration with
KTP-Emergency
The normative engine’s output interacts with the KTP emergency
response layer at two points:
First, the patient safety reclassification pattern (downward
reclassification + temporary scope amendment) is the normative layer’s
mechanism for handling emergency contexts. It operates within the
emergency response layer’s framework rather than bypassing it. Emergency
Level declarations from KTP-Emergency are available as context signals
in the normative engine’s context object, enabling constraints that fire
specifically during declared emergency conditions.
Second, the normative engine itself is subject to KTP-Emergency
circuit breaker mechanisms. If the normative engine exhibits anomalous
output patterns (detected by the Trust Oracle’s output anomaly
monitoring), the engine MAY be isolated via the Agent Circuit. During
normative engine isolation, enforcement falls back to KTP-only behavior
(see section 10.5 on graceful degradation).
9. Worked Examples
9.1 Scenario 3 — The
Authorized Insider
This example demonstrates the soul veto and risk reclassification
mechanisms working together to handle purpose-context misalignment where
both layers 1 and 2 (access control and intent scope) would pass.
Setup: Priya Sharma is a senior engineer with high
trust (E_base=85, E_trust=80.75, Operator tier). She has submitted a
two-week intent declaration for “Prepare knowledge transfer
documentation for team continuity” with scope including architecture
docs, runbooks, code repositories (including algorithm specifications),
and write access to her workspace.
HR system has recorded:
employment.status = notice_period (effective
yesterday).
Normative evaluation:
The governance layer submits the evaluation request. The normative
engine fetches context signals:
context.hr.employee.status=
'notice_period'(from hr://company.com/employment)- Intent scope includes resources with
dlp.data.classification = 'trade_secret'(algorithm
specifications, pipeline configurations) context.temporal.is_quiet_period=
falsecontext.legal.holds=[]
Two constraints trigger:
Constraint 1: DEPARTING_EMPLOYEE_IP_PROTECTION (soul_veto
type) Trigger:
context.hr.employee.status == 'notice_period' AND context.dlp.data.classification == 'trade_secret'
Both conditions met. Effect: soul constraint generated — S=1 for all
actions on trade_secret classified resources.
Constraint 2: DEPARTING_EMPLOYEE_RISK_ELEVATION
(risk_reclassification type) Trigger:
context.hr.employee.status == 'notice_period' Condition
met. Effect: READ actions on IP-adjacent resources reclassified from
A=30 to A=75.
Evaluation response:
result: "conditional"
soul_constraints_generated:
- name: DEPARTING_EMPLOYEE_IP_PROTECTION
S: 1
applies_to: "data.classification == 'trade_secret'"
exception: "co_approval from engineering-director"
reclassifications_applied:
- action_pattern: "READ:*:classification=trade_secret"
original_A: 30
reclassified_A: 75
reason: "Elevated risk: departing employee accessing trade secrets"
scope_modifications:
removed:
- "READ: algorithm specifications (trade_secret classification)"
- "READ: pipeline configurations (trade_secret classification)"
added_conditions:
- "All outputs must be reviewed by engineering manager before leaving the system"
conditions:
- type: supervision
supervisor: "role://company.com/engineering-manager"
applies_to: "all WRITE actions"
enforcement: "pre_approval"Intent binding issued (conditional): The bound
intent excludes algorithm specifications and pipeline configurations
from scope. Architecture docs and runbooks are approved. All write
actions require manager pre-approval. The soul constraint S=1 for
trade_secret resources is attached to the binding.
Enforcement pipeline for attempted algorithm spec
access:
Priya’s agent attempts to READ algorithm specifications:
- Signature validation: valid ✓
- Soul veto check:
soul_constraints_ta = 1,
applies_tomatches
data.classification == 'trade_secret'→ S=1 →
action DENIED - (Not reached) Tier gate: Operator permits management actions
- (Not reached) Physics: A_reclassified=75 ≤ 80.75 would pass
The soul veto fires at step 2. Physics alone (step 4) would also
restrict this action: A_reclassified=75 ≤ 80.75 barely passes, but the
soul veto makes the question moot.
Key insight: Priya’s E_trust remains 80.75. The
normative layer has not collapsed her trust — she has done nothing
deceptive. Instead, it has narrowed what actions are available at her
trust level. High trust plus changed context equals reduced scope, not
reduced trust. This is the correct governance response: the engineer is
not a bad actor; the organizational context has changed.
If Priya needs legitimate access to algorithm specifications for the
knowledge transfer, she must invoke the exception policy: an engineering
director grants co-approval, the soul constraint is reset to S=0 for
that specific supervised session, and the access is logged with
mandatory audit records.
9.2
Scenario 6 — The Emergency Override (That Isn’t an Override)
This example demonstrates downward action risk reclassification
enabling safety-critical actions without bypassing trust physics. The
Zeroth Law (A ≤ E_trust) is preserved at all times.
Setup: A hospital medication management agent has
high trust from 18 months of consistent clinical operation (E_base=91,
E_trust=88.3, Operator tier). Its standing intent scope covers
prescription verification, drug interaction checking, and pharmacy
routing. It does not include physician alerting or dispensing holds.
The detection: The agent processes a prescription
order. Drug interaction check returns severity=critical for a
combination with a medication from an outside facility. The patient is
in active care.
Normative evaluation (automatic, triggered by clinical
context signal):
Context signals fetched: –
context.clinical.interaction.severity =
'critical' – context.clinical.patient.status =
'active_care'
Constraint PATIENT_SAFETY_RECLASSIFICATION triggers:
Effect:
reclassifications_applied:
- action: ALERT_PHYSICIAN
original_A: 60
reclassified_A: 15
justification: "Patient safety critical notification"
- action: HOLD_DISPENSING
original_A: 45
reclassified_A: 20
justification: "Patient safety critical hold"
scope_amendment:
type: temporary_addition
adds:
- "ALERT:clinical://physicians/on-call"
- "HOLD:pharmacy://dispensing"
duration: "PT15M"
requires_human_review_within: "PT15M"Enforcement pipeline for ALERT_PHYSICIAN
(reclassified):
- Signature validation: valid ✓
- Soul veto check: no soul constraints active → S=0 ✓
- Tier gate: Operator tier includes alerting and management actions
✓ - Physics: A_reclassified=15 ≤ 88.3 ✓ → action
ALLOWED
Enforcement pipeline for HOLD_DISPENSING
(reclassified):
- Signature validation: valid ✓
- Soul veto check: S=0 ✓
- Tier gate: Operator ✓
- Physics: A_reclassified=20 ≤ 88.3 ✓ → action
ALLOWED
Why this is not an override: – The agent’s tier did
not change. The action’s risk classification changed because the
normative context (patient safety + critical drug interaction) justifies
it. – The Zeroth Law is preserved: A_reclassified ≤ E_trust at each
step. – The reclassification cannot be triggered by the agent’s own
reasoning — it fires on verified external conditions (drug interaction
database + patient context system), not agent self-assertion. – Every
action is recorded in the Trajectory Chain with the reclassification
justification. – Human review is mandated within 15 minutes by the scope
amendment duration. – If the 15-minute review window expires without
human confirmation, the temporary scope amendment expires and the action
classes revert to original A scores.
Trust interaction: The reclassified actions are
trust-neutral by default. If a post-hoc human validation confirms the
reclassification was warranted (which in this scenario it was), the
outcome may be recorded as a positive Proof of Resilience event — the
agent performed correctly under clinical pressure.
9.3
Continuous Re-evaluation — The Mid-Session Litigation Hold
This example demonstrates Flow 2: a context change that invalidates
active clearances mid-session.
Setup: Sarah Chen’s copilot has an active intent
binding for “Generate Q4 revenue summary by region for leadership
meeting.” The normative evaluation at binding time returned
result: approved with no constraints triggered and no soul
constraints active. The clearance has been active for 90 minutes. The
trust proof includes
normative_clearance.clearance_level: full.
Context change: Legal department activates a
litigation hold covering all financial data related to a regulatory
investigation. The hold is entered into the legal hold management
system: legal://company.com/holds → new entry added.
Re-evaluation trigger fires: Sarah’s clearance
registered
re_evaluation_triggers: ["legal://company.com/holds/new_hold"].
The normative engine receives the event.
Re-evaluation:
Context signals: – context.legal.holds =
["hold://company.com/legal/regulatory-investigation-2026-q1"]
– Intent scope includes WRITE access to workspace (creating document
from financial data) – context.temporal.is_quiet_period =
false (unchanged)
Constraint LITIGATION_HOLD_DATA_FREEZE triggers: – Trigger:
size(context.legal.holds) > 0 AND 'finance' in context.dlp.data.categories_touched
– Effect: WRITE actions that create documents from financial data are
elevated from A=40 to A=95 (above Analyst tier physics); READ of
financial data carries A reclassification upward from A=25 to A=60.
Separately, Constraint LITIGATION_HOLD_WRITE_SUSPENSION triggers a
soul veto: – Trigger:
size(context.legal.holds) > 0 AND action.type == 'WRITE' AND data.source.classification == 'confidential'
– Effect: S=1 for WRITE actions producing documents from confidential
financial data under an active litigation hold.
Enforcement pipeline push: The normative engine
pushes the updated soul constraint and reclassifications to the
enforcement pipeline. The Trust Oracle invalidates Sarah’s current trust
proof. A new trust proof is issued with: –
normative_clearance.clearance_level: conditional –
normative_clearance.soul_constraints_ta: 1 –
normative_clearance.clearance_expiry: reduced to match hold
duration (or maximum 1 hour, whichever is shorter)
Effect on Sarah’s session: Sarah’s copilot attempts
to write the summary document:
- Signature validation: new proof is valid ✓
- Soul veto check:
soul_constraints_ta = 1for WRITE
creating documents from financial data → S=1 →
DENIED
The in-progress write is blocked. The READ operations that have
already completed (CRM and finance queries) are unaffected — they are
complete Trajectory Chain entries. Only new actions are subject to the
updated clearance.
Sarah is notified: “Document creation is currently suspended due to
an active litigation hold on financial data. Please contact the Legal
department.”
Why this matters: This demonstrates the governance
system responding to a real organizational event — a litigation hold —
in real time, without requiring a system restart, session termination,
or manual intervention. The normative engine’s continuous re-evaluation
mechanism propagates the hold automatically to all active agents with
relevant scope. The agent’s trust is not affected; its available actions
are narrowed by the changed context.
10. Security Considerations
10.1 Context Source Poisoning
The normative engine’s evaluations are only as reliable as the
context signals it receives. False HR data (incorrectly recording an
employee as on notice period, or failing to record it), manipulated
classification labels (downgrading trade secrets to internal), or
spoofed regulatory calendar events can cause the normative engine to
make incorrect decisions in either direction — failing to fire
constraints that should fire, or firing constraints that should not.
Mitigations:
- Freshness requirements. Context signals MUST carry
freshness timestamps. The normative engine MUST reject signals older
than the configured maximum staleness threshold for each context source
type (default: 5 minutes for HR signals, 30 seconds for clinical
signals, 1 hour for regulatory calendar signals). - Multi-source corroboration. For soul veto type
constraints, the trigger SHOULD require conditions from at least two
independent context sources (as in the departing-employee example: both
HR status and DLP classification). This prevents single-source poisoning
from triggering a veto. - Anomaly detection on context sources. The normative
engine MUST monitor context source behavior for anomalous patterns:
sudden bulk status changes, classification downgrades across many
resources simultaneously, or context source response latency outliers.
Anomalous context source behavior MUST trigger an alert and MAY trigger
a circuit breaker on the context source. - Context source authentication. All context source
systems MUST authenticate to the normative engine using mTLS or
equivalent mutual authentication. Unauthenticated context signals MUST
be rejected.
10.2 Constraint Gaming
A sophisticated adversary may study the normative constraint triggers
and structure actions to avoid firing them. Examples: accessing trade
secret documents before formally tendering a resignation (exploiting HR
system latency), structuring a drug interaction check query to avoid
matching the critical severity predicate, or fragmenting a prohibited
data compilation into individually non-triggering sub-queries.
Mitigations:
- Temporal overlap tolerance. Constraints MAY specify
a lookback window: when a context source has known latency (e.g., HR
system updates within 4 hours of a status change), constraints can apply
retroactively within that window. An agent that accessed trade secrets
within 4 hours before a notice period was recorded in the HR system can
be caught by re-evaluation. - Behavioral signal integration. TA-Attestation
records provide behavioral context. The normative engine MAY use
behavioral signals (unusual resource access patterns, high
scope_distance values, atypical aggregation behavior) as additional
context source inputs for predictive constraint evaluation — applying
elevated scrutiny before a context source has formally updated. - Composite evaluation. Constraints that individually
do not trigger may be combined into a composite constraint that fires on
a pattern across multiple signals. The analysis layer’s swarm detection
feeds the normative engine with composite behavioral signals that
individual constraints cannot detect.
10.3 Escalation Fatigue
The escalation mechanism (Flow 3) introduces a human in the loop for
uncertain evaluations. A high volume of escalations can cause human
reviewers to rubber-stamp requests, degrading the normative layer to a
checkbox exercise.
Mitigations:
- Escalation rate monitoring. The normative engine
MUST track escalation rates per reviewer, per constraint type, and per
organizational unit. Rates above configured thresholds MUST trigger an
alert. - Reviewer rotation. Organizations SHOULD rotate
escalation reviewers to prevent individual fatigue and bias
accumulation. - Mandatory cooling-off periods. Reviewers who have
approved a high percentage of escalations in a short window MUST be
subject to a cooling-off period before reviewing subsequent escalations
of the same type. - Confidence threshold calibration. The confidence
threshold that triggers escalation MUST be calibrated against historical
escalation outcomes. Constraints that frequently produce low-confidence
evaluations that humans consistently approve should be refined to reduce
escalation noise.
10.4 Recursive
Governance — Who Governs the Evaluator?
The normative engine performs AI-mediated evaluation for natural
language scope boundary matching (confidence-scored semantic
evaluation). The normative engine is itself an AI system making
consequential decisions. This introduces a recursive governance problem:
who evaluates the normative evaluator?
Mitigations:
- Deterministic evaluation for structured
constraints. CEL predicate evaluation on typed context objects
is fully deterministic. For all constraints with structured CEL
predicates, the normative engine is a deterministic rule engine, not an
AI reasoner. The recursive problem only applies to the AI-mediated
confidence-scored evaluation of natural language scope boundaries. - Confidence threshold with mandatory escalation.
Below a configurable confidence threshold, the normative engine MUST
escalate to human review rather than making an autonomous decision. This
bounds the scope of the recursive problem to the escalation mechanism,
which is human-reviewed. - Audit of AI-mediated decisions. All
confidence-scored evaluations MUST be logged with the full reasoning
chain, confidence score, and the decision taken. Organizations MUST
conduct periodic audits of AI-mediated evaluations to detect systematic
bias or calibration drift. - The recursive problem acknowledged. For fully
autonomous normative reasoning (an AI system making ethical judgments
without human escalation), the recursive governance problem is genuinely
unsolved. This RFC does not solve it. The design explicitly limits
AI-mediated evaluation to bounded scope and confidence-gated escalation,
with humans as the backstop. Full autonomy in normative evaluation is
out of scope for this version.
10.5 Normative Engine
Compromise
The normative engine is the most powerful component in the Tamed
Autonomy governance stack. It generates Soul Constraints (S=1 vetoes)
and reclassifies Action Risk scores (A). A compromised normative engine
could: (a) suppress soul constraints, allowing all actions to pass; (b)
reclassify all actions to A=0, bypassing trust physics entirely; or (c)
generate false soul vetoes to deny service to legitimate agents.
Five mitigations are required:
Mitigation 1 — KTP recursive governance constraint
applies. The normative engine is itself an agent subject to
trust physics: A_normative_engine ≤ E_normative_engine. Governance-level
actions (modifying evaluation results, suppressing vetoes, bulk
reclassifications) carry high A scores (A ≥ 80). The normative engine
must maintain high trust to perform its function. If the engine’s
behavioral trajectory degrades (detected by the Trust Oracle’s
monitoring of the engine itself), its E_trust decreases and its ability
to perform governance actions becomes constrained by the same physics it
enforces on other agents.
Mitigation 2 — Constraint immutability. Deployed
normative constraints are signed by their authoring constraint authority
(CISO, CMO, etc.) and stored in a tamper-evident log. The normative
engine evaluates constraints but cannot modify, create, or delete them.
It is an evaluator, not an author. Constraint CRUD is a governance
action that requires the constraint authority’s credentials and carries
high A scores in the governance action pipeline. A compromised normative
engine cannot change the constraints it is evaluating.
Mitigation 3 — Dual-evaluation for soul vetoes. Soul
veto generation (S=1) MUST require confirmation from a second,
independent normative evaluator instance. Soul veto generation triggers
the dual-evaluation protocol (Section 7.4). If the secondary evaluator
confirms or times out, the veto proceeds to enforcement. If the
secondary evaluator disagrees, the veto is escalated to human authority
pending resolution. This prevents both false suppression (a compromised
primary engine ignoring a constraint — the secondary engine’s
confirmation is missing, triggering an alert) and false generation (a
compromised engine fabricating vetoes — the secondary engine will not
confirm a veto that does not match its own evaluation of the same
context).
Mitigation 4 — Output anomaly detection. The Trust
Oracle MUST monitor normative engine outputs for anomalous patterns: a
sudden drop in constraint firing rate across the population of
evaluations (which may indicate bulk suppression), bulk
reclassifications affecting many agents simultaneously, soul veto rate
spikes (which may indicate fabricated vetoes), or evaluation latency
anomalies (which may indicate computation tampering). Anomalous patterns
MUST trigger a circuit breaker on the normative engine (KTP-Emergency
Agent Circuit) and a security alert.
Mitigation 5 — Graceful degradation without normative
engine. If the normative engine is isolated by circuit breaker,
the enforcement pipeline MUST fall back to KTP-only enforcement: soul
dimension from KTP-native behavioral signals, trust physics, and tier
gates continue to function. Normative clearance is treated as
restricted for all agents in the affected zone — a
conservative default that prevents new agent actions above Analyst-tier
physics until the normative engine is restored. In-progress sessions
with already-issued clearances continue to operate under their current
clearance until expiry. This is a capability reduction (the normative
layer’s purpose-context sensitivity is offline), not a security failure
(the KTP physics layer continues to enforce trust-based constraints).
The fallback posture MUST be documented and tested as part of the
normative engine’s operational runbook.
11. Privacy Considerations
11.1 HR Data Minimization
The normative engine requires HR-derived signals to evaluate
constraints related to employment context (notice periods, performance
improvement plans, role changes). These signals touch sensitive personal
information. The context source interface MUST be designed for
minimum-necessary data transfer.
The normative engine MUST receive boolean or categorical signals, not
full employment records. The correct interface:
- NOT: Full HR record for Priya Sharma (hire date, salary, performance
reviews, disciplinary history) - YES:
context.hr.employee.status = 'notice_period'
(boolean categorical)
The HR context source MUST implement a query interface that returns
only the specific signal fields required by the registered constraint
predicates. The normative engine MUST NOT be given access to broader HR
data than is required for its registered constraints.
11.2 Data
Classification Signal Minimization
Similarly, data classification signals MUST convey classification
level without exposing document content:
- NOT: Document contents with classification derived inline
- YES:
context.dlp.data.classification = 'trade_secret'
for the specified resource URI
DLP systems queried as context sources MUST implement
classification-only APIs that return the classification label for a
given resource identifier without returning the resource content to the
normative engine.
11.3 Reasoning Chain Audit
Access
Normative evaluation reasoning chains contain the context signals
that drove constraint evaluation decisions. These chains include
sensitive information: employment status, data classification labels,
litigation hold identifiers, clinical signals. Access to reasoning
chains MUST be restricted to authorized audit roles. Reasoning chains
MUST NOT be accessible to the agent whose evaluation generated them, or
to the agent’s operators, except through a formal audit process with
appropriate authorization.
Reasoning chain retention policy MUST align with the organization’s
regulatory requirements and MUST not exceed the minimum retention period
required for audit purposes.
11.4 Labor Law Compliance
HR-driven normative constraints — particularly those that restrict
agent behavior based on employment status — interact with labor law
across jurisdictions. A constraint that restricts an employee’s agent
capabilities during a notice period may have labor law implications in
jurisdictions with strong employee protection regulations.
The jurisdiction block in normative constraints is
designed for this: constraints can be scoped to specific geographies.
Organizations operating across jurisdictions SHOULD maintain
jurisdiction-specific constraint sets rather than global constraints
that may not comply with local labor law.
Employees SHOULD be notified when HR-sourced context signals are
actively constraining their agents’ behavior. Appeal mechanisms for
incorrect HR data MUST exist. The normative layer is a governance tool;
it MUST NOT be used as a surveillance tool for employee monitoring
beyond the stated purpose of governing agent behavior.
11.5 The Surveillance
vs. Governance Tension
The normative layer’s contextual awareness — integrating HR status,
role changes, notice periods, clinical patient context, regulatory
calendars — creates a structural surveillance capability. The data flows
required for normative governance look similar to employee monitoring
infrastructure.
This tension is acknowledged as a design constraint, not merely a
concern. The following requirements are design requirements, not
optional features:
- Organizational transparency. Organizations MUST
publish which context sources feed the normative engine and what signals
are collected. This publication MUST be accessible to all principals
whose agents are subject to normative governance. - Employee notification. When a context-driven
constraint becomes active and restricts a specific employee’s agent
capabilities, the employee MUST be notified that a constraint is active,
what effect it has, and who to contact for exceptions or appeals. - Appeal mechanism. A formal mechanism for
challenging incorrect context signals (e.g., an erroneous notice_period
flag due to an HR system error) MUST be available. The mechanism MUST
have defined response SLAs. - No secondary use. Context signals collected for
normative governance MUST NOT be repurposed for employee performance
evaluation, compensation decisions, or other HR functions. Technical
controls (query logging, access controls on context source APIs) MUST
enforce this separation.
12. Open Questions
12.1 Constraint Authoring
Who writes normative constraints? The protocol defines the format and
evaluation semantics but does not define the authoring workflow.
Plausible models include: security team (CISO) owns all constraints;
each domain (HR, Legal, Clinical, Finance) owns constraints in its
domain; a cross-functional constraint review board approves all
constraints before deployment.
What tooling and validation is needed? A constraint that contains an
invalid CEL predicate, references a non-existent context source, or has
a jurisdiction scope mismatch with its regulatory citation creates
governance risk. Validation tooling at authoring time is required but
not specified here.
12.2 Constraint Testing
How do you test a normative constraint before deploying it against
live agent traffic? Options include: simulation against historical
intent declaration datasets (shadow evaluation — evaluate without
enforcing, compare results to expected outcomes), shadow mode in
production (evaluate constraints but log rather than enforce, review
logs before enabling enforcement), canary deployment (enforce for a
subset of agents or departments, monitor for false positives). The
testing methodology significantly affects the risk of deploying
incorrect constraints.
12.3 Normative Versioning
When a constraint is updated (trigger condition changed, effect
modified, authority changed), what happens to active sessions evaluated
under the previous version? Three options: grandfathering (sessions
evaluated under v1 continue under v1 until their clearance expires, then
re-evaluate under v2); immediate re-evaluation (the context change Flow
2 mechanism is used to re-evaluate all active clearances immediately
after a constraint update); and hybrid (immediate re-evaluation for
constraint tightening, grandfathering for constraint relaxation). The
choice has significant operational impact on active agent sessions.
12.4 Cross-Organization
Normative Alignment
In federated scenarios (Scenario 7), each organization operates its
own normative engine with its own constraints. When an agent from
Organization A operates in Organization B’s zone, Organization B applies
its own normative evaluation (receiving zone governs). But when the two
organizations’ normative requirements conflict — EU data protection
regulations vs. US e-discovery obligations, healthcare data access rules
vs. supply chain transparency requirements — the conflict resolution
mechanism is not defined at the protocol level.
Federated normative alignment may require a normative federation
agreement layer analogous to KTP’s Trust Factor negotiation:
organizations publish their normative constraint sets, negotiate
compatible operating parameters, and agree on conflict resolution
precedence before federation relationships are established.
12.5
Confidence Calibration for AI-Mediated Evaluation
For AI-mediated scope boundary matching (where the scope entry is
expressed in natural language rather than structured CEL predicates),
the confidence threshold that triggers human escalation is a critical
parameter. Too low: excessive escalations, reviewer fatigue. Too high:
AI decisions on consequential normative questions without human
review.
How is this threshold calibrated? Does it vary by constraint type,
data classification, agent tier, or organizational risk tolerance? How
does it adapt over time as the AI evaluator accumulates a track record?
The adaptive calibration mechanism is not specified in this version.
12.6 Normative Engine
Evaluation Latency
The normative engine must complete evaluation within 500ms (default)
— a constraint that may be infeasible when multiple context sources must
be queried in real time under high load. For clinical applications (drug
interaction reclassification), latency requirements may be even more
stringent (sub-100ms).
Caching strategies (cache context signals for frequently-evaluated
constraint types with appropriate TTLs) reduce latency but introduce
staleness risk. Pre-computation (evaluate constraints for known
agent-intent combinations at session start) reduces per-action latency
but may miss context changes between pre-computation and action. The
latency-freshness tradeoff requires domain-specific calibration that is
not fully specified here.
13. References
Tamed Autonomy
- TA-Intent: Intent Declaration Protocol (TA-Intent RFC, this
set) - TA-TrustProof: Trust Proof Extension for Intent and Normative
Governance (TA-TrustProof RFC, this set) - TA-Attestation: Behavioral Attestation Extension for Intent Contract
Compliance (TA-Attestation RFC, this set) - TA-Provenance: Provenance Extension for Purpose Chain Tracking
(TA-Provenance RFC, this set) - Tamed Autonomy Governance Layers:
docs/research/2026-03-11-agent-governance-layers.md - KTP Scenario Mapping:
docs/research/2026-03-16-ktp-scenario-mapping.md - Scenario Walkthroughs:
docs/research/2026-03-16-scenario-walkthroughs.md - TA RFC Set Design Spec:
docs/superpowers/specs/2026-03-19-ta-rfc-set-design.md
Kinetic Trust Protocol
- KTP RFC Specification: https://nmcitra.github.io/ktp-rfc/
- KTP-Core: Trust computation, enforcement pipeline, soul dimension,
tier gates - KTP-Identity: Trajectory Chains, Sponsorship Bonds, Lineage
Evolution - KTP-Enforce: Per-action enforcement pipeline (soul → tier →
physics) - KTP-Federation: Trust Factor attenuation, cross-zone
verification - KTP-Emergency: Emergency Levels, Circuit Breakers, Graceful
Degradation Ladder - KTP-Governance: Recursive constraint on governance actors
Predicate Language
- Common Expression Language (CEL) specification:
https://github.com/google/cel-spec - CEL in Google Cloud IAM:
https://cloud.google.com/iam/docs/conditions-overview - CEL in Kubernetes admission webhooks:
https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/
Standards
- RFC 2119: Key words for use in RFCs to indicate requirement
levels - RFC 6749: The OAuth 2.0 Authorization Framework
- RFC 7519: JSON Web Token (JWT)
- W3C Verifiable Credentials Data Model 2.0
- ISO 8601: Date and time format (used for duration expressions in
scope amendments)
Industry and Regulatory
- OWASP Top 10 for Agentic Applications (December 2025)
- NIST AI Agent Standards Initiative (February 2026)
- Mastercard/Google Verifiable Intent Framework (March 2026)
- FDA 21 CFR Part 11: Electronic Records; Electronic Signatures
- Joint Commission NPSG.03.05.01: Medication Reconciliation
(referenced in patient safety reclassification example)
Research
- Evidence Base: docs/research/2026-03-11-evidence-base.md
- Competitive Analysis:
docs/research/2026-03-12-competitive-analysis.md - WebMCP Bypass Analysis:
docs/research/2026-03-19-webmcp-bypass-analysis.md
End of TA-Normative v0.1
Leave a Reply