How CoreID works.

CoreID Concepts & Terminology

Introduction

CoreID is built around the principle that intelligent systems require a stable, persistent identity in order to be governed responsibly over time.

This section explains the foundational concepts that CoreID is based on, including what a CoreID is, how identity anchoring works, how governance and compliance are separated, and how visibility is controlled.

All concepts described here apply continuously across the full lifecycle of an intelligent system, not at a single point in time.

Intelligent System

Any software system that performs decision-making, inference, classification, or adaptive behavior, whether model-based, rule-based, or hybrid.

CoreID uses the term "intelligent system" rather than "AI model" to encompass the full range of systems that benefit from identity-anchored governance. This includes machine learning models, but also expert systems, algorithmic decision systems, and hybrid architectures that combine multiple approaches.

CoreID

A CoreID is a globally unique, persistent identifier assigned to an intelligent system.

It serves as the single, enduring reference point for that system across its entire lifecycle, regardless of how the system changes, evolves, or is redeployed.

Once assigned, a CoreID remains stable even when:

• models are updated or retrained
• versions change
• deployments expand or contract
• jurisdictions are added or removed
• ownership and operational responsibility may change over time, but the CoreID remains permanently associated with the system, preserving its full governance and compliance history

Rather than treating each version or deployment as a separate, disconnected entity, CoreID ensures continuity by anchoring all records to one identity.

Identity Anchor

The identity anchor is the principle that all governance, operational, and compliance-related information is tied back to a single CoreID.

This includes:

• Descriptive metadata
• Deployment context
• Governance records
• Compliance profiles
• Attestations and reviews
• Historical versions and lineage

By anchoring all records to a single identity, CoreID prevents fragmented documentation, duplicated compliance efforts, and loss of historical context.

The identity anchor enables long-term traceability and accountability without requiring organizations to rebuild records each time a system evolves.

Organizational status classifications associated with a CoreID (such as Attested) represent platform-level accountability states and do not constitute governmental certification, regulatory approval, or independent legal validation. Additional verification classifications may be introduced as the platform evolves.

Governance Documents

Governance documents capture the day-to-day governance activity of an intelligent system after deployment.

While compliance defines what must be proven, operational governance defines how the system is actually managed over time.

AI systems evolve continuously. They are updated, retrained, overridden, monitored, and integrated into changing environments. Governance documents ensure these events remain structured, traceable, and anchored to a persistent CoreID.

What Counts as a Governance Document

Governance documents may include:

• Monitoring and drift logs
• Incident reports and investigations
• Human oversight and approval events
• Configuration and version changes
• Fail-safe activations and rollback events
• Decision accountability logs
• Third-party dependency updates
• Security and resilience evidence

These records remain private by default and are visible only to authorized organizational users unless explicitly disclosed.

Why Governance Documents Matter

Without structured governance documents:

• Incidents are logged in scattered tools
• Approvals are undocumented
• Overrides lack traceability
• Vendor updates go unnoticed
• Audits require reconstruction

CoreID prevents fragmentation by anchoring operational events to a single persistent system identity.

Relationship to Governance and Compliance

Operational governance:

• Exists regardless of regulatory status
• Is continuous
• Is organization-controlled

Compliance capabilities structure governance documents into framework-aligned snapshots. They build on governance and do not replace it. The level of compliance structure applied depends on the governance model and frameworks selected by the organization.

CoreID does not certify compliance. It provides structured governance infrastructure.

Internal Governance vs Compliance

CoreID separates governance from compliance by design.

These are related, but not the same.

Internal Governance

Internal governance is the foundation of CoreID.

It supports how organizations internally manage, oversee, and document their intelligent systems.

Internal governance includes:

• system purpose and context
• deployment details
• risk considerations
• operational notes
• internal controls
• monitoring and review records
• version history and lineage

• Always available
• Private by default
• Organization controlled

It exists regardless of whether a system is subject to regulation.

Compliance

Compliance capabilities are always available within CoreID and are structured alongside governance.

The depth of compliance structure applied depends on the organization's governance model (Self-Governed or Structured) and the regulatory frameworks applicable to their systems. CoreID:

• structures governance data into compliance records
• maps disclosed attributes to applicable frameworks
• preserves structured snapshots of compliance state

Compliance does not replace governance. It builds on governance that already exists.

CoreID does not require organizations to redesign systems or duplicate records. Governance structure (Self-Governed or Structured) is automatically derived from the organization's role configuration.

Public vs Private Visibility

CoreID operates on a privacy-first visibility model.

All data within CoreID is private by default.

Organizations explicitly choose:

• whether any information is disclosed externally
• which specific fields are visible
• when disclosure is enabled or disabled

Public visibility is:

• Intentional
• Granular
• Controlled
• Revocable

Sensitive information is never exposed by default, and internal governance records remain private unless explicitly disclosed.

Conceptual Summary

At a foundational level, CoreID is built on four principles:

• 1 Persistent identity through a single CoreID
• 2 Continuity over time through identity anchoring
• 3 Separation of governance and compliance
• 4 Controlled, intentional visibility

These concepts form the basis for how CoreID operates across architecture, lifecycle management, disclosure, and compliance support.

System Architecture

Introduction

CoreID is designed as a modular system that separates identity, governance, disclosure, and public verification into clearly defined components.

This separation ensures that sensitive governance data remains private, while approved information can be disclosed externally in a controlled and auditable way.

This section provides a high-level view of CoreID's architecture and explains how its major components interact without exposing internal implementation details.

Architectural Overview

At a high level, CoreID consists of four primary architectural layers:

This architecture is designed to support any intelligent system - regardless of model type, autonomy level, or governance exposure.

• Enterprise Portal
• Identity & Metadata Layer
• Disclosure & Control Layer
• Public CoreID Registry

Each layer has a distinct purpose and operates under different access and visibility rules.

Enterprise Portal

The Enterprise Portal is the private, authenticated interface used by organizations to manage their CoreID records.

Through the Enterprise Portal, authorized users can:

• Create and manage CoreIDs
• Define system and deployment metadata
• Maintain governance records
• Manage versioning and lineage
• Prepare compliance profiles
• Control visibility and disclosure settings

Access to the Enterprise Portal is role-based and restricted to authorized organizational users.

All sensitive information and governance documents are managed exclusively within the Enterprise Portal and are never publicly exposed.

Identity & Metadata Layer

The Identity & Metadata Layer stores the structured records associated with each CoreID.

This layer includes:

• The CoreID identifier
• Descriptive system metadata
• Deployment and contextual information
• Version and lineage relationships
• Governance and compliance references

All records in this layer remain tied to the CoreID identity anchor, ensuring continuity across system evolution.

This layer supports both internal governance and compliance workflows but does not determine visibility on its own.

Organizational verification status (currently Attested) is recorded as structured metadata within this layer. This classification represents a platform-level accountability state and does not independently confirm legal existence, regulatory approval, or governmental certification.

Disclosure & Control Layer

The Disclosure & Control Layer governs what information may be shared outside the Enterprise Portal.

This layer enables organizations to:

• Explicitly approve or restrict disclosure
• Control visibility at the field level
• Manage public vs private status
• Revoke disclosure when required

Disclosure decisions are:

• Intentional
• Auditable
• Reversible

By design, disclosure controls ensure that only non-sensitive, approved metadata can be exposed externally.

Internal governance data, governance documents, and supporting evidence remain inaccessible to public users.

Public CoreID Registry

The Public CoreID Registry is a read-only, public-facing interface.

It displays only information that:

• Has been explicitly approved for disclosure
• Is non-sensitive
• Is safe for public verification

The registry enables external parties to:

• Verify the existence of a CoreID
• Confirm declared attributes such as risk tier, jurisdiction, and status
• Associate a system with its owning organization

The Public CoreID Registry does not provide access to governance records, compliance evidence, internal documentation, or operational data.

It is designed to support verification, not governance.

Separation of Concerns

CoreID's architecture enforces a clear separation of concerns:

• Governance occurs inside the Enterprise Portal
• Disclosure is controlled through explicit configuration
• Verification occurs through the Public CoreID Registry

These functions are deliberately separated to:

• Protect sensitive information
• Prevent accidental exposure
• Support regulatory scrutiny
• Enable trust without over-disclosure

The Public Registry is an output of governance, not a governance tool itself.

Architectural Principles

CoreID's high-level architecture is guided by the following principles:

• Privacy by default
• Disclosure by choice
• Persistence of identity
• Auditability without exposure
• Clear boundary between private and public systems

These principles ensure that CoreID remains adaptable as governance and regulatory expectations evolve.

Governance Lifecycle

Introduction

The CoreID governance lifecycle describes how an intelligent system is identified, governed, and maintained over time.

The lifecycle reflects real-world system development and deployment practices, while ensuring continuity, traceability, and accountability through a single CoreID.

Verification status supports governance traceability and internal accountability but does not substitute for regulatory, legal, or independent compliance review.

Each stage of the lifecycle remains tied to the same CoreID identity anchor, regardless of how the system evolves.

This lifecycle applies to all intelligent systems, regardless of autonomy level, deployment scale, or governance exposure.

Lifecycle Overview

The governance lifecycle supports both:

• internal governance, which is always available, and
• compliance preparation, which is activated only when required.

Lifecycle stages are cumulative. Earlier records are preserved as the system progresses, ensuring historical integrity.

Governance Models

CoreID supports multiple governance structures to reflect how responsibility, review, and accountability are organized within an organization.

Governance structures define how decisions are owned and approved.

Roles and permissions operate within a governance structure but do not replace it.

CoreID does not require a specific governance structure. Organizations remain responsible for selecting the approach appropriate to their team size, system risk profile, and regulatory obligations.

Self-Governed

Self-Governed means that creation, review, and approval activities are performed by the same accountable individual.

This structure is typically used where governance responsibilities are held by a single person and formal role separation is not in place.

This model is common for:

• Solo founders
• Early-stage teams
• Internal tools
• Fast-moving or experimental projects

Self-Governed records are valid and traceable. They reflect that governance decisions are performed by a single accountable individual rather than distributed across multiple governance roles.

Structured Governance

Structured Governance means that governance activities are distributed across defined roles within an organization and may involve authorized reviewers beyond the primary system owner.

This may include:

• A Model Owner creating or maintaining the record
• A Reviewer providing internal or external review
• Auditor or Authorized Officer involvement
• Independent internal audit
• Third-party review
• Formal attestation processes

This model is common for:

• Growing teams
• Internal governance programs
• Organizations preparing for external scrutiny
• Regulated environments
• Public-facing or high-impact systems
• Enterprise or compliance-driven deployments

Structured Governance introduces separation of duties while preserving organizational ownership and control of the system and its records.

CoreID does not differentiate between internal and external reviewers in terms of system permissions. All authorized reviewers operate within the same workflow and logging structure.

Structured Governance strengthens confidence while maintaining clear accountability within the governing organization.

Choosing a Governance Structure

CoreID does not enforce a governance structure or determine whether a model is "sufficient."

Organizations remain responsible for selecting the governance structure appropriate to their team size, system risk profile, and regulatory obligations.

Governance structures may evolve over time. All governance history remains anchored to the same CoreID, preserving continuity and accountability across changes.

Lifecycle Stages

The CoreID governance lifecycle encompasses 10 conceptual stages. Within the Enterprise Portal, information for these stages is captured through a structured registration form with 7 tabs (Identity, Deployment, Governance, Lineage, Obligations & Evidence, Attestation & Audit, and Summary). Each tab maps to one or more lifecycle stages.

1. Create AI Identity

Each intelligent system is assigned a CoreID.

This establishes the system's persistent identity and serves as the anchor for all future governance, lineage, and compliance records.

Once created, a CoreID remains associated with the system for its entire lifecycle.

2. Capture Model Metadata

Foundational information about the system is recorded, including:

• system or model name
• version identifier
• description and intended function
• licensing or ownership context

This metadata provides the baseline definition of the system.

3. Capture Deployment Metadata

Deployment-specific context is documented, such as:

• industry or sector of use
• intended use cases
• jurisdictions of operation
• governance exposure
• data sensitivity considerations
• operational environment

Deployment metadata provides the contextual grounding required for governance and compliance assessment.

4. Lineage & Relationship Mapping

Relationships between systems are recorded, including:

• parent and derived models
• version history
• redeployments and adaptations

Lineage tracking preserves accountability across system evolution and prevents loss of historical context.

5. Regulatory Alignment

Based on disclosed attributes such as industry, jurisdiction, and intended use, CoreID identifies relevant governance and regulatory frameworks.

This stage supports awareness of potential obligations but does not interpret laws or determine compliance outcomes.

6. Add Internal Governance Metadata

Organizations record private governance information, including:

• internal oversight notes
• operational logs
• monitoring data
• incidents or exceptions
• internal controls and reviews

All information captured at this stage is private and never publicly visible.

7. Generate Compliance Profile

When compliance is required, CoreID structures existing governance information into a compliance profile structured for review.

This profile reflects:

• obligations mapped from selected frameworks
• declared risk tier
• documentation state for selected frameworks

No duplication of records is required.

8. Compliance Record Integrity

Compliance profiles are preserved as timestamped, versioned records tied to the system's lifecycle state at that point in time.

This supports auditability and historical verification.

9. Control Visibility (Public / Private)

Organizations explicitly decide whether any information may be disclosed externally.

Visibility controls determine:

• which fields are visible
• what appears in the Public CoreID Registry
• when disclosure is enabled or revoked

Disclosure is always intentional and controlled.

10. Ongoing Integrity & Attestations

As systems evolve, governance and compliance records are updated to reflect:

• new versions
• deployment changes
• oversight activities
• attestations and reviews

All updates remain anchored to the same CoreID, preserving lifecycle continuity.

Lifecycle Integrity

At every stage, CoreID ensures:

• Persistence of identity
• Preservation of historical records
• Separation of private governance and public disclosure
• Continuity across system evolution
• Continuity across ownership transfers and corporate restructuring

The lifecycle is designed to support long-term governance without requiring system re-registration or record fragmentation.

Roles & Access

Introduction

CoreID uses role-based access to ensure that governance, compliance, and oversight responsibilities are clearly separated across an organization.

Each role determines what a user can view, create, submit, review, approve, or audit.

This role model is designed to support accountability, independence of review, and protection of sensitive information throughout the system lifecycle.

Roles operate within a governance model. Governance models define how responsibility and review are structured; roles define who performs those actions.

Role-Based Access Model

CoreID roles are structured around separation of duties:

• operational model management
• formal organizational accountability
• independent review
• independent audit
• read-only visibility

All access is scoped to the organization and governed by organizational permissions.

Core Organizational Roles

Account Owner

Owns the account for their organization - responsible for account security, access control, and recovery. Account Owners manage who can act in CoreID, not how governance decisions are made.

The Account Owner can:

• Full system access
• Change any configuration
• View, create, update, and archive records (records are archived rather than deleted in normal platform use, and the platform provides no way to edit or delete audit records)
• Invite and remove any user
• Assign and remove any role
• Override organization settings
• Emergency access / recovery authority

Can Assign:

All roles (Account Owner, Authorized Officer, Finance, Team Admin, Auditor, Model Owner, Reviewer, Observer)

At least one Account Owner must exist in every organization at all times.

Team Admin

The Team Admin manages the organization's CoreID environment and operational access control.

The Team Admin typically can:

• manage organization settings
• invite users and assign operational roles (Model Owner, Reviewer, Observer)
• manage permissions and role changes for operational roles
• oversee access governance

The Team Admin cannot:

• assign Account Owner, Auditor, Authorized Officer, or Finance roles
• modify other Team Admins

The Team Admin does not create or manage model records unless separately assigned an operational role. Contact an Account Owner to assign elevated roles.

Finance

Billing Only

Billing visibility and payment execution only. Complete separation from governance. Subscription plan, cancellation, overage, and seat decisions rest with the Account Owner.

The Finance role can:

• View billing & invoices
• View subscription status and plan details
• Download invoices and billing reports

This role has no access to governance, model records, or operational functions. Complete separation of billing from platform operations.

Model Owner

The Model Owner is responsible for managing models and the model lifecycle within CoreID.

The Model Owner typically can:

• create and update model records
• manage model metadata such as name, description, and version information
• manage lifecycle states
• maintain supporting operational information required for governance
• initiate submissions for review

The Model Owner is the primary operational role for model record creation, maintenance, and submission.

Authorized Officer

The Authorized Officer is the formal accountability role for escalated approvals.

The Authorized Officer typically can:

• approve records when escalation is required
• confirm organizational accountability for declared metadata
• sign off on governance or compliance records where organizational authority is required
• approve transfers and other actions requiring formal authority

The Authorized Officer is not involved in routine review and only engages where formal accountability or escalation is required.

Reviewer

The Reviewer is responsible for independent review of submitted records for governance and compliance purposes.

The Reviewer typically can:

• view submitted records assigned for review
• request changes or clarification
• record review outcomes and decisions
• access evidence required to support review decisions

Reviewers may be internal or external to the organization, depending on governance model.

The Reviewer provides primary review sign-off unless escalation to the Authorized Officer is required.

Auditor

The Auditor is responsible for independent audit oversight and audit-grade verification.

The Auditor typically can:

• access audit-related records and supporting evidence
• record audit outcomes and findings
• verify the integrity of governance and compliance records across time
• escalate material risks to the Authorized Officer

Auditor access is independent of operational and review workflows. This role can only be assigned by an Account Owner to maintain audit independence.

Observer

The Observer is a read-only role intended for visibility without operational capability.

The Observer typically can:

• view high-level model and compliance information
• view dashboards and summaries as permitted

The Observer cannot:

• create or edit model records
• submit records for review
• complete attestations
• change permissions or enable disclosure

This role supports executive visibility and internal transparency without granting operational authority.

Public Access

Public users do not authenticate into the Enterprise Portal.

Public access is limited to the Public CoreID Registry and provides read-only visibility of non-sensitive metadata only where disclosure is explicitly enabled.

Public visibility of metadata does not constitute regulatory certification.

Public users cannot access:

• internal governance records
• compliance documentation
• review notes
• audit evidence
• organizational dashboards

Access Integrity & Accountability

CoreID enforces access boundaries so that:

• operational actions are performed by Model Owners
• independent review is performed by Reviewers
• formal accountability actions are handled by Authorized Officers
• audit oversight remains independent
• read-only roles remain non-operational
• public visibility remains disclosure-controlled

Role assignment, segregation of duties, and access reviews remain the responsibility of the organization.

Data Visibility & Disclosure Rules

Introduction

CoreID is built on a privacy-first visibility model. All information captured within the system is private by default, and no data is publicly visible unless an organization explicitly enables disclosure.

This section explains how data visibility is handled, what information is never public, what information may be disclosed, and how disclosure is controlled across the Enterprise Portal and the Public CoreID Registry.

Privacy by Default

All CoreID records are private by default.

When a model, system, or record is created, no information is visible outside the organization unless and until disclosure is explicitly enabled by an authorized role.

CoreID does not assume public visibility at any stage of the governance or compliance lifecycle.

Data That Is Never Public

The following categories of data are never publicly visible, regardless of disclosure settings:

• model weights, parameters, or architectures
• training, validation, or inference datasets
• evaluation, testing, bias, or performance reports
• internal risk logs and incident records
• internal governance notes and oversight documentation
• operational monitoring data and metrics
• internal audit materials and evidence
• private identifiers, internal references, or system credentials

This data remains accessible only to authorized organizational users within the Enterprise Portal.

Potentially Disclosable Data

Certain high-level metadata may be disclosed only when explicitly enabled by the organization.

Potentially disclosable fields include:

• CoreID reference identifier
• model or system name
• system version
• declared risk tier
• jurisdictions of operation
• organization name
• system status (e.g. Active)
• lifecycle status
• date issued

Disclosure of these fields is:

• Intentional
• Field-specific
• Auditable
• Reversible

No additional information is disclosed implicitly or by default.

Disclosure of potentially disclosable data does not imply regulatory approval, certification, or compliance status.

Disclosure Controls

Disclosure is managed through explicit controls within the Enterprise Portal.

Authorized users determine:

• whether a system is visible externally
• which specific fields are disclosed
• when disclosure is enabled or disabled

Changes to disclosure settings are recorded as part of the system's governance history.

Disclosure does not expose internal governance records, compliance evidence, or operational data.

Public CoreID Registry Visibility

The Public CoreID Registry displays only non-sensitive metadata that has been explicitly approved for disclosure.

The registry is:

• Read-only
• Non-authenticated
• Limited in scope

It exists to support external verification of declared information, not to provide access to governance or compliance records.

If disclosure is disabled, the corresponding CoreID does not appear in the public registry.

The Public CoreID Registry reflects declared information at a point in time and should not be interpreted as a compliance determination.

Internal Visibility

Internal visibility within the Enterprise Portal is governed by:

• organizational roles
• role-based permissions
• internal access policies

Internal users may view private governance and compliance records only if their role permits access.

Public disclosure settings do not affect internal access rights.

Revocation and Change of Disclosure

Disclosure is not permanent.

Organizations may:

• revoke public visibility at any time
• change which fields are disclosed
• update disclosed information as systems evolve

Revocation removes public visibility from the registry but does not alter internal governance records.

Visibility Principles

CoreID's visibility model is guided by the following principles:

• privacy by default
• disclosure by choice
• minimum necessary exposure
• separation of governance and verification
• organizational control at all times

These principles ensure transparency where appropriate without compromising security, confidentiality, or governance integrity.

Versioning & Lineage

Introduction

CoreID is designed to preserve continuity as intelligent systems evolve over time.

Rather than treating each update, retraining, or redeployment as a separate entity, CoreID maintains a stable identity while recording version changes and lineage relationships.

This section explains how CoreID handles versioning and lineage to support traceability, accountability, and long-term governance.

Versioning

Versioning in CoreID represents changes to a system over time while maintaining a single persistent identity.

Versioning records describe system evolution but do not redefine system identity.

Each CoreID may be associated with multiple versions that reflect:

• model updates or retraining
• changes to architecture or configuration
• updates to dependencies or inputs
• redeployments in different environments

Versions are recorded as part of the system's lifecycle and remain linked to the same CoreID identity anchor.

Versioning allows organizations to:

• document evolution without re-registering systems
• preserve historical context
• distinguish between current and prior system states
• support review, audit, and attestation activities over time

Version Records

Each version record captures information relevant to that specific system state, such as:

• version identifier
• summary of changes
• associated deployment context
• governance and compliance status at that point in time

Version records do not overwrite prior information. Historical versions remain accessible internally for traceability and review.

Lineage

Lineage describes the relationships between systems and versions over time.

CoreID records lineage relationships such as:

• parent and derived systems
• forked or adapted models
• systems created from shared foundations
• reassignment or transfer events

Lineage ensures that accountability is preserved even when systems are reused, adapted, or extended beyond their original context.

Identity Continuity

Regardless of how a system evolves, the CoreID identity remains constant.

This continuity ensures that:

• governance records remain connected
• compliance history is preserved
• audit trails remain intact
• accountability does not fragment across versions

Lineage provides context for change, while CoreID preserves identity.

Governance and Lineage

Lineage information supports governance by:

• clarifying system inheritance
• identifying shared risk factors
• supporting impact assessment across related systems
• enabling informed review and audit decisions

Lineage does not automatically propagate risk classifications or obligations.

Lineage records are maintained internally and are not publicly disclosed.

Public Visibility of Versioning and Lineage

Versioning and lineage details are not publicly visible.

Public disclosure is limited to high-level metadata such as:

• CoreID reference
• current system name
• current version identifier
• declared risk tier
• jurisdiction and status

Detailed version history and lineage relationships remain private within the Enterprise Portal.

Versioning Principles

CoreID's versioning and lineage model is guided by the following principles:

• persistence of identity
• preservation of historical context
• non-destructive recordkeeping
• internal traceability
• separation of governance and disclosure

These principles ensure that system evolution does not compromise governance integrity.

Public CoreID Registry vs Enterprise Portal

Introduction

CoreID is designed with a clear separation between private governance operations and public verification.

This separation is implemented through two distinct components:

• the Enterprise Portal, and
• the Public CoreID Registry.

Each serves a different purpose, operates under different access rules, and exposes different information.

Enterprise Portal

The Enterprise Portal is the private, authenticated environment used by organizations to manage their CoreID records.

It is where all governance, operational, and compliance-related activity occurs.

Through the Enterprise Portal, authorized users can:

• create and manage model and system records
• maintain governance and compliance documentation
• manage versioning and lineage
• conduct reviews, attestations, and audits
• control disclosure and public visibility
• manage organizational roles and access

All sensitive data, governance records, operational context, and compliance evidence are managed exclusively within the Enterprise Portal.

The Enterprise Portal is never publicly accessible.

Public CoreID Registry

The Public CoreID Registry is a read-only, public-facing interface.

It displays only non-sensitive metadata that has been explicitly approved for disclosure by the owning organization.

The registry enables external parties to:

• verify the existence of a CoreID
• confirm declared attributes such as organization, risk tier, jurisdiction, and status
• reference a system using a stable identifier

The Public CoreID Registry does not provide access to:

• governance documentation
• compliance records or evidence
• operational or technical details
• version history or lineage
• internal review or audit information

The registry supports verification, not governance.

Relationship Between the Two

The Enterprise Portal and the Public CoreID Registry are connected, but not interchangeable.

• Governance decisions are made in the Enterprise Portal
• Disclosure settings are configured in the Enterprise Portal
• Public visibility is an output of governance
• The registry reflects only what has been approved for disclosure

The registry does not drive governance activity and cannot modify or influence internal records.

Disclosure Control Boundary

Disclosure is always initiated and controlled from within the Enterprise Portal.

If disclosure is enabled:

• approved metadata appears in the Public CoreID Registry

If disclosure is disabled:

• the CoreID is removed from public view

Changes to disclosure do not affect internal governance records or historical data.

Access Summary

Design Principle

The separation between the Enterprise Portal and the Public CoreID Registry ensures that:

• sensitive information remains protected
• governance remains private and controlled
• transparency is deliberate and limited
• public verification does not imply certification

This boundary is fundamental to CoreID's architecture and trust model.

Compliance Support & Boundaries

Introduction

CoreID is designed to support organizations in managing governance and compliance obligations for intelligent systems.

It provides structured records, traceability, and controlled disclosure to assist with regulatory readiness and oversight.

CoreID does not act as a regulator, certifying authority, or legal advisor. This section clarifies the scope of CoreID's compliance support and the boundaries of its responsibility.

Compliance Support

CoreID supports compliance by providing infrastructure that enables organizations to organize, maintain, and present governance information in a structured and consistent way.

Compliance support includes:

• structuring governance and compliance records under a persistent identity
• mapping disclosed attributes to relevant regulatory frameworks

CoreID may provide automated recommendations or mappings based on user-provided information, jurisdictional inputs, or internal logic. These recommendations are informational support tools only and do not constitute legal advice, regulatory determinations, or compliance certification. Organizations remain solely responsible for validating the applicability of any framework, obligation, or risk classification.

• preserving structured documentation and historical records
• supporting attestations, reviews, and audit workflows
• enabling traceability across system versions and lifecycle stages
• providing controlled public verification where disclosure is enabled

CoreID helps organizations prepare for compliance activities without requiring duplication of records or redesign of internal processes.

Supported Frameworks

CoreID provides structured compliance readiness support across global AI governance frameworks. Framework-specific document types, structured fields, and compliance sections are activated when frameworks are selected during model registration. The EU AI Act serves as the primary reference architecture.

Regulatory

• EU AI Act (primary architecture, high-risk compliance readiness)
• Korea AI Basic Act (high-impact AI requirements)

Standards

• ISO/IEC 42001:2023 (AI Management System)
• ISO/IEC 23894:2023 (Guidance on AI Risk Management)
• IEEE 7000-2021

Frameworks

• NIST AI Risk Management Framework
• OECD AI Principles
• UNESCO Recommendation on the Ethics of AI (2021)
• Singapore Model AI Governance Framework

Regional

• UAE Charter for the Development and Use of AI
• Dubai AI Ethics Principles & Guidelines
• Guidance for AI Adoption
• SDAIA AI Ethics Principles (2025)

Organizations select applicable frameworks during registration. CoreID maps relevant documentation requirements, compliance fields, and governance controls based on the selected frameworks and deployment context.

Compliance Is Supported, Not Certified

CoreID does not certify, approve, or validate AI systems.

Use of CoreID does not imply:

• regulatory approval
• legal compliance
• conformity certification
• endorsement by authorities

Compliance outcomes remain the responsibility of the organization and relevant regulators.

CoreID provides tooling and structure to support compliance efforts but does not determine compliance status.

No Regulatory or Legal Authority

CoreID does not:

• interpret laws or regulations
• provide legal advice
• replace regulatory bodies
• make compliance determinations
• enforce regulatory outcomes

Any references to regulatory frameworks within CoreID are informational and structural only.

Organizational Responsibility

Organizations using CoreID are solely responsible for:

• understanding applicable laws and regulations
• determining which obligations apply to their systems
• ensuring accuracy of declared metadata
• completing required assessments and attestations
• maintaining compliance over time

CoreID supports these responsibilities but does not assume them.

Use in Audits and Reviews

CoreID may be used to support audits and reviews by:

• preserving historical governance and compliance records
• maintaining traceable version and lineage history
• enabling controlled access to evidence and documentation

Audit outcomes and regulatory decisions are made independently of CoreID.

Boundary Summary

CoreID provides:

• governance and compliance infrastructure
• documentation, traceability, and disclosure support
• verification of declared information

CoreID does not:

• certify systems
• interpret regulations
• provide legal advice
• act as a regulator

These boundaries ensure that CoreID remains a neutral, infrastructure-level system.