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

1751 lines
39 KiB
Markdown
Executable File
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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.
```text
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:
```text
Actor
Person
Organization
OrganizationalUnit
Team
Group
Role
Position
Membership
Assignment
Responsibility
Authority
Accountability
ReportingLine
CoordinationMechanism
OperatingUnit
```
The Governance Model should own:
```text
Policy
Rule
Control
Decision
Risk
Obligation
Exception
Evidence
ComplianceRequirement
Audit
GovernanceProcess
```
The boundary rule is:
```text
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:
```text
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:
```text
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:
```text
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:
```yaml
---
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:
```text
idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired
```
Recommended concept statuses:
```text
proposed
experimental
candidate
canonical
deprecated
retired
```
---
# 9. Root Organization Taxonomy
```text
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:
```yaml
id:
entity_type:
canonical_name:
display_name:
lifecycle_state:
source_system:
created_at:
updated_at:
```
Optional attributes:
```yaml
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:
```text
HumanActor
NonHumanActor
CollectiveActor
```
An actor may be:
```text
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:
```text
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:
```text
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:
```text
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:
```text
company
non-profit
public body
open-source foundation
department-like autonomous unit
project organization
temporary venture
network organization
```
Recommended attributes:
```yaml
legal_name:
short_name:
organization_type:
purpose:
boundary_description:
jurisdiction:
lifecycle_state:
```
---
## 10.7 OrganizationalUnit
An **OrganizationalUnit** is a subdivision of an organization.
Examples:
```text
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:
```text
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:
```text
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:
```text
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:
```text
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:
```yaml
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:
```text
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:
```text
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:
```text
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:
```text
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:
```yaml
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:
```text
managerial_reports_to
functional_reports_to
project_reports_to
product_reports_to
governance_reports_to
operational_reports_to
escalates_to
```
Canonical rule:
```text
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:
```text
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:
```text
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:
```text
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:
```text
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:
```yaml
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:
```text
Owner
accountable for lifecycle and outcome.
Steward
responsible for quality, interpretation, and care.
Operator
responsible for running or executing operational activity.
```
**Used Concepts:**
```text
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:
```text
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:
```text
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:
```text
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:
```yaml
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:
```text
Provide a minimal organization model for a small SaaS platform or product company.
```
Included concepts:
```text
Organization
Team
Person
Agent
Role
Membership
Assignment
Responsibility
Accountability
Authority
Ownership
Stewardship
ReportingLine
```
Required relationships:
```text
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:
```text
Define the minimum organization structure required to connect teams and people to services in the Landscape Model.
```
Included concepts:
```text
Team
Person
Role
ServiceOwner
TechnicalOwner
Operator
SupportGroup
Ownership
Responsibility
Escalation
```
Required relationships:
```text
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:
```text
Support systems where humans and AI/software agents collaborate as actors.
```
Included concepts:
```text
Person
Agent
Team
Role
Assignment
Authority
Delegation
Responsibility
Supervision
AuditReference
```
Required relationships:
```text
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:
```text
Support organizations where people report functionally while being assigned to projects, products, or programs.
```
Included concepts:
```text
Person
FunctionalUnit
ProjectTeam
ProductTeam
ProjectRole
FunctionalRole
ReportingLine
Assignment
Capacity
Availability
```
Required relationships:
```text
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:
```text
exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference
```
## 14.2 Mapping Record
Example:
```yaml
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:
```text
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:
```text
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:
```text
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
```text
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:
```text
service ownership
support groups
runtime operation
technical stewardship
incident escalation
data ownership
system accountability
```
## 16.2 Governance Model
Governance imports organization concepts for:
```text
policy ownership
control ownership
decision authority
risk ownership
audit accountability
exception approval
```
## 16.3 Task Model
Task imports organization concepts for:
```text
assignee
requester
responsible actor
accountable actor
reviewer
approver
team ownership
capacity
availability
```
## 16.4 Access Control Model
Access Control imports organization concepts for:
```text
person
agent
group
role reference
membership
authority
delegation
```
But Access Control owns:
```text
permission
entitlement
credential
access policy
authorization decision
privilege
```
## 16.5 Tagging Standard
Tagging imports organization concepts for tags such as:
```text
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:
```yaml
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:
```text
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:
```text
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:
```text
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:
```text
info-tech-canon/
standards/
organization/
InfoTechCanonOrganizationModel.md
agent-brief.md
concepts/
relationships/
patterns/
profiles/
mappings/
assimilation/
examples/
validation/
```
Seed files:
```text
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:
```text
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:
```text
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