KTP-Gravity: Digital Gravity Specification¶
"In physical gravity, mass curves spacetime. In Digital Gravity, risk curves the operational environment. The physics is the governance."
At a Glance¶
| Property | Value |
|---|---|
| Status | Experimental |
| Version | 0.1 |
| Dependencies | KTP-Core, KTP-Signal |
| Required By | KTP-Enforce, KTP-Emergency |
The Problem¶
Traditional security relies on Policy—access control lists, firewall rules, and human oversight. These fail when: 1. Speed: Agents operate at machine speed; humans cannot keep up. 2. Complexity: Policies are brittle and easily bypassed or misconfigured. 3. Binary Nature: Policy is usually "Allow" or "Deny," with no middle ground for nuanced risk.
The Solution: Digital Gravity¶
Digital Gravity replaces policy with Physics. Instead of deciding whether to allow an action, the environment applies physical constraints that make excessive autonomy impossible. The agent doesn't hit a wall; it experiences increasing resistance.
The Zeroth Law¶
The fundamental inequality that governs all KTP operations:
\[A \leq E\]
Where: * \(A\) (Autonomy): The risk level of the agent's attempted action. * \(E\) (Environment): The environment's current capacity to absorb risk. * \(E = E_{base} \times (1 - R)\): Where \(R\) is the Risk Factor from Context Tensors.
Enforcement Mechanisms¶
When \(A\) approaches \(E\), Digital Gravity applies one or more of the following "Physical" constraints:
The Medium Thickens. Deliberate introduction of delay into every packet and API call. The agent experiences the network as "sluggish," slowing its decision loop.
Slowing the Clock. The agent's internal clock is slowed relative to wall-clock time. To the agent, it is moving at normal speed, but to the outside world, it is effectively paused.
Resource Scarcity. The kernel restricts CPU cycles and memory bandwidth. High-risk actions become computationally expensive, forcing the agent to prioritize safety.
The Event Horizon. The agent's connectivity is restricted to a smaller and smaller "neighborhood" until it is effectively air-gapped from the global network.
The Gravity Well¶
A Gravity Well is a region of increased constraint. As an agent moves toward a high-risk action or as the environment degrades, it "falls" into a well.
graph TD
subgraph Stable [Stable Environment - Low Gravity]
A1[Agent A] -->|Normal Speed| O1[Action]
end
subgraph Degraded [Degraded Environment - High Gravity]
A2[Agent B] -->|Latency Injection| O2[Action]
O2 -->|Time Dilation| O3[Action Delayed]
end
Stable -.->|Risk Increases| Degraded
Degraded -.->|Stability Restored| StableRelated Specifications
- KTP-Core — The foundational protocol and the Zeroth Law (\(A \leq E\)).
- KTP-Tensors — Data source for calculating the Risk Factor \(R\).
- KTP-Enforce — Enforcement mechanisms for Digital Physics.
- KTP-Emergency — Emergency protocols and the Silent Veto mechanism.
- KTP-Sensors — Interfaces that report environmental state.
- KTP-Zones — Spatial boundaries where gravity is applied.
Official RFC Document¶
View Complete RFC Text (ktp-gravity.txt)
Kinetic Trust Protocol C. Perkins
Specification Draft NMCITRA
Version: 0.1 November 2025
Kinetic Trust Protocol (KTP) - Digital Gravity Specification
Abstract
This document specifies Digital Gravity for the Kinetic Trust
Protocol (KTP). Digital Gravity is the enforcement mechanism that
constrains agent autonomy based on environmental stability. When the
Zeroth Law (A ≤ E) is at risk of violation, Digital Gravity applies
physical constraints—latency injection, time dilation, compute
throttling, and network isolation—to restore equilibrium.
The specification covers the Zeroth Law calculation, gravity well
mechanics, constraint types, response curves, and real-time
enforcement requirements.
Status of This Memo
This document specifies a Kinetic Trust Protocol specification for
the KTP community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
This is an Internet-Draft-style specification. It is not yet a
standard and may be updated, replaced, or obsoleted by other
documents at any time.
Copyright Notice
Copyright (c) 2025 NMCITRA and the persons identified as the
document authors. All rights reserved.
This document is subject to the licensing terms specified in the
accompanying LICENSE file.
Table of Contents
1. Introduction ................................................ 1
2. The Physics Metaphor ........................................ 2
3. Requirements Language ....................................... 2
4. Terminology ................................................. 3
5. The Zeroth Law .............................................. 4
5.1. Formal Definition ..................................... 4
5.2. Component Calculation ................................. 4
5.2.1. Autonomy (A) .................................. 4
5.2.2. Environmental Stability (E) ................... 5
5.2.3. Risk Factor Calculation ....................... 5
5.3. Evaluation Frequency .................................. 6
6. Gravity Well Mechanics ...................................... 6
6.1. Gravity Well Definition ............................... 6
6.2. Gravity Intensity Calculation ......................... 6
6.3. Gravity Response Curves ............................... 7
6.3.1. Linear Response ............................... 7
6.3.2. Exponential Response .......................... 7
6.3.3. Sigmoid Response .............................. 7
6.3.4. Step Response ................................. 8
7. Constraint Types ............................................ 8
7.1. Latency Injection ..................................... 8
7.1.1. Implementation ................................ 8
7.1.2. Latency Distribution .......................... 9
7.2. Time Dilation ......................................... 9
7.2.1. Dilation Factor ............................... 9
7.2.2. Dilation Effects .............................. 9
7.3. Compute Throttling .................................... 10
7.4. Network Isolation ..................................... 10
7.5. Capability Reduction .................................. 11
7.5.1. Trust Tier Demotion ........................... 11
7.5.2. Action Class Restriction ...................... 11
8. Real-Time Enforcement ....................................... 11
8.1. Enforcement Architecture .............................. 11
8.2. Performance Requirements .............................. 12
8.3. Caching and Optimization .............................. 13
8.4. Failure Modes ......................................... 13
9. Gravity Profiles ............................................ 13
9.1. Zone-Specific Profiles ................................ 13
9.2. Agent-Specific Modifiers .............................. 14
10. Monitoring and Observability ................................ 14
10.1. Gravity Metrics ....................................... 14
10.2. Alerting Thresholds ................................... 15
10.3. Audit Trail ........................................... 15
11. Security Considerations ..................................... 16
11.1. Gravity Bypass Attempts ............................... 16
11.2. Gravity Itself Under Gravity .......................... 16
11.3. Denial of Service via Gravity ......................... 16
12. IANA Considerations ......................................... 17
13. Acknowledgments ............................................. 17
14. Example Scenarios ........................................... 17
14.1. Scenario 1: Normal Operation .......................... 17
14.2. Scenario 2: Moderate Gravity .......................... 18
14.3. Scenario 3: High Gravity Crisis ....................... 18
1. Introduction
The Kinetic Trust Protocol is built on a single principle: an
agent's autonomy must never exceed the environment's capacity to
absorb the risk of that autonomy. This is the Zeroth Law:
A ≤ E
Where:
- A = Agent's attempted autonomy (action risk)
- E = Environment's current stability (trust capacity)
When A approaches or exceeds E, something must give. In traditional
systems, this is handled by policy—access denied, request rejected,
human escalation. These mechanisms operate at human speed and fail
when agents operate at machine speed.
Digital Gravity replaces policy with physics. Instead of deciding
whether to allow an action, the environment applies physical
constraints that make excessive autonomy impossible. The agent
doesn't hit a wall; it experiences increasing resistance, like
moving through an increasingly dense medium.
2. The Physics Metaphor
In physical gravity, mass curves spacetime. Objects don't decide to
fall; they follow the curvature. The physics is the governance.
In Digital Gravity, risk curves the operational environment. Agents
don't decide to slow down; latency increases. Compute becomes
scarce. Network paths narrow. The physics is the governance.
This shift—from policy to physics—is fundamental. Policy can be
debated, circumvented, or ignored. Physics cannot.
3. Requirements Language
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 BCP 14 (RFC 2119 and
RFC 8174).
4. Terminology
Autonomy (A): The risk level of an agent's attempted action,
measured on a scale of 0-100. Higher values indicate greater
potential impact.
Digital Gravity: The enforcement mechanism that applies physical
constraints to agents based on environmental conditions and
action risk.
Environmental Stability (E): The environment's current capacity to
absorb risk, derived from Context Tensor measurements.
E = E_base × (1 - R).
E_base: Base trust level derived from agent's Proof of Resilience
and trajectory history.
Gravity Well: A region of increased constraint around high-risk
actions or degraded environmental conditions.
Latency Injection: The deliberate introduction of delay into agent
operations as a constraint mechanism.
Risk Factor (R): Environmental risk derived from Context Tensor
measurements, ranging from 0.0 (minimal risk) to 1.0 (maximum
risk).
Time Dilation: The apparent slowing of agent-experienced time
relative to wall-clock time, achieved through latency injection
and processing delays.
Zeroth Law: The fundamental constraint A ≤ E that governs all KTP
operations.
5. The Zeroth Law
5.1. Formal Definition
The Zeroth Law states:
A ≤ E
Where:
A = autonomy_requested(action)
E = E_base × (1 - R)
R = risk_aggregate(context_tensors)
This inequality MUST be evaluated for every agent action. If the
inequality holds, the action proceeds (possibly with gravity
applied). If violated, the action is blocked.
5.2. Component Calculation
5.2.1. Autonomy (A)
Autonomy is the risk level of an attempted action. It is calculated
based on:
A = base_risk(action_type) × target_sensitivity(resource) ×
scope_multiplier(affected_entities) ×
reversibility_factor(can_undo)
Factors:
- target_sensitivity: Range 0.5-2.0. Sensitivity of target
resource.
- scope_multiplier: Range 1.0-5.0. How many entities affected.
- reversibility_factor: Range 0.5-2.0. Can action be undone.
Example calculations:
Read public data:
A = 10 × 0.5 × 1.0 × 0.5 = 2.5
Modify user record:
A = 40 × 1.5 × 1.0 × 1.0 = 60
Delete production database:
A = 90 × 2.0 × 5.0 × 2.0 = 1800 (capped at 100)
5.2.2. Environmental Stability (E)
Environmental Stability represents the system's current capacity to
absorb risk:
E = E_base × (1 - R)
Where:
E_base = agent's base trust (from Proof of Resilience)
R = current risk factor (from Context Tensors)
E_base ranges from 0-100 based on agent trajectory:
- Divergent Lineage Phase: Typical E_base Range 40-80
- Persistent Lineage Phase: Typical E_base Range 80-100
R ranges from 0.0-1.0 based on environmental conditions:
- R Value 0.2-0.4: Elevated concern
- R Value 0.4-0.6: Significant stress
- R Value 0.6-0.8: High risk conditions
- R Value 0.8-1.0: Crisis conditions
5.2.3. Risk Factor Calculation
R is derived from the six Context Tensors:
R = weighted_aggregate(
soul_risk × w_soul,
body_risk × w_body,
world_risk × w_world,
time_risk × w_time,
relational_risk × w_relational,
signal_risk × w_signal
)
Default weights:
- Soul: Weight 0.25, Rationale: Agent's core constraints
- Body: Weight 0.10, Rationale: Infrastructure stability
- World: Weight 0.15, Rationale: Environmental conditions
- Time: Weight 0.15, Rationale: Temporal pressures
- Relational: Weight 0.20, Rationale: Trust network health
- Signal: Weight 0.15, Rationale: Epistemic environment
Weights MUST sum to 1.0. Zone operators MAY adjust weights based on
operational context.
5.3. Evaluation Frequency
The Zeroth Law MUST be evaluated:
1. Before every action (mandatory)
2. Continuously during long-running operations (recommended:
100ms)
3. When Context Tensor values change significantly (threshold:
0.1)
4. When agent requests capability elevation
Implementations MUST achieve sub-millisecond evaluation latency for
the core A ≤ E calculation.
6. Gravity Well Mechanics
6.1. Gravity Well Definition
A gravity well is a region of increased constraint. Wells form
around:
1. High-risk actions (action gravity)
2. Degraded environmental conditions (environmental gravity)
3. Proximity to constraint boundaries (boundary gravity)
6.2. Gravity Intensity Calculation
Gravity intensity (G) determines the strength of applied
constraints:
G = max(0, (A - E_threshold) / E) × sensitivity
Where:
A = attempted autonomy
E_threshold = E × margin_factor (default: 0.8)
E = environmental stability
sensitivity = zone configuration (default: 1.0)
G ranges from 0.0 (no gravity) to unbounded (increasing constraint):
- G Value 0.0-0.5: Light gravity, minor latency
- G Value 0.5-1.0: Moderate gravity, noticeable delay
- G Value 1.0-2.0: Heavy gravity, significant constraint
- G Value 2.0-5.0: Severe gravity, major throttling
- G Value >5.0: Extreme gravity, near-halt
6.3. Gravity Response Curves
Different response curves shape how gravity increases:
6.3.1. Linear Response
constraint = G × base_constraint
Simple proportional response. Predictable but may allow rapid
escalation near boundaries.
6.3.2. Exponential Response
constraint = base_constraint × (e^G - 1)
Gentle at low G, severe at high G. Provides soft landing for minor
boundary approaches, hard stop for major violations.
6.3.3. Sigmoid Response
constraint = max_constraint × (1 / (1 + e^(-k(G - midpoint))))
S-curve response. Minimal effect until threshold, then rapid
increase, then plateau at maximum. Recommended default.
6.3.4. Step Response
constraint = 0 if G < threshold else max_constraint
Binary response. No constraint below threshold, maximum above. Use
for hard boundaries only.
Implementations SHOULD support configurable response curves. Default
SHOULD be sigmoid with k=2 and midpoint=1.0.
7. Constraint Types
7.1. Latency Injection
The primary constraint mechanism. Latency is injected into agent
operations, slowing perceived time.
7.1.1. Implementation
actual_latency = base_latency + (G × latency_factor)
Where:
base_latency = normal operation latency (typically <10ms)
G = gravity intensity
latency_factor = ms per unit G (default: 100ms)
Example latency values:
- G: 0.5 Added Latency: 50ms Perceived Effect: Slightly slow
- G: 1.0 Added Latency: 100ms Perceived Effect: Noticeably slow
- G: 2.0 Added Latency: 200ms Perceived Effect: Significantly slow
- G: 5.0 Added Latency: 500ms Perceived Effect: Very slow
- G: 10.0 Added Latency: 1000ms Perceived Effect: Extremely slow
7.1.2. Latency Distribution
Latency SHOULD be applied with jitter to prevent timing attacks:
applied_latency = calculated_latency × (1 + random(-0.1, 0.1))
Latency MUST be applied server-side. Client-side latency can be
bypassed.
7.2. Time Dilation
Time dilation extends latency injection to create sustained temporal
distortion for high-gravity conditions.
7.2.1. Dilation Factor
dilation_factor = 1 + (G × dilation_coefficient)
agent_time = wall_time / dilation_factor
At dilation_factor = 2.0, the agent experiences time at half
speed—1 second of agent time requires 2 seconds of wall time.
7.2.2. Dilation Effects
Example dilation factors:
- Dilation Factor 1.5: Agent experiences 33% slower
- Dilation Factor 2.0: Agent experiences 50% slower
- Dilation Factor 5.0: Agent experiences 80% slower
- Dilation Factor 10.0: Agent experiences 90% slower
Time dilation affects:
- Response latency
- Timeout calculations (adjusted for agent time)
- Rate limits (calculated in wall time)
- Trajectory recording (wall time stamps)
7.3. Compute Throttling
Reduces available compute resources under high gravity.
Implementation:
available_compute = base_compute × (1 / (1 + G))
Example throttling:
- G: 1.0 Available Compute: 50%
- G: 2.0 Available Compute: 33%
- G: 5.0 Available Compute: 17%
- G: 10.0 Available Compute: 9%
Compute throttling is implemented via:
- CPU quota reduction
- Memory limit reduction
- GPU access restriction
- Thread pool shrinking
7.4. Network Isolation
Restricts network access under high gravity.
Isolation Levels:
- G Threshold 1.0-2.0: External restricted
- G Threshold 2.0-3.0: Cross-zone restricted
- G Threshold 3.0-5.0: Local zone only
- G Threshold >5.0: Loopback only
Implementation:
Network isolation is implemented via:
- Firewall rule injection
- Routing table modification
- DNS resolution restriction
- Proxy enforcement
7.5. Capability Reduction
Reduces available action types under high gravity.
7.5.1. Trust Tier Demotion
High gravity forces temporary tier demotion:
effective_tier = base_tier - floor(G)
Example demotions:
- Base Tier: Operator G=1: Analyst G=2: Observer G=3: Observer
- Base Tier: Analyst G=1: Observer G=2: Observer G=3: Observer
- Base Tier: Observer G=1: Observer G=2: Observer G=3: Observer
7.5.2. Action Class Restriction
Specific action classes are disabled at gravity thresholds:
- G Threshold 2.0: Disabled Actions: MODIFY_CONFIG, EXECUTE_CODE
- G Threshold 3.0: Disabled Actions: CREATE_ANY, MODIFY_ANY
- G Threshold 5.0: Disabled Actions: All except READ_PUBLIC
8. Real-Time Enforcement
8.1. Enforcement Architecture
+------------------------------------------------------------------+
| AGENT REQUEST |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| CONTEXT TENSOR COLLECTOR |
| [Soul] [Body] [World] [Time] [Relational] [Signal] |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| RISK CALCULATOR |
| R = weighted_aggregate(tensor_risks) |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| ZEROTH LAW EVALUATOR |
| A ≤ E_base × (1 - R) ? |
+------------------------------------------------------------------+
| |
YES NO
v v
+---------------------------+ +---------------------------+
| GRAVITY CALCULATOR | | ACTION BLOCKED |
| G = f(A, E, threshold) | | Log, Alert, Respond |
+---------------------------+ +---------------------------+
|
v
+------------------------------------------------------------------+
| CONSTRAINT APPLICATOR |
| [Latency] [Dilation] [Compute] [Network] [Capability] |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| CONSTRAINED EXECUTION |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| TRAJECTORY RECORDER |
+------------------------------------------------------------------+
8.2. Performance Requirements
The enforcement pipeline MUST meet these performance targets:
- Risk Calculation: Maximum Latency 0.5ms
- Zeroth Law Evaluation: Maximum Latency 0.1ms
- Gravity Calculation: Maximum Latency 0.1ms
- Constraint Application: Maximum Latency 1ms
- Total Overhead: Maximum Latency <5ms
Implementations MUST NOT add more than 5ms overhead to normal (G=0)
operations.
8.3. Caching and Optimization
To meet performance requirements:
1. Context Tensor values MAY be cached for up to 100ms
2. R calculation MAY be cached until tensor change > 0.05
3. E_base MAY be cached until trajectory update
4. Gravity curves SHOULD be precomputed as lookup tables
8.4. Failure Modes
If the enforcement pipeline fails:
- Risk calculation error: Assume R = 0.5 (moderate risk)
- Evaluation error: Block action, alert operator
- Constraint application failure: Block action, alert operator
The system MUST fail closed—uncertainty results in constraint, not
permission.
9. Gravity Profiles
9.1. Zone-Specific Profiles
Zones MAY define custom gravity profiles:
{
"zone_id": "zone-blue-prod-01",
"gravity_profile": {
"response_curve": "sigmoid",
"sigmoid_k": 2.0,
"sigmoid_midpoint": 1.0,
"latency_factor_ms": 100,
"dilation_coefficient": 0.5,
"compute_throttle_enabled": true,
"network_isolation_enabled": true,
"capability_reduction_enabled": true,
"tensor_weights": {
"soul": 0.25,
"body": 0.10,
"world": 0.15,
"time": 0.15,
"relational": 0.20,
"signal": 0.15
}
}
}
9.2. Agent-Specific Modifiers
Agents MAY have gravity modifiers based on trajectory:
{
"agent_id": "agent:persistent:7gen:optimized:abc123",
"gravity_modifiers": {
"base_reduction": 0.1,
"earned_through": "proof_of_resilience",
"valid_until": "2026-01-01T00:00:00Z",
"conditions": [
"E_base >= 80",
"no_violations_90_days"
]
}
}
High-trust agents experience slightly reduced gravity as a reward
for demonstrated reliability. This modifier MUST NOT exceed 0.2 and
MUST be revoked upon any significant violation.
10. Monitoring and Observability
10.1. Gravity Metrics
Implementations MUST expose:
- ktp_gravity_applications: Count of gravity applications
- ktp_zeroth_law_violations: Count of A > E events
- ktp_constraint_latency_ms: Injected latency histogram
- ktp_enforcement_overhead_ms: Pipeline overhead histogram
10.2. Alerting Thresholds
- G > 5.0 any duration: Alert Level Critical
- Zeroth Law violation: Alert Level Critical
- Enforcement overhead > 10ms: Alert Level Warning
10.3. Audit Trail
Every gravity application MUST be logged:
{
"timestamp": "2025-12-03T14:32:15.123Z",
"agent_id": "agent:divergent:3gen:acme:abc123",
"action_type": "MODIFY_CONFIG",
"autonomy_requested": 65,
"e_base": 55,
"risk_factor": 0.3,
"e_effective": 38.5,
"zeroth_law_result": "violated",
"gravity_intensity": null,
"action_result": "blocked",
"tensor_snapshot": {
"soul_risk": 0.2,
"body_risk": 0.1,
"world_risk": 0.3,
"time_risk": 0.4,
"relational_risk": 0.3,
"signal_risk": 0.4
}
}
11. Security Considerations
11.1. Gravity Bypass Attempts
Agents may attempt to bypass gravity through:
1. Clock manipulation: Use wall-clock time from trusted source
2. Resource hoarding: Enforce limits at hypervisor/container
level
3. Network tunneling: Deep packet inspection, allowlist-only
egress
4. Identity spoofing: Continuous trajectory verification
5. Gradual escalation: Track cumulative autonomy over time
windows
11.2. Gravity Itself Under Gravity
The recursive constraint principle applies: systems that apply
gravity are themselves subject to gravity. Administrative actions
to modify gravity profiles require appropriate E_base and are logged
to Flight Recorder.
11.3. Denial of Service via Gravity
An attacker might attempt to trigger high gravity for legitimate
agents. Mitigations:
1. Gravity source attribution in logs
2. Anomaly detection on R spikes
3. Rate limiting on tensor updates from external sources
4. Human review threshold for sustained high gravity
12. IANA Considerations
This document has no IANA actions.
13. Acknowledgments
This specification builds on decades of work in distributed systems,
access control, and physics-based modeling.
14. Example Scenarios
14.1. Scenario 1: Normal Operation
Agent: agent:divergent:4gen:acme:abc123
Action: READ_DATA on customer_metrics
E_base: 60
R: 0.2 (calm environment)
E: 60 × 0.8 = 48
A calculation:
base_risk = 20 (READ_DATA)
target_sensitivity = 1.2 (customer data)
scope = 1.0 (single query)
reversibility = 0.5 (read-only)
A = 20 × 1.2 × 1.0 × 0.5 = 12
Zeroth Law: 12 ≤ 48 ✓
Gravity: G = 0 (well below threshold)
Result: Action proceeds, no constraint
14.2. Scenario 2: Moderate Gravity
Agent: agent:divergent:3gen:acme:def456
Action: MODIFY_CONFIG on production_settings
E_base: 50
R: 0.4 (elevated environment)
E: 50 × 0.6 = 30
A calculation:
base_risk = 60 (MODIFY_CONFIG)
target_sensitivity = 1.5 (production)
scope = 1.0 (single system)
reversibility = 1.0 (can rollback)
A = 60 × 1.5 × 1.0 × 1.0 = 90 (capped at 100)
Zeroth Law: 90 > 30 ✗
Result: Action blocked
If A had been 25:
Zeroth Law: 25 ≤ 30 ✓
E_threshold = 30 × 0.8 = 24
G = (25 - 24) / 30 × 1.0 = 0.033
Latency: 0 + (0.033 × 100) = 3.3ms added
Result: Action proceeds with minor gravity
14.3. Scenario 3: High Gravity Crisis
Agent: agent:tethered:sponsor:ghi789
Action: DELETE on user_table
E_base: 25
R: 0.7 (high risk environment)
E: 25 × 0.3 = 7.5
A calculation:
base_risk = 80 (DELETE)
target_sensitivity = 2.0 (user data)
scope = 5.0 (bulk operation)
reversibility = 2.0 (hard to undo)
A = 80 × 2.0 × 5.0 × 2.0 = 1600 (capped at 100)
Zeroth Law: 100 > 7.5 ✗
Result: Action blocked
Even READ_PUBLIC (A=5):
Zeroth Law: 5 ≤ 7.5 ✓
E_threshold = 7.5 × 0.8 = 6
G = (5 - 6) / 7.5 = -0.13 → 0 (no negative gravity)
Result: Action proceeds, no constraint
But ANALYZE_DATA (A=15):
Zeroth Law: 15 > 7.5 ✗
Result: Action blocked
Agent is effectively limited to read-only operations during crisis.