coulomb/info-tech-canon
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
info-tech-canon/seeds/InfoTechCanonOrganizationModel_RC1_seed.md

39 KiB
Executable File
Raw Permalink Blame History

InfoTechCanon Organization Model

Short Name: ITC-ORG
Document Status: Seed Standard Release Candidate 1
Version: RC1-seed
Date: 2026-05-22
Repository Context: info-tech-canon
Document Type: InfoTechCanon Domain Standard
Intended Audience: Organization designers, enterprise architects, platform builders, governance designers, product owners, service owners, HR/people-ops modelers, project/program managers, security architects, knowledge-system builders, standards authors, and agentic tooling.

1. Purpose

The InfoTechCanon Organization Model defines a canonical seed model for representing organizations, organizational units, actors, memberships, roles, authority, responsibility, accountability, teams, operating structures, collaboration structures, and organizational viability patterns.

It exists to support the broader InfoTechCanon goal of building interoperable information-processing systems without forcing rigid organizational assumptions into every subsystem.

This standard provides:

  • a canonical vocabulary for organizational structures,
  • a distinction between persons, actors, roles, positions, groups, teams, units, and organizations,
  • a responsibility and authority model,
  • a membership and assignment model,
  • support for formal, informal, matrix, product, project, and networked organizations,
  • interfaces to governance, landscape, task, tagging, access-control, service, and security models,
  • mapping hooks to external standards and frameworks,
  • seed patterns for practical organization modeling,
  • profile hooks for implementation contexts,
  • and retrieval-friendly structure for humans, agents, and markdown-based infospaces.

2. Position in InfoTechCanon

The Organization Model is a domain standard within InfoTechCanon.

It should become the canonical owner of organizational concepts that are currently only referenced by the Landscape Model.

InfoTechCanon
├── InfoTechCanonCore
├── InfoTechCanonOrganizationModel     <-- this standard
├── InfoTechCanonGovernanceModel       <-- close dependency / sibling standard
├── InfoTechCanonLandscapeModel        <-- imports organization references
├── InfoTechCanonTaskModel             <-- imports actors, assignments, accountability
├── InfoTechCanonAccessControlModel    <-- imports actor, role, principal distinctions
├── InfoTechCanonTaggingStandard
├── InfoTechCanonPatternLanguage
└── Application Profiles

2.1 Boundary with Governance

The Organization Model owns:

Actor
Person
Organization
OrganizationalUnit
Team
Group
Role
Position
Membership
Assignment
Responsibility
Authority
Accountability
ReportingLine
CoordinationMechanism
OperatingUnit

The Governance Model should own:

Policy
Rule
Control
Decision
Risk
Obligation
Exception
Evidence
ComplianceRequirement
Audit
GovernanceProcess

The boundary rule is:

Organization defines who can act, where they belong, and what authority or responsibility they carry.

Governance defines which rules, decisions, controls, obligations, and evidence structures constrain or direct action.

3. Research Basis and External Alignment

This seed standard draws on several bodies of prior work.

3.1 W3C Organization Ontology

The W3C Organization Ontology provides a reusable ontology for organizational structures, including organizations, organizational units, posts, roles, membership, reporting, and classification. It is a strong source for linked-data-friendly modeling of organizational structure.

Relevant external concepts:

Organization
OrganizationalUnit
FormalOrganization
OrganizationalCollaboration
Post
Role
Membership
reportsTo
memberOf

3.2 Enterprise Modeling Standards

Enterprise modeling standards such as ISO 19439 and ISO 19440 emphasize enterprise constructs, processes, resources, and human tasks. They support the idea that organizational models must interoperate with process, resource, and capability models rather than exist only as HR charts.

3.3 Business Motivation and Governance Models

The OMG Business Motivation Model treats organization units, assets, business processes, and business rules as important references, while making clear that detailed organization structure is outside its own scope. This supports the InfoTechCanon separation between organization modeling and governance/motivation modeling.

3.4 Viable System Model

Stafford Beer’s Viable System Model provides a cybernetic view of organization: operational units, coordination, control, intelligence/adaptation, and policy/identity functions recur at multiple levels. This is useful as a pattern layer rather than a mandatory structure.

3.5 Project and Matrix Organization Literature

Project management practice distinguishes functional, matrix, projectized, and composite structures. This is important because real organizations rarely follow a single hierarchy. The Organization Model must support multiple simultaneous authority, reporting, allocation, and accountability relations.

3.6 IT Service Management and Governance Practice

ITIL, COBIT, COSO, ISO 9001, and similar frameworks emphasize roles, responsibilities, authorities, controls, accountability, governance structures, and process ownership. The Organization Model should provide the structural substrate for these models while not owning their full governance semantics.

3.7 Human Capital Reporting

ISO 30414 and related human-capital reporting practice highlight workforce composition, skills, productivity, leadership, succession, culture, and workforce metrics. These are not all core organizational structure concepts, but they provide important future mapping and assimilation targets.

4. Seed Standard Design Stance

This standard is a seed standard, not a final complete theory of organizations.

A seed standard shall:

  1. define enough canonical concepts to support practical system integration,
  2. avoid pretending that organization theory is complete or simple,
  3. preserve orthogonality with governance, access control, task management, and landscape modeling,
  4. support formal and informal structures,
  5. support recursive and matrix structures,
  6. support human and non-human actors,
  7. expose mapping hooks to existing standards,
  8. enable practical subsystem interface declarations,
  9. and remain suitable for markdown-first knowledge spaces and agent retrieval.

5. Scope

5.1 In Scope

This standard covers canonical representation of:

  • organizations,
  • organizational units,
  • teams,
  • groups,
  • persons,
  • actors,
  • agents,
  • roles,
  • positions,
  • posts,
  • membership,
  • assignment,
  • reporting lines,
  • responsibility,
  • accountability,
  • authority,
  • delegation,
  • stewardship,
  • ownership,
  • operating units,
  • collaboration structures,
  • project/product/value-stream structures,
  • matrix organization relationships,
  • organizational capabilities,
  • coordination mechanisms,
  • viability functions,
  • and organization-facing interface concepts for other InfoTechCanon standards.

5.2 Out of Scope

This standard does not fully define:

  • legal corporate structures in jurisdiction-specific detail,
  • employment law,
  • compensation and payroll,
  • full HR management,
  • performance management,
  • psychological safety,
  • labor relations,
  • social responsibility,
  • diversity reporting,
  • full governance and compliance models,
  • full access-control semantics,
  • full project management methodology,
  • or all organizational design theory.

Those may be mapped, assimilated, profiled, or handled by adjacent standards.

6. Normative Language

The following terms are used normatively:

  • SHALL indicates a mandatory rule for conformance.
  • SHOULD indicates a recommended practice.
  • MAY indicates an optional capability.
  • MUST NOT indicates a prohibited practice.
  • SEED marks a concept defined provisionally here but open to later refinement.
  • EXTRACT marks a concept that may later move to a more specialized standard.

7. Core Principles

7.1 Person, Actor, Role, and Position Are Distinct

The model SHALL distinguish:

Person
Actor
Agent
Role
Position
Assignment
Membership

A person is not a role.
A role is not a person.
A position is not a role.
An assignment is not permanent identity.
A membership is not necessarily authority.

7.2 Organization Is More Than Hierarchy

The model SHALL support hierarchical, matrix, networked, projectized, product-oriented, functional, and informal organizational structures.

7.3 Authority and Responsibility Are First-Class

Authority, responsibility, and accountability SHALL be modeled explicitly when relevant.

They MUST NOT be hidden as free-text comments on people or teams.

7.4 Multiple Structures May Coexist

An actor MAY participate in multiple organizational structures at the same time.

Example:

A person may belong to a functional department,
work in a product team,
serve as incident commander,
hold a security role,
and be accountable for a service.

7.5 Organization Models Must Support Time

Memberships, assignments, reporting lines, responsibilities, and authorities SHOULD carry validity intervals.

7.6 Organization Models Must Support Source and Confidence

When organizational data is imported from HR systems, identity systems, service catalogs, CMDBs, Git repositories, project tools, or manual documents, its source and confidence SHOULD be recorded.

7.7 Governance Uses Organization but Does Not Replace It

Governance models need organizational structures, but policies and controls are not the same thing as organizational roles or responsibilities.

7.8 Access Control Uses Roles but Does Not Own All Roles

Access-control roles, organizational roles, job roles, governance roles, and task roles may overlap but are not identical.

The Organization Model owns the generic role concept. The Access Control Model should own permission-bearing access roles and entitlements.

8. Canonical Seed Metadata

Every organization artifact SHOULD support structured metadata.

Recommended front matter:

---
id: itc-org:Team
type: concept
standard: InfoTechCanonOrganizationModel
standard_version: RC1-seed
status: candidate
canonical_owner: InfoTechCanonOrganizationModel
preferred_label: Team
related:
  - itc-org:Organization
  - itc-org:Role
  - itc-org:Membership
  - itc-org:Responsibility
mappings:
  - itc-map:team-to-w3c-org-organizational-unit
---

Recommended artifact statuses:

idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired

Recommended concept statuses:

proposed
experimental
candidate
canonical
deprecated
retired

9. Root Organization Taxonomy

OrganizationEntity
├── ActorEntity
│   ├── Person
│   ├── Agent
│   ├── HumanActor
│   ├── NonHumanActor
│   └── CollectiveActor
├── StructureEntity
│   ├── Organization
│   ├── OrganizationalUnit
│   ├── Team
│   ├── Group
│   ├── Committee
│   ├── Community
│   ├── Network
│   └── Collaboration
├── RoleEntity
│   ├── Role
│   ├── OrganizationalRole
│   ├── JobRole
│   ├── FunctionalRole
│   ├── GovernanceRole
│   ├── ServiceRole
│   ├── ProjectRole
│   └── AccessRoleReference
├── PositionEntity
│   ├── Position
│   ├── Post
│   └── Seat
├── RelationshipEntity
│   ├── Membership
│   ├── Assignment
│   ├── ReportingLine
│   ├── Delegation
│   ├── Responsibility
│   ├── Accountability
│   ├── Authority
│   └── Consultation
├── CapabilityEntity
│   ├── OrganizationalCapability
│   ├── Skill
│   ├── Competence
│   ├── Capacity
│   └── Availability
└── ViabilityEntity
    ├── OperatingUnit
    ├── CoordinationFunction
    ├── ControlFunction
    ├── IntelligenceFunction
    ├── PolicyFunction
    └── RecursiveOrganizationUnit

10. Core Concepts

10.1 OrganizationEntity

An OrganizationEntity is any identifiable organizational concept relevant to people, actors, structures, roles, authority, responsibility, coordination, or organizational capability.

Recommended attributes:

id:
entity_type:
canonical_name:
display_name:
lifecycle_state:
source_system:
created_at:
updated_at:

Optional attributes:

owner:
steward:
classification:
source_confidence:
valid_from:
valid_to:
tags:
external_references:

10.2 Actor

An Actor is an entity capable of participating in action, responsibility, communication, decision, work, or authority relationships.

Subtypes:

HumanActor
NonHumanActor
CollectiveActor

An actor may be:

Person
Team
Organization
ServiceAccount
AI Agent
System
Committee
ExternalPartner

Canonical Rule

Actor is a functional modeling concept.

It MUST NOT be treated as synonymous with Person.

10.3 Person

A Person is a human individual represented in the organization model.

A person may have:

memberships
assignments
roles
positions
responsibilities
authorities
skills
availability
identity references

The model SHOULD avoid storing unnecessary sensitive personal data unless a concrete profile requires it.

10.4 Agent

An Agent is a non-human actor that can act in a system context.

Examples:

software agent
AI agent
automation bot
service account
operational daemon
workflow executor

Agent concepts are important because InfoTechCanon must support human-agent organizations.

10.5 CollectiveActor

A CollectiveActor is a group-like actor that can be assigned responsibility or authority.

Examples:

team
committee
organization
external supplier
community
working group

10.6 Organization

An Organization is a structured collective actor with identity, purpose, boundaries, and some capacity for coordinated action.

An organization may be:

company
non-profit
public body
open-source foundation
department-like autonomous unit
project organization
temporary venture
network organization

Recommended attributes:

legal_name:
short_name:
organization_type:
purpose:
boundary_description:
jurisdiction:
lifecycle_state:

10.7 OrganizationalUnit

An OrganizationalUnit is a subdivision of an organization.

Examples:

division
department
business unit
chapter
tribe
cost center
regional unit
product area

Organizational units usually imply structural membership and some form of management or accountability.

10.8 Team

A Team is a collective actor organized around shared work, responsibility, service, product, capability, or mission.

A team may or may not be a formal organizational unit.

Canonical distinction:

OrganizationalUnit
  structural subdivision of an organization

Team
  working collective with shared responsibility

Group
  collection of actors, often for classification, communication, access, or convenience

10.9 Group

A Group is a collection of actors.

Groups MAY be used for:

communication
access control
classification
mailing lists
work coordination
interest communities

A group does not automatically imply shared responsibility, shared management, or organizational authority.

10.10 Role

A Role is an expected pattern of responsibility, authority, behavior, participation, or capability that can be assigned to an actor.

Subtypes:

OrganizationalRole
JobRole
FunctionalRole
GovernanceRole
ServiceRole
ProjectRole
TaskRole
AccessRoleReference

Canonical Rule

A role describes a type of participation or responsibility.

A role SHALL NOT be used as a substitute for a person, position, permission set, or team unless a profile explicitly declares that simplification.

10.11 Position

A Position is an organizationally defined slot that may be occupied by a person or actor.

Examples:

Chief Technology Officer
Head of Product
Team Lead Backend
Security Officer
Data Protection Officer

A position may imply roles, responsibilities, authority, and reporting lines.

10.12 Post

A Post is a position-like place in an organization that exists independently of the current holder.

This term is useful when mapping to W3C ORG.

10.13 Membership

A Membership is a relationship that connects an actor to a group, team, organizational unit, or organization.

Recommended attributes:

member:
organization_entity:
membership_type:
valid_from:
valid_to:
source_system:
confidence:

Membership does not necessarily imply authority.

10.14 Assignment

An Assignment is a relationship that assigns an actor to a role, position, responsibility, task, service, project, or scope.

Examples:

Person assigned_to Role
Team assigned_to Service
Person assigned_to Position
Agent assigned_to AutomationTask
Team assigned_to IncidentResponseDuty

Assignment should usually be time-bounded.

10.15 Responsibility

A Responsibility is an obligation or expected duty assigned to an actor for a scope.

Examples:

responsible for operating a service
responsible for reviewing pull requests
responsible for maintaining a dataset
responsible for incident response

Responsibility does not necessarily imply final decision authority.

10.16 Accountability

Accountability is the condition of being answerable for the outcome of a responsibility, decision, service, control, or obligation.

Canonical rule:

A scope SHOULD have clear accountability when failure has meaningful consequences.

Profiles MAY require exactly one accountable actor per scope, but the core model does not mandate this universally because real organizations may have shared or layered accountability.

10.17 Authority

Authority is the recognized right to make decisions, allocate resources, approve changes, enforce rules, or direct action within a scope.

Subtypes:

DecisionAuthority
ApprovalAuthority
BudgetAuthority
OperationalAuthority
TechnicalAuthority
PolicyAuthority
EmergencyAuthority

Authority SHOULD be scoped.

10.18 Delegation

Delegation is a relationship in which an actor transfers or grants responsibility or authority to another actor within defined limits.

Recommended attributes:

delegator:
delegate:
delegated_scope:
delegated_authority:
valid_from:
valid_to:
revocable:
constraints:

10.19 ReportingLine

A ReportingLine is a relationship indicating managerial, functional, project, product, operational, or governance reporting.

Subtypes:

managerial_reports_to
functional_reports_to
project_reports_to
product_reports_to
governance_reports_to
operational_reports_to
escalates_to

Canonical rule:

ReportingLine MUST specify its type when more than one reporting logic exists.

10.20 Ownership

Ownership is a strong responsibility relationship connecting an actor to an entity whose lifecycle, quality, continuity, or outcome the actor is expected to care for.

Ownership is often used by landscape, service, data, product, and governance models.

Subtypes:

ServiceOwnership
ProductOwnership
DataOwnership
TechnicalOwnership
ProcessOwnership
ControlOwnership
RiskOwnership

Ownership SHOULD be mapped to responsibility and accountability but is not identical to legal ownership.

10.21 Stewardship

Stewardship is a responsibility for care, quality, maintenance, interpretation, or proper use of an entity.

Stewardship is often less absolute than ownership.

Examples:

data steward
standard steward
service catalog steward
architecture steward
community steward

10.22 OrganizationalCapability

An OrganizationalCapability is the capacity of an organization or organizational part to reliably perform a class of work or produce a kind of outcome.

Examples:

software delivery
incident response
customer support
security monitoring
product discovery
regulatory reporting

This concept should align with strategy and landscape capability modeling.

10.23 Skill and Competence

A Skill is an ability that can be possessed by a person or agent.

A Competence is a demonstrated or recognized ability to perform in a domain or role.

These concepts are seed concepts and may later be refined in a human-capital or capability standard.

10.24 Capacity and Availability

Capacity is the amount of work or responsibility an actor or group can realistically absorb in a time or context.

Availability is the degree to which an actor is accessible for assignment, decision, support, or communication.

These are important for task, project, service, and incident models.

11. Core Relationship Vocabulary

Recommended root relationship types:

member_of
has_member
assigned_to
plays_role
occupies_position
reports_to
delegates_to
responsible_for
accountable_for
has_authority_over
owns
stewards
consulted_by
informed_by
supports
coordinates_with
collaborates_with
escalates_to
represents
external_to
part_of
composes

Relationship records SHOULD support:

id:
relationship_type:
source_actor_or_entity:
target_actor_or_entity:
scope:
valid_from:
valid_to:
source_system:
confidence:
evidence:

12. Organizational Structure Patterns

12.1 Pattern: Person-Role-Assignment Split

Context: Systems often store people, roles, and assignments as one field.

Problem: A person may change roles; a role may be held by many people; a position may exist without a current person; an assignment may be temporary.

Solution: Model Person, Role, Position, Membership, and Assignment separately.

Result: Better history, delegation, access modeling, accountability, and integration with HR, IAM, service ownership, and task systems.

12.2 Pattern: Owner-Steward-Operator

Context: Services, datasets, standards, systems, and controls need clear responsibility.

Problem: “Owner” is often overloaded.

Solution: Distinguish:

Owner
  accountable for lifecycle and outcome.

Steward
  responsible for quality, interpretation, and care.

Operator
  responsible for running or executing operational activity.

Used Concepts:

Ownership
Stewardship
Responsibility
Accountability
Authority
Team
Role

12.3 Pattern: Matrix Without Confusion

Context: A person belongs to a functional department but works in a product or project team.

Problem: One hierarchy cannot represent both skill development and delivery accountability.

Solution: Model multiple relationship types:

functional_reports_to
project_reports_to
product_reports_to
member_of
assigned_to
accountable_for

Result: The model can represent functional, matrix, projectized, and product-aligned structures.

12.4 Pattern: Recursive Viability

Context: Organizations need autonomy and coordination at multiple scales.

Problem: Centralized control does not scale, but uncontrolled autonomy fragments the organization.

Solution: Model operating units as recursively viable units with patterns for:

operation
coordination
control
intelligence
policy

Note: This pattern is inspired by the Viable System Model but does not require every organization to implement VSM terminology directly.

12.5 Pattern: Role is Not Permission

Context: Systems often confuse organizational roles with access-control roles.

Problem: A role such as “Product Owner” is not the same as a permission set in an IAM system.

Solution: Model organizational roles separately from access entitlements.

Access-control standards may map roles to permissions, but should not own generic organizational role semantics.

12.6 Pattern: Temporary Organization

Context: Projects, incident response teams, ventures, and task forces form temporarily.

Problem: Formal org charts cannot represent temporary collaboration structures well.

Solution: Model temporary organizations or collaborations with explicit validity intervals, purpose, members, authority, and dissolution conditions.

12.7 Pattern: Accountability Scope

Context: People ask “who owns this?” but the answer depends on scope.

Problem: Ownership without scope creates confusion.

Solution: Every ownership or accountability relationship SHOULD declare its scope.

Examples:

service lifecycle
runtime operation
budget
security posture
data quality
architectural coherence
customer outcome

13. Organization Profiles

13.1 Profile Format

An Organization Profile SHALL declare:

id:
profile_name:
status:
implements:
  - InfoTechCanonOrganizationModel
target_context:
included_concepts:
required_relationships:
required_metadata:
source_of_truth_rules:
mapping_files:
validation_rules:
examples:
known_deviations:

13.2 Seed Profile: Small SaaS Organization Profile

Purpose:

Provide a minimal organization model for a small SaaS platform or product company.

Included concepts:

Organization
Team
Person
Agent
Role
Membership
Assignment
Responsibility
Accountability
Authority
Ownership
Stewardship
ReportingLine

Required relationships:

Person member_of Team
Team owns Service
Team operates RuntimePlatform
Person plays_role Role
Role responsible_for Scope
Team accountable_for Service
Agent assigned_to AutomationScope

13.3 Seed Profile: Service Ownership Profile

Purpose:

Define the minimum organization structure required to connect teams and people to services in the Landscape Model.

Included concepts:

Team
Person
Role
ServiceOwner
TechnicalOwner
Operator
SupportGroup
Ownership
Responsibility
Escalation

Required relationships:

ApplicationService owned_by Team
TechnicalService operated_by Team
Person plays_role ServiceOwner
ServiceOwner accountable_for Service
SupportGroup supports Service
Incident escalates_to SupportGroup

13.4 Seed Profile: Human-Agent Organization Profile

Purpose:

Support systems where humans and AI/software agents collaborate as actors.

Included concepts:

Person
Agent
Team
Role
Assignment
Authority
Delegation
Responsibility
Supervision
AuditReference

Required relationships:

Agent assigned_to TaskScope
Agent operates_under Authority
Person supervises Agent
Agent emits AuditEvent
Person accountable_for AgentScope

13.5 Seed Profile: Matrix Project Organization Profile

Purpose:

Support organizations where people report functionally while being assigned to projects, products, or programs.

Included concepts:

Person
FunctionalUnit
ProjectTeam
ProductTeam
ProjectRole
FunctionalRole
ReportingLine
Assignment
Capacity
Availability

Required relationships:

Person member_of FunctionalUnit
Person assigned_to ProjectTeam
Person functional_reports_to Manager
Person project_reports_to ProjectLead
ProjectTeam accountable_for Deliverable
FunctionalUnit responsible_for SkillDevelopment

14. Mapping Model for the Organization Standard

Mappings relate InfoTechCanon organization concepts to external standards, frameworks, products, and regulations.

14.1 Mapping Types

Recommended mapping types:

exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference

14.2 Mapping Record

Example:

id: itc-map:org-team-to-w3c-org-organizational-unit
source_concept: itc-org:Team
target_body: W3C Organization Ontology
target_version: "2014 Recommendation"
target_concept: org:OrganizationalUnit
mapping_type: closeMatch
scope:
  - structural or working groups represented as organizational units
not_valid_for:
  - informal chat groups
  - access-control-only groups
rationale: >
  Teams may often be represented as organizational units in linked data,
  but InfoTechCanon distinguishes teams from formal organizational units.
confidence: medium
status: candidate
owner: InfoTechCanonOrganizationModel

14.3 Seed Mapping Targets

The Organization Model SHOULD maintain mappings to:

W3C Organization Ontology
OMG Commons Organizations
ArchiMate organization and actor concepts
OMG Business Motivation Model references
ISO 19439 / ISO 19440 enterprise modeling constructs
ISO 9001 roles, responsibilities, and authorities
ISO 30414 human capital reporting concepts
ISO 26000 stakeholder and social responsibility concepts
ITIL roles and service organization concepts
COBIT organizational structures and governance components
PMBOK organizational structures and responsibility assignment concepts
RACI / RASCI responsibility assignment models
HRIS / IAM / directory service models

15. Assimilation Hooks

The Organization Model SHALL be able to receive new bodies of organizational knowledge through the InfoTechCanon assimilation process.

15.1 Assimilation Triggers

Assimilation may be triggered by:

new organization theory
new HR standard
new governance framework
new ITSM practice
new project-management model
new company operating model
new legal structure
new identity or access model
new collaboration tooling model
new agentic organization pattern

15.2 Organization Assimilation Output

An organization assimilation SHOULD produce:

source summary
extracted organization concepts
concept comparison matrix
gap list
conflict list
mapping file
candidate new concepts
candidate relationship changes
candidate pattern changes
candidate profile changes
open questions

15.3 Recommended First Assimilation Candidates

W3C Organization Ontology
ArchiMate organization-related concepts
PMBOK organizational structures and RACI
ITIL role and practice ownership concepts
COBIT governance components and organizational structures
ISO 9001 roles, responsibilities, and authorities
VSM organizational viability patterns
ISO 30414 human capital reporting

16. Integration with Other InfoTechCanon Standards

16.1 Landscape Model

Landscape imports organization concepts for:

service ownership
support groups
runtime operation
technical stewardship
incident escalation
data ownership
system accountability

16.2 Governance Model

Governance imports organization concepts for:

policy ownership
control ownership
decision authority
risk ownership
audit accountability
exception approval

16.3 Task Model

Task imports organization concepts for:

assignee
requester
responsible actor
accountable actor
reviewer
approver
team ownership
capacity
availability

16.4 Access Control Model

Access Control imports organization concepts for:

person
agent
group
role reference
membership
authority
delegation

But Access Control owns:

permission
entitlement
credential
access policy
authorization decision
privilege

16.5 Tagging Standard

Tagging imports organization concepts for tags such as:

team
owner
stakeholder
business-unit
responsibility-area

17. Canon Interface Card Usage

Subsystems that implement or produce organization knowledge SHOULD publish a Canon Interface Card.

Example:

subsystem: user-engine
implements:
  - InfoTechCanonOrganizationModel
  - HumanAgentOrganizationProfile
produces:
  - Person
  - Agent
  - Group
  - Membership
  - RoleAssignment
consumes:
  - Organization
  - Team
  - Policy
relations:
  - Person member_of Team
  - Person plays_role Role
  - Agent assigned_to AutomationScope
source_of_truth:
  person_identity: user-engine
  group_membership: user-engine
known_deviations:
  - does not model employment contracts
  - does not model compensation

18. Retrieval Requirements

The Organization Model is designed for markdown-based infospaces.

18.1 Required Retrieval Properties

Every major concept SHOULD provide:

  • stable heading,
  • stable identifier,
  • short definition,
  • longer explanation,
  • examples,
  • distinction notes,
  • relationship examples,
  • mapping hooks,
  • profile references,
  • and common mistakes.

18.2 Agent Brief

A mature Organization Model SHOULD include an agent-brief.md file with:

purpose
scope
owned concepts
imported concepts
core distinctions
do / do not rules
relationship patterns
minimal examples
common mistakes
profile list
mapping list

18.3 Indexes

The organization information space SHOULD provide indexes by:

concept
relationship
role type
actor type
profile
pattern
mapping target
status
source system

19. Conformance Levels

19.1 Reference-Conformant

A document or system is reference-conformant if it uses Organization Model terminology consistently but does not implement structured metadata or validation rules.

19.2 Metadata-Conformant

A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types.

19.3 Relationship-Conformant

A system is relationship-conformant if it represents memberships, assignments, responsibilities, accountabilities, authorities, and reporting lines as explicit relationships.

19.4 Temporal-Conformant

A system is temporal-conformant if memberships, assignments, roles, responsibilities, and reporting lines can carry validity intervals.

19.5 Profile-Conformant

A system is profile-conformant if it implements a declared Organization Profile and passes its validation rules.

19.6 Assimilation-Conformant

A system or repository is assimilation-conformant if it can accept external organization concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes.

20. Validation Rules

Initial validation rules:

VAL-ORG-001: Person, Role, Position, Membership, and Assignment SHOULD be modeled as distinct concepts.

VAL-ORG-002: A Role MUST NOT be treated as identical to an access-control permission set unless declared by an Access Control profile.

VAL-ORG-003: A Group MUST NOT imply shared responsibility unless a Responsibility relationship is present.

VAL-ORG-004: Membership MUST NOT imply authority unless an Authority or Assignment relationship is present.

VAL-ORG-005: ReportingLine SHOULD specify its type when more than one reporting logic exists.

VAL-ORG-006: Responsibility SHOULD declare a scope.

VAL-ORG-007: Accountability SHOULD declare a scope and accountable actor.

VAL-ORG-008: Authority SHOULD declare its scope and limits.

VAL-ORG-009: Time-bounded assignments SHOULD include valid_from and valid_to when available.

VAL-ORG-010: Imported external concepts SHOULD be represented through mapping records rather than silently reused.

VAL-ORG-011: Profiles MUST NOT redefine canonical concepts. They may constrain them.

VAL-ORG-012: Human and non-human actors SHOULD be distinguishable in systems that include automation or AI agents.

VAL-ORG-013: Sensitive personal data SHOULD NOT be included unless required by a declared profile and justified purpose.

VAL-ORG-014: Organization references used by other standards SHOULD resolve to Organization Model concepts or declared mappings.

21. Anti-Patterns

21.1 Person Equals Role

Treating a named person as if they were the role itself.

21.2 Group Equals Team

Treating every collection of people as a team with shared responsibility.

21.3 Membership Equals Authority

Assuming membership in a group grants decision power.

21.4 Org Chart as Organization

Treating the formal reporting hierarchy as the complete organization.

21.5 Hidden Matrix

Using only one reporting line while project, product, functional, and operational structures coexist.

21.6 Owner Means Everything

Using “owner” for every kind of responsibility, accountability, stewardship, operation, and approval.

21.7 Access Role Leakage

Letting IAM permission roles define organizational semantics.

21.8 Eternal Assignment

Failing to model time-bound roles, project assignments, temporary teams, or delegated authority.

21.9 Human-Only Organization

Ignoring software agents, AI agents, service accounts, and automation actors in modern organizations.

22. Initial Repository Placement

Recommended repository layout:

info-tech-canon/
  standards/
    organization/
      InfoTechCanonOrganizationModel.md
      agent-brief.md
      concepts/
      relationships/
      patterns/
      profiles/
      mappings/
      assimilation/
      examples/
      validation/

Seed files:

standards/organization/InfoTechCanonOrganizationModel.md
standards/organization/agent-brief.md
standards/organization/concepts/actor.md
standards/organization/concepts/person.md
standards/organization/concepts/role.md
standards/organization/concepts/team.md
standards/organization/concepts/responsibility.md
standards/organization/concepts/authority.md
standards/organization/patterns/person-role-assignment-split.md
standards/organization/patterns/owner-steward-operator.md
standards/organization/patterns/matrix-without-confusion.md
standards/organization/profiles/small-saas-organization-profile.md
standards/organization/profiles/service-ownership-profile.md
standards/organization/profiles/human-agent-organization-profile.md
standards/organization/mappings/w3c-org.yaml
standards/organization/mappings/archimate.yaml
standards/organization/mappings/raci.yaml

23. Roadmap

Phase 1: Seed Stabilization

  • Establish this standard as InfoTechCanonOrganizationModel.
  • Extract organization concepts from the Landscape Model.
  • Add seed concepts, relationship vocabulary, patterns, and profiles.
  • Define validation rules.

Phase 2: Core Alignment

  • Align with InfoTechCanonCore once defined.
  • Move generic mapping, profile, pattern, provenance, and conformance mechanics into Core.
  • Keep only organization-specific applications here.

Phase 3: Governance Boundary

  • Create or align with InfoTechCanonGovernanceModel.
  • Move policies, controls, risks, obligations, evidence, and decision governance to Governance.
  • Keep actor, authority, accountability, and responsibility concepts here.

Phase 4: First Assimilations

Recommended first assimilations:

W3C Organization Ontology
RACI / responsibility assignment models
ArchiMate organization-related concepts
ITIL role concepts
VSM viability functions
COBIT governance components
ISO 9001 clause 5.3 concepts

Phase 5: Tooling Integration

  • Generate concept indexes.
  • Generate agent brief.
  • Create machine-readable YAML/JSON exports.
  • Add validation scripts.
  • Use in user-engine, landscape, task, access-control, and governance-related repositories.

24. Summary

The InfoTechCanon Organization Model is the seed standard for modeling organizational reality across the InfoTechCanon information space.

Its most important commitments are:

Separate person, actor, role, position, membership, assignment,
responsibility, accountability, authority, and ownership.

Model organization as a network of formal and informal structures,
not merely as a hierarchy.

Support matrix, project, product, functional, temporary, and human-agent organizations.

Keep governance, access control, task management, and landscape modeling
orthogonal but interoperable.

Use mappings and assimilation to stay connected to external standards
without surrendering internal semantic autonomy.

This makes the Organization Model a practical structural foundation for interoperable systems, service ownership, task assignment, governance, access control, agent collaboration, and future organizational intelligence.

Reference in New Issue View Git Blame Copy Permalink