Skip to content

Core

Core defines the four primary building blocks of a Unitt's foundational workload: Identity, Rules, Policies, and Governance. These sections are established during agent initialization and define the operational identity, behavioral boundaries, and governance model of the Unitt before runtime execution begins. The Core tab refines and evolves these sections over time, allowing each Unitt to develop a more specialized operational profile when needed. Depending on the workload, some or all Core sections may be used, while simpler Unitts may require minimal identity or persona configuration. Each Core file is generated through the primary chat interface while remaining directly editable as markdown files within the Unitt developer platform, allowing engineers to combine conversational configuration with direct source-level control while the platform continuously optimizes and refines runtime alignment and operational stability.

Core is informed by the active agentic-governance research lineage, including the Anthropic subagent identity template, Anthropic Building Effective Agents configuration guidance, the NIST AI Risk Management Framework and NIST AI 600-1 Generative AI Profile, the proposed NIST AI RMF Agentic Profile from CSA Labs, the OWASP LLM Top 10 v2025 and OWASP Top 10 for Agentic Applications 2026, the Microsoft Agent Governance Toolkit, policy-as-code engines including Open Policy Agent / Rego and AWS Cedar (used by Bedrock AgentCore Policy), Vertex AI Agent Builder governance, and the EU AI Act (high-risk obligations effective August 2026) and Colorado AI Act (June 2026). Selection criteria for governance posture are documented in Reference › Research › Assembly Core.

Note

Any Core section may be backed by a remote database, API, or CLI tool, though this is not recommended for identity.md. External integrations should include a corresponding tool-use markdown file and must define a strict recall period to avoid excessive runtime overhead from repeated calls. Policy and governance databases may also be connected directly when automatic runtime updates are required.

flowchart TD
    A[Unitt Core] --> B[Identity.md]
    A --> C[Rules.md]
    A --> D[Policies.md]
    A --> E[Governance.md]

    classDef coreFile fill:#ffd541,stroke:#222021,color:#222021
    class B,C,D,E coreFile

    B --> R[Agent Runtime]
    C --> R
    D --> R
    E --> R

    R --> F[Objectives]
    R --> G[Skills]
    R --> H[Tools]
    R --> I[Patterns]
    R --> J[Connectors]

    B -. defines .-> F
    B -. frames .-> G

    C -. constrains .-> I
    C -. validates .-> H

    D -. authorizes .-> H
    D -. gates .-> J
    D -. adapts .-> I

    E -. supervises .-> R
    E -. audits .-> J
    E -. escalates .-> K[Human Review]

    K --> R

identity.md

Identity defines what a Unitt is at its foundational level. It establishes the operational character, behavioral posture, specialization, authority scope, and interaction expectations of the Unitt before runtime execution begins, creating a persistent operational profile that guides reasoning behavior, communication patterns, execution style, memory interpretation, and policy enforcement throughout the runtime lifecycle. Identity is continuously evaluated during execution and serves as a foundational dependency for runtime selection, tool authorization, governance enforcement, execution patterns, and inter-unit coordination.

The platform treats every agent as a non-human identity with cryptographic provenance; the Cloud Security Alliance "identity explosion" framing applies directly. Identity binds to a signed agent card (A2A v1.2 cryptographic domain verification) and a software bill of materials so the supply chain of any deployed Unitt is auditable end-to-end.

flowchart LR
    IDF[identity.md] --> NHI[Non-Human Identity]
    NHI --> AC[Signed Agent Card]
    NHI --> SBOM[SBOM]
    NHI --> SVC[Service Account / Principal]
    SVC --> POL[Policy Scope]
    AC -. verifies .-> A2A[A2A Inter-Agent]
    SBOM -. attests .-> SUP[Supply-Chain Provenance]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class IDF,NHI,AC,SBOM,SVC,POL,A2A,SUP stage

The Anthropic subagent template names vague identity specification as the number-one cause of duplicated work in multi-agent systems. Identity files in Emergence include five load-bearing fields: operational character, behavioral posture, specialization scope, authority boundary, and interaction expectations.

rules.md

Rules define static behavioral constraints that guide execution patterns, tool validation, and runtime behavior. Unlike Policies, Rules are not conditionally evaluated against runtime state; they are persistent invariants that the agent observes on every step. Rules are the right surface for absolute prohibitions ("never send outbound email without approval"), persistent style guidance, and execution shape preferences that should not change across sessions or workloads. Rules are inherited by every workflow stage, every tool call, and every memory write the Unitt performs.

The line between Rules and Policies follows the Open Policy Agent and AWS Cedar tradition: Rules are static contract clauses, Policies are conditional authorization decisions evaluated at action time. Both feed the same governance enforcement point.

policy.md

Policies define conditional governance and authorization logic used to dynamically regulate runtime behavior. Unlike static Rules, Policies continuously evaluate operational, environmental, security, financial, and contextual conditions to determine whether specific actions, tools, workflows, communications, or autonomous decisions are authorized. Policies act as a primary runtime governance layer that can enforce confidence thresholds, budget limits, approval workflows, security restrictions, and runtime safety controls while preserving operational flexibility, security, and deterministic oversight across distributed execution environments.

Policy must live outside the agent. The established 2024-2026 pattern is to centralize policy evaluation at the tool-calling layer; the agent never decides what is allowed, the engine does. Policy-as-code substrates in production include OPA / Rego (note the Apple / Styra acquisition August 2025 affects long-term OPA governance), AWS Cedar with formal verification (used by AWS Bedrock AgentCore Policy), and the Vertex AI Agent Gateway policy enforcement point.

flowchart LR
    REQ[Runtime Action Request] --> PEP[Policy Enforcement Point]
    PEP -. evaluate .-> PDP[Policy Decision Point]
    PDP -. read .-> POL[policy.md + Cedar / Rego]
    PDP -. read .-> CTX[Runtime Context]
    PDP --> DEC{Decision}
    DEC -->|allow| EX[Execute Action]
    DEC -->|deny| DENY[Deny + Audit]
    DEC -->|escalate| HR[Human Review]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class REQ,PEP,PDP,POL,CTX,DEC,EX,DENY,HR stage

Tool authorization is re-evaluated at every Action transition rather than only at agent boot. Credential rotation, scope revocation, and policy updates take effect on the next step, not on the next session; this is the OWASP Agentic Top 10 recommended posture for blast-radius control.

governance.md

Governance defines the systems, enforcement mechanisms, and operational oversight models used to ensure that Unitts remain controllable, observable, compliant, and aligned during execution. It acts as the authoritative control framework that enforces policies, validates execution behavior, manages escalation, records audit trails, applies operational constraints, and preserves deterministic oversight across autonomous and semi-autonomous runtime systems. Governance operates as a continuous supervisory layer that enables scalable autonomy while maintaining accountability, security, auditability, execution traceability, and human control across the lifecycle of the Unitt.

Governance frameworks the platform aligns to:

flowchart TD
    GOV[governance.md] --> ID[Identity Provenance]
    GOV --> AU[Audit Trail]
    GOV --> ES[Escalation Paths]
    GOV --> OB[Observability]
    GOV --> CO[Compliance Mapping]

    ID --> AGC[Signed Agent Card + SBOM]
    AU --> OTEL[OpenTelemetry GenAI Spans]
    AU --> APP[Append-Only Event Log]
    ES --> HITL[Human-In-The-Loop Interrupts]
    OB --> METRICS[Metrics + Traces + Logs]
    CO --> NIST[NIST AI RMF + Agentic Profile]
    CO --> OWASP[OWASP Agentic Top 10]
    CO --> EU[EU / Colorado AI Acts]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class GOV,ID,AU,ES,OB,CO,AGC,OTEL,APP,HITL,METRICS,NIST,OWASP,EU stage

The audit trail conforms to OpenTelemetry GenAI semantic conventions so observability data is portable across LangSmith, Arize Phoenix, Langfuse, Helicone, and Traceloop without re-instrumentation.

Core Validation

Before a Unitt can run, its Core files must pass an explicit validation pipeline that checks schema, internal consistency, policy compilation, and dry-run governance evaluation. Validation is the platform's first line of defense against the OWASP-Agentic "Specification & System Design" failure cluster (~42% of multi-agent failures per the MAST taxonomy).

flowchart LR
    CFG[Core Files] --> SCH[Schema Validation]
    SCH --> CONS[Internal Consistency Check]
    CONS --> POL[Policy Compile + Lint]
    POL --> DRY[Dry-Run Policy Evaluation]
    DRY --> AUD[Audit Sample Probe]
    AUD --> REP[Validation Report]
    REP -->|pass| READY[Unitt Ready]
    REP -->|fail| FIX[Return To Editor]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class CFG,SCH,CONS,POL,DRY,AUD,REP,READY,FIX stage
  • Schema validation confirms every Core file conforms to its declared shape.
  • Internal consistency verifies that identity claims, rules, and policies do not contradict each other.
  • Policy compile runs Rego / Cedar compilation against the policy.md source.
  • Dry-run evaluation evaluates representative runtime requests against the compiled policy to surface unintended denials or excessive grants.
  • Audit sample probe confirms the observability stack receives expected events from a synthetic run.

Governance Posture

The platform supports three default governance postures, selected per Unitt based on workload tier. The selection matrix is documented in Reference › Research › Assembly Core.

Posture Workload Tier Defaults
Permissive Internal experimentation Identity + Rules; minimal policy; sample audit.
Standard Production internal Identity + Rules + Policies + Audit; OWASP coverage; OTel tracing.
Strict External-facing / regulated Full Core + signed agent card + per-step PDP + EU AI Act mapping + HITL on side effects.

Cross-References

  • Objectives inherit identity, rules, and policies that bound the goal surface.
  • Patterns inherit policies that govern execution-graph branching and stage gating.
  • Connectors inherit credential scope and authorization rules from Core.
  • Tools inherit allowlists, validation requirements, and authorization gates.
  • Skills inherit identity framing and policy scope across reusable knowledge modules.
  • Emergence › Subunits propagates Core scopes across delegated sub-agents.
  • Fabric › Setup wires the Core layer into a multi-agent fabric topology.
  • Reference › Research › Assembly Core documents the citations, selection criteria, and source research.