# 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.