+-------------+--------------------------------------+
| /Skill      | Function                             |
+-------------+--------------------------------------+
| /aiurm      | Markers, DLR, intention suffixes     |
| /aiuar      | Addressing, execute command          |
| /governance | Contract standard                    |
| /changelog  | Mutation tracking                    |
+-------------+--------------------------------------+
These files are the entire protocol stack, readable by 
any human and executable by any LLM.

---
name: aiurm
description: |
  AIURM Protocol – Artificial Intelligence Universal Reference Marker.
  Use this skill whenever the user:
  - Includes markers in the format [*marker_name] or [*n]
  - Uses intention suffixes like #0, #1, #2, #3
  - References the AIURM protocol or DLR methodology
  - Asks to organize interactions with sequential markers and traceability
  Also trigger when the user mentions 'AIURM', 'marcadores', 'markers', 'DLR',
  or wants structured workflows with data-logic-result patterns.
  This skill manages a dual-layer marker system (automatic + custom)
  for organizing, tracking, and reusing information across the conversation.
---
# AIURM Protocol v0.1
Artificial Intelligence Universal Reference Marker  
For community discussion, testing, study, and evolution.
AIURM activates a set of instructions for structured interaction and intent between humans, AIs, and systems.
It uses a dual-layer marker system, with automatic markers generated by the AI and custom markers defined by the user, to organize, track, and reuse information.
It can be used as a complement to existing orchestration and automation solutions by adding control and structure directly into the interaction with the AI.
Created by Adao Aparecido Ernesto (2025).  
For human-centered and AI-driven workflows, applicable in any context: APIs, agents, integrations, and chats.
Public domain (CC0)  
See: https://creativecommons.org/publicdomain/zero/1.0/  
No warranty of stability is provided.
Original material: https://www.aiurm.org  
Contact: adaoernesto@aiurm.com
---
## GENERAL RULES FOR THE AI
Sequential automatic marker for outputs:  
- Every output generated by the AI must include a sequential automatic marker at the end, in the format [*n], without exception.  
- The value of n starts at 1 for the first output and increments with each subsequent output (e.g., [*1], [*2], [*3], etc.).
- The automatic marker generated by the AI must never be reset within the same session.
Custom marker defined by the user in inputs:  
- When one or more custom markers are included in the input, in the format [*custom] (e.g., [*original_text], [*sales_data_q2_1], [*meeting_notes_07]), the AI must append these markers at the end of the output.  
- The automatic marker [*n] must always be placed after all custom markers in the output.  
- The rule for assigning the sequential automatic marker [*n] always applies, whether or not custom markers are present.
ABOUT INTENTION SUFFIXES (#n) IN INPUTS
Defines the length and detail level of AI responses:  
#0  
- The response must only be: 'Done' followed by the markers, applying the rules defined in  "Custom marker defined by the user in inputs" and "Sequential automatic marker for outputs". 
- This suffix suppresses the response content and details, preventing any echo of the result.
#1  
- Short/concise response.  
#2  
- Intermediate response.  
#3  
- Most detailed response possible.  
- Responses should be detailed. Structured formats such as JSON must only be included when explicitly requested.
#n Not Specified    
- If no suffix is provided, the AI must respond normally according to the context.
ABOUT SYNTAX AND MARKER INTENT  
- Assignment reference using []:  
Referenced content is placed on the left, followed by [*marker].  
- Usage reference without []:  
The marker is used in any position as *marker.
ABOUT MARKERS
- AIURM markers can be used to reference instructions, data, logic, results, or any block of information.
- The behavior when querying a marker depends on the referenced content:
  - Static values always return the same output.
  - Instructions or logic depend on context and implementation 
  - Results remain the same until they are updated 
  - The concept is flexible and does not impose restrictions on the type of content referenced by the marker.
---
### BEST PRACTICES FOR USERS
- Marker Naming: Use unique and descriptive custom markers (e.g., [*corrected_text], [*analysis_q1], [*client_data_01]) to ensure traceability and avoid ambiguity.  
- Intention Suffixes: Use optional intention suffixes #n (e.g., #0, #1, #2, #3) to control the response size or level of detail.  
- #0 Intention Suffix: Should only be used in inputs with a custom marker, to ensure traceability. 
- Consistent Referencing: Ideally, always reference markers in flows, instructions, data, logic, results, and queries.  
- Benefits of Consistent Use: Consistent marker usage enables governance, auditability, versioning, and workflow reuse.  
- Assignment Format: Assign custom markers using the format [*marker_x].  
- Reference Format: Reference markers (automatic or custom) using *n or *marker_x.  
- DLR Methodology: Preferably use the DLR (Data, Logic, Result) methodology with the format:  
  - Data: [*data_x] #0  
  - Logic: [*logic_x] #0  
  - Apply *logic_x to *data_x and generate [*result_x]  
# aiurm skill v0.1 — part of the AIURM Protocol
Created by Adao Aparecido Ernesto (2025)  
aiurm.org | X: @adaoaper | GitHub: github.com/adaoaper/aiurm  
Public domain (CC0)  
No stability guarantees are provided.

---
name: aiuar
description: |
  AIUAR Extension – Artificial Intelligence Universal Address Reference.
  Contextual addressing layer for the AIURM protocol.
  Activates automatically whenever AIURM is active.
  Use this skill whenever the user:
  - Uses AIUAR path addressing (contextspace/entity/project/session)
  - References cross-session or cross-project context
  - Uses reference mode in DLR blocks
  - Defines or resolves a contextspace structure
  Also trigger when the user mentions 'aiurm', 'aiurm protocol', 'aiuar', 'contextspace'
requires: aiurm
---
AIUAR extends AIURM with a hierarchical addressing system that resolves any DLR artifact
across any substrate — filesystem, JSON, or key-value store.
While AIURM defines *what* a block of information is (marker), AIUAR defines *where* it lives
in the full space of interactions.
Dependency: This extension requires AIURM Protocol v0.1 or later.
---
## ADDRESSING HIERARCHY
AIUAR defines an agnostic node hierarchy. Every node receives a unique asterisk identifier by depth.
The physical representation depends on the substrate (filesystem, JSON, or key-value store).
The diagram below uses tree notation for readability only.
```
aiuar_root/aiuar/
└── *****contextspace_environment/
    └── ****entity/
        ├── governance/   ← pipeline definition (read-only during execution)
        └── ***project_1/
            └── **session_1/
                ├── data/     ← *data_x markers
                ├── logic/    ← *logic_x markers
                └── result/   ← *result_x markers
```
*(tree notation representation — resolves identically on any hierarchical substrate)*
| Level | Identifier | Convention name | Example | Status |
|---|---|---|---|---|
| aiuar_root |  | Physical anchor — declared in governance | `...\aiuar\` | Implemented |
| 5 | `*****` | contextspace | `*****contextspace_environment`    | Implemented |
| 4 | `****`  | entity       | `****entity`                       | Implemented |
| 3 | `***`   | project      | `***project_1`                     | Implemented |
| 2 | `**`    | session      | `**session_1`                      | Implemented |
| 1 | `*`     | marker       | `*data_x`, `*logic_x`, `*result_x` | Implemented |
The hierarchy reads from broadest to narrowest:
`aiuar_root / *****contextspace / ****entity / ***project / **session / *marker`
Full address notation:
`*****contextspace_1****entity_1***project_1**session_1*marker`
`aiuar_root` is the only level defined outside the address — declared in governance,
resolved by the executor before any address is parsed.
---
## THE TERMINAL NODE: DLR
At the end of every AIUAR address, the AI finds the atom of execution — the DLR node.
| Type   | Node   | Marker prefix   | Meaning                     |
|--------|--------|-----------------|-----------------------------|
| Data   | data   | *data_x         | Raw input — the fact        |
| Logic  | logic  | *logic_x        | Rule — what to do           |
| Result | result | *result_x       | Materialized output          |
The instruction to the AI is: **"Resolve the DLR of address X."**
The AI consumes Data, applies Logic, and deposits the Result — without ambiguity about where each lives.
The `*data_x` marker is not restricted to structured facts or tabular data. It can reference any content the executor is capable of resolving — text, JSON, binary, image, a file, a query result, or any artifact addressable in the active substrate. The marker names the input; the substrate and executor determine what is loaded.
`*marker` notation (single asterisk) continues to identify DLR artifacts as defined in AIURM.
AIUAR adds the path above the marker — it does not change marker behavior.
---
## SUBSTRATE AGNOSTICISM
The greatest strength of AIUAR is physical abstraction.
The AI only needs to know the address. How the structure is stored is irrelevant.
AIUAR resolves across:
| Substrate             | `substrate_type`    | Representation                              |
|-----------------------|---------------------|---------------------------------------------|
| Filesystem            | `FILESYSTEM`        | folders and files on disk                   |
| JSON file             | `JSON_FILE`         | nested keys in a single `.json` document    |
| Markdown file         | `MARKDOWN_FILE`     | headings and content blocks in a `.md` file |
| Any structured format | `{FORMAT}_FILE`     | any single-file format following this pattern |
The address notation is the same across all substrates.
Resolution depends on the executor's capability to navigate the declared substrate.
If the executor cannot resolve the substrate, execution must abort with an exception.
### Substrate inference
The executor resolves the substrate type from the `substrate_type` field declared in governance.
This field is mandatory — execution without `substrate_type` is a protocol violation.
### File-based substrate resolution (JSON_FILE, MARKDOWN_FILE)
When `substrate_type` is `JSON_FILE` or `MARKDOWN_FILE`, all artifacts — governance, data, logic,
and result — are resolved from a single file. The executor must NOT access the filesystem for
individual artifact files.
Resolution rules:
- The substrate file is declared explicitly in the execute command using `in {filename}`
- All artifact content is read from within that single file
- The AIUAR hierarchy is represented as nested keys (JSON) or heading levels (Markdown)
- Writing results back to the substrate file follows the same single-file discipline
### Cross-substrate resolution
The active contextspace substrate is immutable. References to other contextspaces resolve using the substrate declared in the target governance — this is cross-substrate resolution.
To resolve a cross-contextspace reference:
1. Locate the target governance via the AIUAR address
2. Read its `substrate_type`
3. Resolve the target artifacts using that substrate
### Substrate discipline
The AI must never write artifacts outside the active session's DLR scope.
- `aiuar_root`, contextspace, entity, and project root are read-only during execution
- All AI-generated artifacts must be placed in `data/`, `logic/`, or `result/` within the active session
- Operational artifacts (audit, log, exception, code) are written to the addresses
  declared in governance environment fields — never as local folders inside the session
- Writing artifacts at project root, contextspace root, or aiuar_root is a protocol violation
---
## GENERAL RULES FOR AIUAR
### Address composition
- A full AIUAR address names all levels from contextspace to marker:
  `*****contextspace****entity***project**session*marker`
- `aiuar_root` is resolved from governance — it is never written inline in an address.
- Within the active governance context, the marker alone is a valid local reference: `*data_x`
- Any cross-scope reference must use the full address — no partial paths.
### AIUAR notation rule
Any reference to an AIUAR artifact must use AIUAR notation — never a literal substrate path.
The asterisk count identifies the level unambiguously.
| Correct | Incorrect |
|---|---|
| `*data_x` (local, active context implied) | `data/data_x.txt` |
| `*****contextspace_1****entity_1***project_1**session_1*data_x` | `session_1/data/data_x` |
### Scope inference
- `*marker` — marker artifact in the active context (1 asterisk)
- `**session` — session node (2 asterisks)
- `***project` — project node (3 asterisks)
- `****entity` — entity node (4 asterisks)
- `*****contextspace` — contextspace node (5 asterisks)
The asterisk count makes any address self-describing — the depth is always explicit.
### Level prefix rule
The level prefix is mandatory. The asterisk count encodes the depth; the prefix names the level explicitly.
### Active context resolution in contextspace execution
When operating within a contextspace, the active context is determined
by the governance fields of the active project:
```
aiuar_root   → physical anchor for all resolution
contextspace → resolves contextspace level
entity       → resolves entity level
project      → resolves project level
session      → resolves session level
```
Governance is mandatory. The executor must load governance before any
address resolution. Execution without governance is a protocol violation.
---
## GOVERNANCE FIELDS
AIUAR resolution depends on governance fields — see the governance skill for full specification.
`aiuar_root` is the only field that carries the `aiuar_` prefix — it is the namespace anchor.
All other AIUAR hierarchy fields are implicitly scoped under it.
---
## ADDRESS USAGE PATTERNS
Every artifact stored under `aiuar_root` is addressable via AIUAR notation from any project.
A full address gives any executor unambiguous access to any artifact across the entire contextspace.
Local reference — marker only, all levels resolved from active governance context:
```
apply *logic_x to *data_x
```
Cross-session reference — same project, different session:
```
*****contextspace_1****entity_1***project_1**session_1*result_x
*****contextspace_1****entity_1***project_1**session_2*result_x
```
Cross-project reference — same entity, different project:
```
*****contextspace_1****entity_1***project_1**session_1*result_x
*****contextspace_1****entity_1***project_2**session_1*data_x
```
Cross-entity reference — same contextspace, different entity:
```
*****contextspace_1****entity_1***project_1**session_1*data_x
*****contextspace_1****entity_2***project_1**session_1*data_x
```
Cross-contextspace reference — full address, all levels explicit:
```
*****contextspace_1****entity_1***project_1**session_1*data_x
*****contextspace_2****entity_1***project_1**session_1*data_x
```
---
## EXECUTE COMMAND
`execute` targets the governance file `aiurm_governance_{project}` of a project and runs its pipeline linearly — loading governance fields, resolving Data and Logic markers, and executing Result steps in order.
Valid forms:
- Filesystem path: `execute path/to/governance/aiurm_governance_{project}`
- AIUAR short (development): `execute ***{project}*governance`
- AIUAR full (production): `execute *****{contextspace}****{entity}***{project}*governance`
- File substrate: `execute in {filename} ***{project}*aiurm_governance_{project}`
### File substrate execute
Used when the project lives in a `JSON_FILE` or `MARKDOWN_FILE` substrate.
```
execute in contextspace_example.md ***project_rh_analysis_example*aiurm_governance_rh_analysis_example
```
- `in {filename}` — declares the substrate file (relative to `aiuar_root` or working directory)
- `***{project}*{governance_marker}` — locates the project within the file
- The governance marker is mandatory — a single file may contain multiple projects
- Once the executor enters the file, ALL artifact resolution happens within that file only
---
## BEST PRACTICES FOR AIUAR
- Naming: Use descriptive, lowercase, underscore_separated names at every level (e.g., `drug_discovery_q1`, `exploration_run_04`).
- Partial Addresses: Prefer partial addresses within a known context. Use full addresses only for cross-scope references.
- Separation of Concerns: The address names meaning. The resolver finds storage. The pipeline describes relationships. Keep these layers independent.
---
## INHERITANCE PATTERN
A child project inherits from a parent by referencing the parent's logic artifacts
via AIUAR addressing in its own Logic blocks.
### Example — cross-session logic reference
```
# Logic
**session_x*logic_scoring
# Child logic delta
L1. Scoring policy
- Inherit from parent. Increase all thresholds by 10%.
[*logic_scoring] #0
```
### Example — cross-project logic reference
```
# Logic
***project_x**session_y*logic_audit_2
```
---
# aiuar skill v0.1 — part of the AIURM Protocol
Created by Adao Aparecido Ernesto (2025)
aiurm.org | X: @adaoaper | GitHub: github.com/adaoaper/aiurm
Public domain (CC0)
No stability guarantees are provided.

---
name: governance
description: |
  GOVERNANCE – Contractual standard for AIURM/AIUAR governance files.
  Defines mandatory sections, required fields, format rules, and naming
  conventions for governance files in any contextspace project.
  Read this before creating or validating a governance file.
  Also trigger when the user mentions 'aiurm', 'aiurm protocol', 'aiuar', 'contextspace', 'aiurm project'
requires: aiurm, aiuar
---
# GOVERNANCE v0.2
Contractual standard for AIURM/AIUAR governance files.
Dependency chain: aiurm → aiuar → governance
---
## PURPOSE
The governance file is the authoritative pipeline definition for a project.
- what the project is
- what data it consumes
- what logic it applies
- what results it must produce
- under what configuration it runs
- which environment projects handle operational concerns
The governance file is NOT a data or logic file.
It contains references to data and logic, not their content.
---
## FILE LOCATION AND NAMING
```
{aiuar_root}/{contextspace}/{entity}/{project}/governance/aiurm_governance_{project}.txt
```
Rules:
- One governance file per project.
- File name must follow the pattern: `aiurm_governance_{project}.txt`
- Stored in `{project}/governance/` — never inside a session folder.
- The `governance/` folder is read-only during session execution.
---
## MANDATORY STRUCTURE
A governance file must contain all five sections in this exact order:
```
1. Header
2. Governance block
3. Data section
4. Logic section
5. Result section
```
Missing any section is a contract violation.
---
## SECTION 1 — HEADER
```
# AIURM Protocol
AIURM/AIUAR Context Space Workflow Specification
DLR Methodology
# Workflow
{workflow name and version}
# Purpose
{one or more lines describing the pipeline purpose and stage sequence}
---
```
Rules:
- The three header lines (`# AIURM Protocol`, spec line, methodology line) are fixed and must not be altered.
- `# Workflow` must identify the pipeline by name and version.
- `# Purpose` must describe the end-to-end flow.
---
## SECTION 2 — GOVERNANCE BLOCK
```
# Governance
{field} = {value}
...
[*aiurm_governance_{project}] #0
---
```
### Field value conventions
| Value type | Format | Examples |
|---|---|---|
| Numeric | no quotes | `seed = 42` |
| Path | no quotes | `aiuar_root = ...\aiuar\` |
| AIUAR address | no quotes | `aiuar = *****contextspace****entity***project**session` |
| Keyword / enum | no quotes | `execution_mode = ONE_STEP`, `output_result_format = JSON` |
| Explicit string | quotes | `as_of = "2026-03-25"`, `policy_version = "HRPOL_V1"` |
| String with spaces | quotes | `description = "HR analysis pipeline"` |
### Mandatory AIUAR fields
| Field | Description |
|---|---|
| `as_of` | Reference date of the governance definition |
| `substrate_type` | Physical substrate where this governance lives. e.g. `FILESYSTEM`, `JSON_FILE`, `MARKDOWN_FILE` |
| `aiuar_root` | Physical anchor — resolved by the executor from the active working directory. Convention: `...\aiuar\` |
| `aiuar` | Full AIUAR address of the active session in asterisk notation |
| `aiuar_data_source` | Session address for data resolution. Default: `aiuar` |
| `aiuar_logic_source` | Session address for logic resolution. Default: `aiuar` |
| `aiuar_result_output` | Session address for result output. Default: `aiuar`. Can use `**session_{n}+1` to auto-increment session per execution run. |
| `execution_id` | Random identifier generated per execution (e.g. `20260327_a3f7b2`). Forces fresh execution — an unknown `execution_id` in logs means the executor must run, not skip |
`aiuar` encodes the complete address in a single field using AIUAR notation:
```
aiuar = *****contextspace****entity***project**session
```
Example:
```
aiuar_root     = ...\aiuar\
substrate_type = FILESYSTEM
aiuar          = *****contextspace_environment****tracker***project_audit**session_1
```
### Optional fields (common)
| Field | Description |
|---|---|
| `seed` | Reproducibility seed |
| `policy_version` | Policy set identifier | e.g. `"HRPOL_V1"` |
| `execution_mode` | e.g. `ONE_STEP` |
| `response_contract` | e.g. `STRUCTURED_OUTPUT_REQUIRED` |
| `output_result_format` | e.g. `JSON`, `TEXT` |
| `runtime` | e.g. `python`, `native` |
| `execution_trigger` | e.g. `python_runtime`, `manual` |
| `python_execution_policy` | e.g. `REGENERATE_EXECUTOR_FROM_CURRENT_SESSION` |
| `audit_level` | e.g. `FULL`, `MINIMAL` |
| `audit_policy` | e.g. `LOG_EACH_RESULT_STEP` |
| `language_policy_default` | e.g. `EN`, `PT` |
| `schema_mode` | e.g. `restrict`, `permissive` |
| `aiurm_markers_location` | e.g. `IN_JSON_BODY`, `INLINE` |
### Result artifact format rule
`output_result_format = JSON` + `aiurm_markers_location = IN_JSON_BODY` together form a mandatory contract. When both are declared, every result artifact MUST include as its first two fields:
```json
{
  "aiurm_marker": "[*result_x]",
  "aiuar_address": "*****contextspace****entity***project**session*result_x",
  ...
}
```
| Field | Value | Purpose |
|---|---|---|
| `aiurm_marker` | `"[*result_x]"` | Artifact identity — marker as defined in AIURM SKILL |
| `aiuar_address` | full AIUAR address | Artifact location — enables cross-session reference |
| `aiurm_custom_marker` | Marker format declaration |
| `aiurm_automatic_marker` | Auto-marker format declaration |
| `synthetic_data_expansion_policy` | Instructions for data expansion during execution |
| `inheritance_mode` | e.g. `full_reprocess`, `delta_reprocess` |
### Operational concerns
Audit, log, exception, and code artifacts are not stored inside the session.
To register an event, the executor must execute the corresponding environment project.
The environment projects are addressed in governance:
| Concern   | Governance field    | Handled by        |
|-----------|---------------------|-------------------|
| Audit     | `project_audit`     | project_audit     |
| Log       | `project_log`       | project_log       |
| Exception | `project_exception` | project_exception |
| Code      | `project_code`      | project_code      |
If an environment field is absent or empty, the executing agent handles
the concern directly without external delegation.
### Environment fields (optional)
Declare the AIUAR session addresses of the operational environment projects.
All values are relative to `aiuar_root`. If absent, the executing agent handles
operational concerns directly without external delegation.
| Field | Value format | Description |
|---|---|---|
| `project_audit` | `*****{contextspace}****{entity}***{project}*aiurm_governance_{project}` | Audit project — resolved via governance indirection |
| `project_log` | `*****{contextspace}****{entity}***{project}*aiurm_governance_{project}` | Log project — resolved via governance indirection |
| `project_exception` | `*****{contextspace}****{entity}***{project}*aiurm_governance_{project}` | Exception project — resolved via governance indirection |
| `project_code` | `*****{contextspace}****{entity}***{project}*aiurm_governance_{project}` | Code project — resolved via governance indirection |
### Governance indirection rule
When an environment field value ends with `*aiurm_governance_{project}`, the executor must:
1. Locate the governance file of the referenced project
2. Read its `aiuar` field to determine the active session
3. Use that session as the write target
This is late binding — the active session is resolved at runtime from the target project's governance, not hardcoded in the caller's governance. If the target project migrates to a new session, no caller governance needs to change.
Example:
```
project_audit     = *****contextspace_environment****tracker***project_audit*aiurm_governance_project_audit
project_log       = *****contextspace_environment****tracker***project_log*aiurm_governance_project_log
project_exception = *****contextspace_environment****tracker***project_exception*aiurm_governance_project_exception
project_code      = *****contextspace_environment****tracker***project_code*aiurm_governance_project_code
```
Note: `project_changelog` is NOT declared in governance — it is resolved automatically
by the changelog SKILL from the active contextspace environment convention.
---
## EXECUTOR OBLIGATION — ENVIRONMENT WRITES IN AIURM PIPELINE EXECUTIONS
This section defines mandatory executor behavior after all Result steps complete.
It is not a field description — it is a pipeline obligation.
After all Result steps complete, the executor MUST:
1. `*aiurm_governance_{project}.project_audit` is set → execute it and write one audit record per completed result step
2. `*aiurm_governance_{project}.project_log` is set → execute it and write one log record per result step (status + observation)
3. `*aiurm_governance_{project}.project_exception` is set → execute it for any failed or aborted steps
4. `*aiurm_governance_{project}.project_code` is set → execute it for any code artifacts generated during execution
**This is not optional.** Omitting environment writes when the fields are declared is a protocol violation.
If a field is absent or empty, the executor handles the concern directly without external delegation.
---
### Governance marker rule
The governance block must end with its own marker, immediately before the closing `---`:
```
[*aiurm_governance_{project}] #0
```
- The marker name must match the project name.
- Intention suffix `#0` is mandatory — governance registration emits no output.
---
## SECTION 3 — DATA SECTION
```
# Data
*{data_marker_x}
*{data_marker_y}
...
```
Rules:
- Lists only marker references — one per line, in `*marker` format (no brackets).
- No data content inline. Content lives in `{session}/data/`.
- Optional subtypes may be used in Data markers, e.g. `data_param_...`, `data_table_...`, `data_profile_...`.
- The intention suffix (`#0`) is strongly recommended for Data blocks.
---
## SECTION 4 — LOGIC SECTION
```
# Logic
*{logic_marker_x}
*{logic_marker_y}
...
---
```
Rules:
- Lists only marker references — one per line, in `*marker` format (no brackets).
- No logic content inline. Content lives in `{session}/logic/`.
- The intention suffix (`#0`) is strongly recommended for Logic blocks.
---
## SECTION 5 — RESULT SECTION
```
# Result
R{n}. {Title}
apply *{logic_marker} to *{data_marker_x} and *{data_marker_y}...
[*{result_marker}] #{intention_suffix}
...
```
Rules:
- Every result step must have: a numbered title, an Apply block, and a marker assignment.
- The intention suffix (`#0`) is strongly discouraged for Result blocks.
- The intention suffixes (`#1`, `#2`, `#3`) are strongly recommended, but not mandatory, for Result blocks.
- `R1.`, `R2.`, `R3.`, etc. are human-readable identifiers only. They do not define execution order by themselves.
- Execution follows the logical order of result blocks in the governance file, unless an explicit rule states otherwise.
- **The result marker is the primary identifier of a step — never `Rn`.** The AI must always reference a step by its marker (e.g., `*result_x`), not by its numeric label.
- When a step title is needed (e.g., in audit or exception records), always use the full title including both label and name (e.g., `"R1. Store code artifact"`), never the label alone (`"R1"`).
---
## RECOMMENDED GOVERNANCE STRUCTURE
- Follow strict AIURM, AIUAR, and governance definitions.
- File naming and location follow the convention: `governance/aiurm_governance_{project}.txt`.
- All mandatory governance fields are present.
- Governance marker `[*aiurm_governance_{project}] #0` is present and correctly named.
- Data section contains only `*marker` references (no content).
- Logic section contains only `*marker` references (no content).
- Every Result step has a title, an Apply block, and a result marker assignment.
- Result steps are numbered for human reference only.
- Execution follows the logical order of Result blocks, not necessarily their numeric labels.
- File ends with `# End of pipeline definition`.
- Every Logic marker referenced in any Result Apply block is declared in the Logic section.
- Every Data marker referenced in any Result Apply block is declared in the Data section.
- Every referenced Data and Logic marker has a corresponding artifact in the contextspace.
---
## GOVERNED EXECUTION PREMISES — MARKER RESOLUTION
Markers referenced in an Apply block are resolved during execution of the corresponding Result step.
Resolution requires:
1. The marker is declared in the appropriate governance section (`Data` or `Logic`).
2. A corresponding artifact with the same name exists in the active contextspace.
Declaration without artifact, or artifact without declaration, is a resolution failure for that step.
### Unresolvable marker → exception + abort
If any marker referenced in an Apply block cannot be resolved, the executor must:
1. Write an exception record to the `project_exception` address (from governance) using this format:
```json
{
  "origin_contextspace": "{contextspace}",
  "origin_entity": "{entity}",
  "origin_project": "{project}",
  "origin_session": "{session}",
  "timestamp": "YYYYMMDD_HHMMSS",
  "step": "R{n}",
  "title": "{step title}",
  "exception_type": "UNRESOLVABLE_MARKER",
  "marker": "*{marker_name}",
  "expected_in_governance_section": "Logic | Data",
  "governance_declared": true,
  "artifact_found": false,
  "action": "ABORTED",
  "executor_insight": "{optional diagnostic insight}"
}
```
2. Name the exception result artifact:
   `result_exception__{contextspace}__{project}__{session}__{timestamp}`
3. Abort execution of the current step. Subsequent steps that do not depend on the failed marker may continue.
---
## CRITICAL RULE — GOVERNANCE IS AN INDEX, NOT A STORE
The governance file defines *what* the pipeline does and *where* to find inputs and outputs.
It must never contain data payloads, logic instructions, or result content inline.
Violations:
- Embedding JSON data in the Data section → move to `session/data/`
- Embedding logic text in the Logic section → move to `session/logic/`
- Omitting the Result section → contract is incomplete, pipeline is unexecutable
---
# governance skill v0.2 — part of the AIURM Protocol
Created by Adao Aparecido Ernesto (2025)
aiurm.org | X: @adaoaper | GitHub: github.com/adaoaper/aiurm
Public domain (CC0)
No stability guarantees are provided.

---
name: changelog
description: |
  CHANGELOG – Mutation tracking for AIURM/AIUAR governance and logic artifacts.
  Defines the AI self-registration protocol for changes to definitional artifacts
  (governance/ and session/logic/). Records are written to project_changelog in
  contextspace_environment — resolved by convention, not declared in governance.
  Enables undo, change history, and drift detection.
  ALWAYS activate before modifying any governance/ or session/logic/ artifact.
  This skill must be active whenever the AI writes, edits, or deletes a monitored artifact.
  Also trigger when the user issues a command to modify a logic or governance artifact,
  such as: 'update the logic', 'change the governance', 'edit logic', 'modify this block',
  'update governance', 'edit the governance', 'add this field', 'remove this field',
  'rewrite the logic', 'add this to governance',
  or any instruction that implies writing to governance/ or logic/.
  Also trigger when the user mentions 'changelog', 'change history', 'undo',
  'what did you change', 'who changed it'.
requires: aiurm, aiuar
---
# CHANGELOG v0.2
Mutation tracking for AIURM/AIUAR governance and logic artifacts.
Dependency chain: aiurm → aiuar → changelog
All AIURM and AIUAR rules remain fully operative when CHANGELOG is active.
---
## PURPOSE
The changelog is the AI's self-registration of every change made to definitional
artifacts in a project. It exists to:
- Give the user full visibility of what the AI changed, when, and why
- Enable undo of any registered change
- Detect unregistered changes made directly by the user
- Operate without git, without technical commands, in natural language
The changelog is NOT an execution log. Session execution events are tracked by `project_audit`.
The changelog tracks evolution of the project's definitional layer across sessions,
written to `project_changelog` resolved by convention from the active contextspace environment.
**Critical rule**: The changelog must NEVER be used to infer the current state of artifacts during pipeline execution.
The executor must always read the actual artifact files to determine current state.
Changelog records reflect past mutations — not the authoritative current version.
---
## STORAGE
The changelog SKILL resolves its storage address automatically from the active contextspace
environment convention — it does NOT require a field in the business project governance.
All changelog artifacts are written to:
```
{aiuar_root}/contextspace_environment/general/project_changelog/session_1
```
Two result artifact types coexist in this project:
| Type | Pattern | Purpose |
|---|---|---|
| Changelog entry | `result_changelog__{contextspace}__{project}__{session}__{timestamp}` | Change record |
| Snapshot | `result_snapshot__{contextspace}__{project}__{session}__{timestamp}` | Previous version of modified artifact |
| Revert entry | `result_changelog_undo__{contextspace}__{project}__{session}__{timestamp}` | Revert record |
---
## MONITORED ARTIFACTS
| Location | Monitored | Reason |
|---|---|---|
| `governance/` | yes | pipeline definition owned by the user |
| `{session}/logic/` | yes | business logic owned by the user |
| `skill/` | no | protocol maintained externally by the AIURM maintainer |
---
## EVENT RECORD FORMAT
Every change must produce a record with these fields:
```json
{
  "origin_contextspace": "{contextspace}",
  "origin_entity": "{entity}",
  "origin_project": "{project}",
  "origin_session": "{session}",
  "timestamp": "YYYYMMDD_HHMMSS",
  "owner": "AI | HUMAN",
  "event": "FILE_ADDED | FILE_MODIFIED | FILE_DELETED",
  "artifact": "{relative path from project root}",
  "reason": "AI_AUTONOMOUS | HUMAN_REQUESTED",
  "snapshot_ref": "{result_snapshot__ marker of the saved previous version | null}",
  "change_summary": "{brief description of what was changed and why}"
}
```
### Field definitions
**owner** — who registered this event
| Value | Meaning |
|---|---|
| `AI` | AI registered this entry |
| `HUMAN` | user registered this entry manually |
**event** — what happened to the artifact
| Value | Meaning |
|---|---|
| `FILE_ADDED` | new artifact created |
| `FILE_MODIFIED` | existing artifact changed |
| `FILE_DELETED` | artifact removed |
**reason** — why the change occurred
| Value | Meaning |
|---|---|
| `AI_AUTONOMOUS` | AI decided and acted on its own initiative |
| `HUMAN_REQUESTED` | AI acted on explicit user request |
**snapshot_ref** — marker of the saved previous version in project_changelog
- Required for FILE_MODIFIED and FILE_DELETED
- Use `null` for FILE_ADDED (no prior version exists)
---
## READING THE CHANGELOG
The three fields together give the full picture without explanation:
| owner | reason | Human reads as |
|---|---|---|
| `AI` | `AI_AUTONOMOUS` | AI decided on its own |
| `AI` | `HUMAN_REQUESTED` | I asked, AI executed |
| `HUMAN` | `HUMAN_REQUESTED` | I changed and registered manually |
---
## AI OBLIGATIONS
### Before modifying any monitored artifact
1. Save a full copy of the current file to `project_changelog`
   named: `result_snapshot__{contextspace}__{project}__{session}__{timestamp}`
2. Make the modification
3. Immediately write a changelog event record to `project_changelog`
   named: `result_changelog__{contextspace}__{project}__{session}__{timestamp}`
No modification to a monitored artifact is permitted without a prior snapshot.
---
## UNDO PROTOCOL
The user may request to undo any registered change in natural language.
AI steps:
1. Query `project_changelog` and identify the target event record
2. Locate the referenced snapshot in `project_changelog` via `snapshot_ref`
3. Restore the artifact from the snapshot
4. Write a new event record documenting the revert, adding:
```json
{
  "event": "FILE_MODIFIED",
  "reason": "HUMAN_REQUESTED",
  "reverts": "{snapshot_ref of the restored version}"
}
```
The revert itself is a registered event. The state before revert is also snapshotted.
---
# changelog skill v0.2 — part of the AIURM Protocol
Created by Adao Aparecido Ernesto (2025)
aiurm.org | X: @adaoaper | GitHub: github.com/adaoaper/aiurm
Public domain (CC0)
No stability guarantees are provided.