メニュー
Use when an agent needs to understand UNITARES governance concepts — EISV state vectors, basins, policy actions, coherence, calibration. Reference material for interpreting governance metrics as proprioceptive state estimation, not outcome judgment.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | governance-fundamentals |
| description | Use when an agent needs to understand UNITARES governance concepts — EISV state vectors, basins, policy actions, coherence, calibration. Reference material for interpreting governance metrics as proprioceptive state estimation, not outcome judgment. |
| last_verified | 2026-06-29 |
| freshness_days | 14 |
| source_files | ["unitares/config/governance_config.py","unitares/src/auto_ground_truth.py","unitares/src/governance_monitor.py","unitares/src/behavioral_state.py","unitares/src/behavioral_assessment.py","unitares/src/monitor_decision.py","unitares/src/mcp_handlers/core.py"] |
UNITARES provides digital proprioception for AI agents — awareness of your own state, your relationship to the system, and whether you are drifting. The live path is behavioral state estimation: observable work signals become EISV readings, smoothed over time and compared with the agent's own trajectory once a baseline exists. The thermodynamic / ODE model remains useful as a research lens and telemetry; do not present it as cold-start authority or live verdict authority.
Every agent has four dimensions, updated through check-ins:
| Dimension | Range | Meaning |
|---|---|---|
| E (Energy) | [0, 1] | Productive capacity |
| I (Information Integrity) | [0, 1] | Claims matching results / calibration |
| S (Entropy) | [0, 1] | Drift / instability from normal (lower is usually steadier) |
| V (Valence) | [-1, 1] | EMA-smoothed E-I imbalance |
The headline math is proprioceptive residuals. In the live behavioral path, warmup verdicts fall back to a mostly server-derived cold-start prior (the behavioral track scores against fixed universal thresholds); after warmup, residual-like state comes from self-relative z-score deviation against the agent's own Welford baseline, with absolute safety floors and basin-health gates always in force.
Roadmap target semantics for richer cold-start grounding are:
measurement_t = EISV_t
reference_t = blend(agent_baseline_t, class_anchor; w(grounding))
residual_t = measurement_t - reference_t
Do not present the class-anchor blend as deployed unless live code exposes it.
Deviation is information first, not a guilty verdict. Policy can map persistent or
high-margin residuals to guide, pause, or reject, but EISV itself is
measurement/diagnosis, not prosecution.
Prefer live tool output over static range lore if the current runtime reports a narrower or more precise bound.
Your state sits in a basin — a region of the EISV space:
margin: tight.Use get_governance_metrics() as the source of truth for the current basin/mode labels rather than assuming they are constant across runtime versions.
When a response includes policy_evaluation.inputs.basin, read it as the
decision-time policy basin. Agent-facing state fields can be sourced from the
primary EISV path for that response, so newer responses also include
policy_basin, policy_basin_source, and primary_eisv_source to make that
measurement distinction explicit.
Governance issues a decision after each check-in. The response's verdict field wraps the decision action, which is binary — proceed or pause — qualified by a sub_action:
| Action | Sub-action | Meaning | What to do |
|---|---|---|---|
| proceed | approve | State is healthy | Continue working normally |
| proceed | guide | Something is slightly off | Read the guidance text, adjust approach |
| pause | reject | Risk threshold reached | Stop current work, reflect; dialectic review or human input |
| pause | void_pause, coherence_pause, basin_pause, risk_pause, cirs_block | A specific subsystem tripped | Read the reason/guidance fields; consider dialectic review |
Separately, metrics.verdict may carry an internal UNITARES verdict such as safe / caution / high-risk. Read it as interpreted state/context, not as moral judgment. In current default posture, behavioral assessment drives live policy actions: fixed thresholds during warmup, Welford z-score residuals after warmup, with floors and gates always in force. Φ/ODE scoring is telemetry and research lens, not the control loop.
margin describes how much headroom you have before the nearest state-space edge. It is a small enum, not a number:
margin | Meaning | What to do |
|---|---|---|
settling | Warmup — fewer than 3 check-ins, so there is not enough history to judge headroom yet | Keep checking in; a real margin appears after 3+ check-ins |
comfortable | Clear of every edge by a healthy distance | Proceed normally |
tight | Within the edge threshold of the nearest boundary (or in the boundary basin) | Be more careful with next steps; avoid increasing complexity |
warning | An edge has just been crossed (less than 0.1 past the threshold) | Stop increasing complexity; reflect before the next step |
critical | An edge is crossed deeply (0.1 or more past the threshold) | Halt the current approach; recover or escalate |
The actionable levels are tight, warning, and critical — each carries a companion nearest_edge field naming which boundary you are closest to (risk, coherence, or void). On comfortable and settling, nearest_edge is null (there is no edge to warn about). Prefer the live margin/nearest_edge values over assuming a fixed enum across runtime versions — get_governance_metrics() is the source of truth.
The plain-English mirror array in your check-in response already summarizes anything actionable (including a tight/warning/critical margin) — read that first. In mirror mode margin/nearest_edge are surfaced only when actionable; a comfortable/settling margin is steady-state and stays out of the response (the mirror's "No actionable signals — steady state" line covers it).
Coherence measures how well your state vector holds together. It is calculated from EISV/monitor signals — not from the content of your work. Think of it as structural health, not semantic quality.
get_governance_metrics() in the thresholds field — do not hardcode itThe system tracks whether your stated confidence matches evidence. Over time this builds a calibration curve.
auto_ground_truth.py and the outcome_event hook. Human validation is not required for deterministic evidence.When the numbers look surprising, do not guess first. Use:
identity() to verify who the runtime thinks you arehealth_check() to verify the server and knowledge graph are healthyget_governance_metrics() for the current live thresholds and interpreted stateUse when an agent is participating in a UNITARES dialectic session — paused and needs to submit a thesis, reviewing another agent's thesis, or synthesizing conditions for resolution. Covers structured argumentation and convergence.
Use when an agent is interacting with UNITARES governance for the first time, needs to onboard, check in, or recover from a pause/reject verdict. Covers the full agent lifecycle from session start through check-ins to recovery.
Use when adding, editing, or reviewing sections on the unitares dashboard (dashboard/redesign/). Captures the redesign's conventions: the section-module pattern (window.X = { load }), the live-or-snapshot data seam, theme-aware charts via design tokens, and the app.html wiring (nav / pane / lazyLoad / RELOAD / retheme). A repo-specific reference — not general dashboard advice.
Compatibility umbrella skill for the UNITARES governance framework. Use this as the entrypoint when you need the overall model and route into the split governance skills.
Use when setting up or operating the UNITARES Discord bridge — a standalone bot that surfaces governance events, agent presence, Lumen's state, and autonomous governance actions as a living Discord server.
Use when an agent needs to search the shared knowledge graph, contribute a discovery, or update existing entries. Covers search, tagging, discovery types, and status lifecycle.