mirai-graph 1.3.0 → 2.1.0

package/standard/feature-implementation-traceability.md

@@ -1,68 +0,0 @@
-# Feature Implementation Traceability
-
-Feature Implementation Traceability is a Mirai Graph pattern for connecting feature intent to implementation, tests, evidence, documentation, and review.
-
-It answers a simple governance question:
-
-```text
-For each feature, what proves where it is implemented, how it was tested, what remains incomplete, and which transition decision it supports?
-```
-
-## Scope
-
-The traceability layer is useful for software products, AI employees, research systems, organizational processes, and other projects where generated or human plans must be tied to delivered work.
-
-It should track:
-
-- feature or capability reference;
-- owning component or package;
-- implementation mapping;
-- dependency mapping;
-- test and validation evidence;
-- documentation evidence;
-- review status;
-- known gaps and blockers;
-- supported transition or release decision.
-
-## Required Separation
-
-Mirai Graph keeps these states separate:
-
-- `specified`: the feature is described;
-- `mapped`: the feature is connected to expected implementation locations or work items;
-- `implemented`: the work has concrete implementation evidence;
-- `tested`: validation evidence exists;
-- `reviewed`: semantic or human review exists;
-- `accepted`: the relevant gate accepted the work;
-- `released`: release or publication gate passed.
-
-`specified`, `mapped`, `ready_to_execute`, and `ready_to_code` are not implementation.
-
-## Mapping Rules
-
-Every mapping should declare:
-
-- `feature_ref`;
-- `implementation_refs`;
-- `test_refs`;
-- `evidence_refs`;
-- `review_refs`;
-- `documentation_refs`;
-- `status`;
-- `confidence`;
-- `known_gaps`.
-
-An implementation mapping without evidence should stay below accepted readiness.
-
-## Governance Use
-
-Traceability supports:
-
-- cockpit instrumentation;
-- process-transition validation;
-- release readiness review;
-- technology quality feedback;
-- drift detection;
-- Kaizen classification.
-
-It does not create approval. It gives reviewers and validators a reproducible path from intent to work evidence.

package/standard/federation-health.md

@@ -1,42 +0,0 @@
-# Federation Health
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Federation health summarizes whether a graph-managed federation is routable,
-explainable and safe to use as a context/control layer.
-
-## Health Signals
-
-A health dashboard should include:
-
-- skill or capability count;
-- runtime-ready count;
-- stale graph count;
-- watch conflict count;
-- unresolved conflict count;
-- failed fixture count;
-- high-risk routes without explanation;
-- fallback-required route count;
-- blocked route count;
-- route regression status;
-- pending learning proposals;
-- conflict details with severity and next action.
-
-## Conflict Details
-
-Counts are not enough. A useful dashboard should identify:
-
-- conflict family id;
-- affected capabilities;
-- failed fixture ids;
-- latest route explanation references;
-- required owner review;
-- next action;
-- severity.
-
-## Boundary
-
-Health dashboards are evidence and control surfaces. They do not grant runtime
-authorization or canonical write permission.

package/standard/feedback-learning-gate.md

@@ -1,101 +0,0 @@
-# Feedback Learning Gate
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-This section defines how feedback can improve a Mirai Graph-modeled AI employee
-without allowing uncontrolled self-modification.
-
-## Core Flow
-
-```text
-feedback -> proposal -> replay/evaluation -> approval -> canonical graph update
-```
-
-## Feedback
-
-Feedback is an observation, review, correction, rating, error report or outcome
-signal.
-
-Feedback may come from:
-
-- a human reviewer;
-- an audited result;
-- a failed action;
-- a successful action;
-- a monitoring signal;
-- a peer AI employee;
-- an external evaluation.
-
-Feedback is evidence. It is not automatically a behavior change.
-
-## Learning Proposal
-
-A learning proposal describes what should change in the graph.
-
-It may propose:
-
-- updating a policy;
-- adding or changing a lesson;
-- changing a workflow;
-- changing a skill description;
-- adding a risk;
-- changing a delegation rule;
-- adding a new approval requirement.
-
-## Replay Or Evaluation
-
-Before acceptance, the proposal should be evaluated.
-
-Evaluation may include:
-
-- replaying the failed scenario;
-- comparing expected and actual result;
-- checking policy impact;
-- checking safety or public-release risk;
-- checking whether the lesson is too broad;
-- checking whether the change conflicts with existing graph state.
-
-## Approval
-
-Learning changes that affect future behavior should pass a governance gate.
-
-Examples:
-
-- `feedback_learning_before_behavior_update`;
-- `human_review_before_canonical_write`;
-- `public_safety_before_release`;
-- `approval_before_external_action`.
-
-## Canonical Update
-
-After approval, a canonical graph update may add, deprecate or change objects
-and relations.
-
-The update should preserve:
-
-- feedback evidence;
-- proposal id or source;
-- approval record;
-- affected object and relation ids;
-- limitation or rollback note when relevant.
-
-## Anti-Patterns
-
-- Treating every feedback item as a permanent lesson.
-- Letting a failed action automatically rewrite policy.
-- Updating behavior without preserving evidence.
-- Merging runtime logs directly into canonical memory.
-- Accepting broad lessons from one narrow example.
-
-## Claim Rule
-
-Passing through a feedback learning gate supports this limited claim:
-
-```text
-The behavior update was proposed, evaluated and accepted through a recorded
-governance process.
-```
-
-It does not prove the updated behavior is universally correct.

package/standard/goal-vector-quality-control.md

@@ -1,128 +0,0 @@
-# Goal Vector Quality Control
-
-Status: 1.0 release-candidate extension contract
-
-## Purpose
-
-Goal Vector Quality Control checks whether meaningful work moves toward the
-declared final outcome instead of only producing useful-looking activity.
-
-It is an extension contract, not a standalone Mirai Graph profile. It composes
-project management, implementation control, technology quality feedback,
-dynamic episode evidence and semantic intent resolution.
-
-## Core Pattern
-
-Goal Vector Quality Control combines forward execution and reverse audit.
-
-Forward execution:
-
-```text
-start state
--> final outcome
--> current goal
--> stages
--> batches
--> evidence
--> completion claim
-```
-
-Reverse audit:
-
-```text
-final outcome
--> required qualities
--> checks and evidence
--> actual result
--> workflow decisions
--> drift findings
--> correction route
-```
-
-Every meaningful batch should be able to state:
-
-```text
-This batch advances <goal/final outcome> by <specific contribution>.
-```
-
-If that link is missing, the work may be drift even when it produced files,
-tests or reports.
-
-## Boundary
-
-Goal Vector Quality Control is not authorization.
-
-```text
-goal vector != approval
-reverse audit != release permission
-evidence != acceptance
-tests != semantic acceptance
-correction route != canonical update
-```
-
-The contract may produce quality evidence, drift findings, correction routes,
-Kaizen items and graph proposals. It must not grant production permission,
-approve deployment, mutate source systems or update canonical graph state.
-
-## Required Fields
-
-- `start_state`
-- `final_outcome`
-- `work_scale`
-- `goal_vector`
-- `vector_segments`
-- `batch_vector_links`
-- `required_qualities`
-- `quality_evidence`
-- `reverse_audit`
-- `drift_findings`
-- `correction_routes`
-- `quality_verdict`
-- `completion_claim`
-- `canonical_write_allowed`
-
-## Verdicts
-
-- `PASS`
-- `PASS_WITH_NOTES`
-- `PARTIAL`
-- `CORRECTION_REQUIRED`
-- `BLOCKED`
-- `FAIL`
-
-`PASS` and `PASS_WITH_NOTES` require evidence, reverse audit and no unresolved
-blocking drift findings. `PARTIAL` is suitable for in-progress work when the
-vector is visible but the final outcome is not yet complete.
-
-## Integration Points
-
-- `project_management`: owns start state, final outcome, goal vector, stages,
-  tasks and batch movement.
-- `implementation_control`: owns launch/completion guards, work states,
-  evidence boundaries and false completion guards.
-- `technology_quality_feedback`: owns reverse audit, finding classification,
-  semantic acceptance and correction routing.
-- `dynamic_episode_layer`: records what happened, which path was selected and
-  why alternatives were blocked.
-- `semantic_intent_resolution`: captures intended final outcome and missing
-  context before execution starts.
-
-## Public Safety
-
-Public examples must be synthetic. Do not publish private project workflow
-contents, private runtime traces, customer messages, access details, tokens,
-internal handoff payloads or raw logs.
-
-## Conformance
-
-Initial public conformance is synthetic:
-
-- `G0_concept`: extension contract only.
-- `G1_synthetic_fixture`: synthetic example and negative fixtures.
-- `G2_internal_pilot`: private pilot evidence with public-safe summary.
-- `G3_replay_regression`: replay/regression evidence for drift reduction.
-- `G4_audited_runtime`: audited operational use with retention and review
-  policy.
-
-The public `1.0` release-candidate layer should claim no more than
-`G1_synthetic_fixture` until sanitized pilots and replay evidence are available.

package/standard/governance.md

@@ -1,137 +0,0 @@
-# Mirai Graph Governance
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Governance rules define how Mirai Graph controls updates, generated context,
-public claims and action-capable workflows.
-
-The central distinction is:
-
-```text
-suggestion != decision
-generated context != canonical state
-evidence != claim
-plan != action
-private material != public material
-```
-
-## Governance Gate
-
-A governance gate is a rule or checkpoint that decides whether something may
-proceed.
-
-Gate examples:
-
-- accept object into canonical graph;
-- accept relation into canonical graph;
-- publish material;
-- execute action;
-- generate external-facing context;
-- claim validation;
-- migrate from one standard version to another.
-
-## Gate Record
-
-A gate record should include:
-
-```json
-{
-  "id": "gate.public_release.synthetic_benchmark",
-  "kind": "governance_gate",
-  "title": "Public release check for synthetic benchmark",
-  "summary": "Checks that benchmark material is synthetic and public-safe before release.",
-  "readiness": "accepted",
-  "evidence": [],
-  "profile": "core"
-}
-```
-
-Future schemas may define a separate gate-result structure.
-
-## Update Governance
-
-Canonical graph updates should be gated when they:
-
-- change accepted objects;
-- change accepted relations;
-- resolve or introduce contradictions;
-- affect public claims;
-- affect action permissions;
-- change conformance status.
-
-Generated suggestions may propose updates, but they do not become canonical
-state until accepted through the appropriate gate.
-
-## Action Governance
-
-If a Mirai Graph implementation supports actions, it must separate:
-
-- proposed action;
-- authorized action;
-- executed action;
-- action evidence;
-- rollback or recovery path.
-
-Action-capable implementations need stricter gates than documentation-only
-implementations.
-
-## Public Release Governance
-
-Before public release, check:
-
-- no private source material;
-- no secrets;
-- no customer or employee data;
-- no private repository paths;
-- no unsupported validation claims;
-- licensing is clear;
-- synthetic materials are marked as synthetic.
-
-## Claim Governance
-
-Claims must be gated by evidence level.
-
-Example:
-
-- `The synthetic benchmark calculation is reproducible` may be claimed after a
-  passing benchmark run.
-- `Mirai Graph improves real-world productivity` requires real-world validation
-  evidence.
-- `Mirai Graph is universally valid` should not be claimed without broad
-  independent replication.
-
-## Human Oversight
-
-Mirai Graph can support AI-assisted work, but governance-sensitive operations
-should have human oversight.
-
-Human oversight is especially important for:
-
-- public claims;
-- external publication;
-- irreversible actions;
-- permission changes;
-- legal, financial, safety or privacy-sensitive decisions.
-
-## Failure Handling
-
-A governance gate may produce:
-
-- `pass`;
-- `pass_with_notes`;
-- `blocked`;
-- `rejected`;
-- `needs_more_evidence`.
-
-Blocked items should remain traceable. Do not delete a blocked element merely to
-make the graph look clean.
-
-## Anti-Patterns
-
-- Letting generated AI output directly mutate canonical state.
-- Treating approval for one profile as approval for all profiles.
-- Publishing synthetic evidence as real-world proof.
-- Hiding governance failures.
-- Combining private implementation notes with public standard text.

package/standard/graph-as-ai-brain.md

@@ -1,81 +0,0 @@
-# Graph As AI Brain
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-This section defines how Mirai Graph can model the stable brain of an AI
-employee without turning the standard into one specific AI-agent runtime.
-
-## Core Principle
-
-```text
-AI employee is not a prompt.
-AI employee is a governed runtime over an evolutionary graph.
-The graph is the canonical brain/state/control model.
-The runtime executes through tools, policies, approvals and audit.
-```
-
-## Brain Model
-
-In this model, the graph stores durable state:
-
-- identity of the AI employee;
-- department and role;
-- skills and specializations;
-- knowledge and memory references;
-- tools and capabilities;
-- policies and approval gates;
-- workflows and automation rules;
-- actions, results, feedback and lessons;
-- federation endpoints.
-
-The graph does not directly execute actions. It provides the structured state
-used by an implementation to generate context, select policies, request
-approval, call tools and record results.
-
-## Runtime Model
-
-An implementation may run an AI employee using:
-
-- an LLM or another reasoning engine;
-- a tool adapter layer;
-- queue or event processing;
-- policy evaluation;
-- approval workflows;
-- audit logging;
-- feedback evaluation.
-
-These runtime choices are outside the core standard. Mirai Graph standardizes
-the graph shape and safety boundaries that make implementations inspectable.
-
-## Required Distinctions
-
-An AI-employee implementation should keep these states separate:
-
-- canonical graph state;
-- generated context;
-- runtime decision;
-- proposed action;
-- approved action;
-- executed action;
-- audited result;
-- feedback;
-- accepted lesson or behavior update.
-
-Merging these states makes it difficult to audit why the employee acted, which
-policy applied, whether approval was required and what changed after feedback.
-
-## Anti-Patterns
-
-- Treating a prompt as the entire AI employee.
-- Letting generated context mutate canonical graph state.
-- Treating a runtime decision as permission to execute.
-- Recording only the final result without proposed action, policy and approval
-  trace.
-- Learning from feedback without replay, evaluation and approval.
-
-## Profile Link
-
-The `ai_employee` profile provides the first public object and relation set for
-this model.

package/standard/graph-dna-alignment.md

@@ -1,50 +0,0 @@
-# Graph DNA Alignment
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Graph DNA alignment keeps components, work batches, generated projections and
-runtime feedback aligned with the larger system purpose.
-
-It prevents local optimization: a component can be internally detailed but still
-harm the parent graph if it owns the wrong scope, violates invariants or drifts
-from the evolution vector.
-
-## Core Pattern
-
-```text
-parent DNA
--> component DNA
--> ownership boundary
--> invariants
--> anti-patterns
--> success criteria
--> alignment result
-```
-
-## Minimum Concepts
-
-- parent system DNA: mission, evolution vector and non-negotiable principles;
-- component DNA: why the component exists and what value it creates;
-- owns: responsibilities the component is allowed to own;
-- must not own: responsibilities that must stay elsewhere;
-- invariants: properties that must remain true during change;
-- anti-patterns: recurring shapes that indicate drift;
-- success criteria: observable evidence that the component serves the parent.
-
-## Rules
-
-- A component must not redefine the parent system direction.
-- A component that conflicts with parent DNA needs a proposal or a blocker.
-- Generated projections can reveal DNA gaps but cannot change DNA by
-  themselves.
-- Implementation work should load relevant DNA before crossing a launch gate.
-
-## Schema
-
-Machine-readable alignment results can be validated with:
-
-```text
-schemas/graph-dna-alignment.schema.json
-```

package/standard/graph-dna.md

@@ -1,70 +0,0 @@
-# Mirai Graph DNA
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Mirai Graph DNA defines why a graph exists, what it should become and which
-principles must guide its growth.
-
-Without DNA, a graph can collect objects and relations but still drift into an
-uncontrolled archive. DNA keeps growth aligned with purpose.
-
-## Definition
-
-Graph DNA is the development contract of a graph.
-
-It answers:
-
-- why the graph exists;
-- what larger system it serves;
-- what kind of growth it should enable;
-- which principles cannot be violated;
-- which object families belong inside the graph;
-- which entity families should become separate graphs;
-- how success will be recognized.
-
-## Minimum Fields
-
-```json
-{
-  "schema_version": "0.1.0",
-  "graph_id": "example.graph",
-  "purpose": "Why this graph exists.",
-  "parent_dna_ref": null,
-  "evolution_vector": "Where the graph should develop.",
-  "non_negotiable_principles": [],
-  "allowed_entity_families": [],
-  "success_criteria": []
-}
-```
-
-## Alignment Rule
-
-Every significant accepted object should be able to explain:
-
-- how it serves the graph purpose;
-- what it contributes to the evolution vector;
-- what would be harmed if it were missing;
-- whether it belongs in this graph or should become a separate graph.
-
-If an object cannot answer these questions, keep it as a draft idea or separate
-graph candidate.
-
-## Relationship To Graph Seed
-
-Graph DNA defines what the graph must become.
-
-Graph Seed defines how the first controlled growth step should start.
-
-```text
-Graph DNA -> Graph Seed -> Graph Embryo -> Canonical Graph State
-```
-
-## Anti-Patterns
-
-- Creating many objects without a purpose.
-- Treating every related entity as part of the same graph.
-- Adding relation types that do not support the evolution vector.
-- Optimizing for local detail while losing the larger system goal.
-- Changing DNA silently after downstream artifacts depend on it.