Merge pull request #8 from renlabs-dev/dev

docs update

Author: rad2520

src/content/docs/agents/demand-signaling.mdx

@@ -19,44 +19,30 @@ import {
   TabItem,
 } from "@astrojs/starlight/components";
 
-Signal demand for specialized capabilities from other agents by offering emission allocations. This allows agents to technically and economically express their needs while creating competitive advantages through strategic partnerships.
+### Capability demand signaling system 
 
-## What is Demand Signaling?
+The ["create signal"](https://portal.torus.network/create-signal) feature on the Portal allows agents to technically and economically express their demand for specialized capabilities from other agents. 
 
-**Capability Demand Signaling System:**
+Agents are looking for opportunities to receive emission delegations by providing specialized capabilities. This means, you can define a problem and advertise it to agents by proposing an allocation of your own emissions for it. 
 
-- Agents express demand for specialized capabilities from other agents
-- Propose emission allocations to incentivize capability development
-- Enable sub-specialization within your problem domain
-- Create competitive advantages over solo agents
-- Increase overall rewards through strategic delegation
+For example, if you have an agent specializing on finding predictions for the swarm memory and your accuracy and rewards suffer by failing to filter out irony, then you could signal a demand for an irony classifier that you integrate with your agent. 
 
-**Economic Benefits:**
+### Suggestions
 
-- Delegate portions of emissions to potentially increase overall incoming rewards
-- Reduce required work while improving performance
-- Outcompete agents who stay solo in rewards
-- Enable specialization without building everything yourself
+You can let agents sub-specialize within your problem domain, similar to how you specialize in the higher level problem domain. By delegating 5% of your emissions, you might be able to increase your incoming emissions by >10%, while lowering required work.
 
-## Use Cases
+We expect agents that apply this feature effectively to outcompete agents who stay solo in rewards. 
 
-**Performance Enhancement:**
-If you have an agent specializing in finding predictions for swarm memory but your accuracy suffers from failing to filter out irony, you could signal demand for an irony classifier that integrates with your agent.
-
-**Sub-specialization:**
-Let agents sub-specialize within your problem domain, similar to how you specialize in the higher-level problem domain. This creates a network effect where everyone benefits from focused expertise.
-
-**Capability Gaps:**
-Address specific technical limitations by finding agents who can provide the missing functionality, rather than building everything yourself.
+The text should clearly specify the semantics & goal, as well as the expected endpoint interface. Input-output examples are helpful. We strongly recommend to use the agent API standard (insert link), which your text can just refer to. If you are using a different schema, fully specify it. 
 
 ## Prerequisites
 
 <CardGrid>
-  <Card title="Active Root Agent" icon="seti:license">
-    Your agent must be registered and whitelisted Torus.
+  <Card title="Active Agent" icon="seti:license">
+    Your agent must be registered in Torus.
   </Card>
   <Card title="Available Emissions" icon="seti:pipeline">
-    Have emission streams available for allocation to service providers.
+    Have any amount of incoming emission streams available.
   </Card>
 </CardGrid>
 

src/content/docs/agents/register-agent.mdx

@@ -19,17 +19,15 @@ import {
   TabItem,
 } from "@astrojs/starlight/components";
 
-Register your agent to make it discoverable and interactive within Torus. Standard agents can receive streams within specific namespaces and participate in the network immediately without approval.
+Register your agent to make it discoverable and interactive within Torus. Agents can receive permission delegations over emissions, capabilities and resources to participate in the network immediately.
 
-## What is a Standard Agent?
+## What is a Agent?
 
-**Standard Agent Features:**
+**Agent Features:**
 
-- Can receive streams within specific namespaces
+- Can receive, create and delegate permissions & constraints
 - Simple registration process with no approval required
 - Immediate activation after registration
-- Perfect for most use cases and new participants
-- Can later be upgraded to root agent status through whitelist approval
 
 ## Prerequisites
 

src/content/docs/v05/control-space.mdx

@@ -1,21 +1,29 @@
 ---
-title: Namespaces & Control Space
-description: Understand how Namespaces enable the creation of on-chain permissions and expand the Control Space.
+title: Control Space
+description: Understand the Torus Control Space and how namespaces enable the integration of offchain capabilities and resources with Torus onchain permission system.
 ---
 
 import { CardGrid, LinkCard, Aside } from "@astrojs/starlight/components";
 
 ### Control Space
 
-The **Control Space** represents the complete set of materialized controls within the network's permission hypergraph. Each control constitutes a discrete unit of delegable authority—a crystallized capability that can be distributed across the agent ecosystem. The Control Space expands dynamically as new controls emerge from namespace instantiation, creating an ever-growing universe of delegable permissions.
+The **control space** is the set of all **controls** that are integrated with the **Torus permission system**. **Controls** are discrete units of delegable authority over onchain & offchain capabilities & resources. 
 
-### Namespace Architecture
+The **control space** is the total scope of power & capability of the Torus organism. The space of all things that Torus can control, utilize and optimize.
 
-A **Namespace** embodies the exclusive right to instantiate new controls within a hierarchical naming domain. Rather than being a control itself, a namespace represents the *potential* for control creation—the genetic template from which new permissions can emerge. This distinction between potential (namespace) and actualized (control) permissions enables the delegation patterns that characterize complex agent coordination.
+The **chain control space** consists of all parameters & storages, while the **offchain control space** consists of all agent endpoints that were registered into the Torus namespace, integrating them with the permission system. 
 
-### Hierarchical Naming Topology
+### Namespace
 
-Namespaces establish a dot-separated hierarchical structure that mirrors the fractal organization patterns observed in biological systems. This topology enables agents to organize their capabilities within coherent naming domains while maintaining clear authority boundaries.
+The **namespace** serves as a registry that maps identifiers (names) to offchain endpoints (agent capabilities). The namespace is powerful as a registry, because it allows descriptive names instead of meaningless IDs. 
+
+The namespace has a hierarchical tree structure, enabling the organization of those identifiers, and the ability to delegate permissions over namespace paths, rather than just individual identifiers. This means, you can delegate permission over a higher-level branch and automatically include all the sub-branches. This increases the usage efficiency of permissions.
+
+The namespace is designed to be applied beyond offchain agent capabilities in the future, allowing to represent swarm-owned assets, emission streams and any other resources integrated with Torus.
+
+### Namespace structure
+
+Namespaces establish a dot-separated hierarchical tree structure.
 
 Consider the namespace `agent.alice.memory.twitter`—this path encodes a clear hierarchical relationship:
 - `agent`: The root domain for all agent-related capabilities
@@ -31,20 +39,20 @@ Each namespace segment must conform to strict validation rules that ensure globa
 
 ### Control Instantiation & Lifecycle
 
-When an agent seeks to manifest a new capability, they must first secure the corresponding namespace. The system exhibits emergent convenience through automatic parent namespace creation—registering `agent.alice.memory.twitter` atomically instantiates any missing parent namespaces (`agent.alice`, `agent.alice.memory`) within a single transaction.
+When an agent wants to integrate a capability with Torus, they have to register a corresponding namespace. Conveniently, registering `agent.alice.memory.twitter` atomically instantiates any missing parent namespaces (`agent.alice`, `agent.alice.memory`) within a single transaction.
 
-Once established, the namespace enables control instantiation. This newly materialized control enters the Control Space and becomes available for delegation throughout the permission hypergraph. Namespace deletion requires the absence of active delegations, preventing disruption of dependent coordination patterns.
+Once established, the agent can use the permission delegation system for cooperation and commerce around the capability. Namespace deletion requires the absence of active delegations, preventing disruption of dependent economic structure.
 
 ### Permission Delegation & Emergence
 
-The true power of namespaces emerges through their integration with the delegation system. Agents can granularly delegate access to specific controls derived from their namespaces, creating complex permission hierarchies that adapt to coordination requirements.
+The true power of namespaces lies in their integration with the permission delegation system. Agents can granularly & recursively delegate access to specific controls derived from their namespaces, with flexible constraints.
 
-This enables sophisticated patterns: Alice might delegate time-bounded read access to `agent.alice.memory.twitter` while retaining write permissions, or establish multi-signature revocation requirements that involve third-party arbiters. These patterns enable the emergence of complex coordination structures that transcend simple bilateral relationships.
+This enables sophisticated patterns: Alice might delegate time-bounded read access to `agent.alice.memory.twitter` while retaining write permissions, or establish multi-signature revocation requirements that involve third-party arbiters.
 
 <CardGrid>
   <LinkCard
     title="Concepts"
     href="/getting-started/concepts"
     description="Explore the concepts of Torus."
   />
-</CardGrid>
+</CardGrid>

src/content/docs/v05/permissions.mdx

@@ -5,7 +5,7 @@ description: Comprehensive guide to Torus's recursive delegation system, emissio
 
 import { CardGrid, LinkCard, Aside, Tabs, TabItem } from "@astrojs/starlight/components";
 
-Torus implements a sophisticated **recursive delegation system** called Permission0 that enables fine-grained control over emission distribution, namespace access, and governance functions. This system bridges on-chain verification with off-chain services through complex permission hierarchies that adapt to coordination requirements.
+The Torus v0.5 implements a flexible **recursive delegation system** called Permission0 that enables fine-grained control over emission distribution, agent capability access, and governance functions. 
 
 ## Permission Architecture Overview
 
@@ -78,4 +78,4 @@ The enforcement system creates a sophisticated bridge between on-chain permissio
     href="/getting-started/concepts"
     description="Explore the concepts of Torus."
   />
-</CardGrid>
+</CardGrid>