# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-24T02:00:48Z", "synthesisSha256": "c626866472ec1be766b3ce256f0e3f375118fb1c462fac4921a367f925ca0bc4", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-ORG-003", "registryId": "vr.wm-org-003", "name": "Team", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Society, people and institutions", "industry": [ "Cross-industry" ], "domain": [ "SOC.ORG.TEM" ], "tags": [ "team", "soc.org.tem" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-org-003-team/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-org-003", "model": { "registry_id": "vr.wm-org-003", "model_id": "WM-ORG-003", "name": "Team", "entry_kind": "aggregate", "purpose": "Provide a format-neutral governed context structure that lets an AI agent identify, constitute, staff, operate, measure, change and retire a team as a bounded working collective, without duplicating the containing organization (WM-ORG-001) or the reusable position catalogue (WM-ORG-004).", "scope_statement": "A Team is a named, bounded collective of two or more actors constituted to perform work together under a shared mandate, whose membership is expressed as time-bounded assignment facts. The model is an aggregate: the team node is the root and the membership-assignment records are governed inside it, following the n-ary reification pattern of org:Membership and FHIR CareTeam.participant. Scope covers identity, classification and capability typing, charter and authority, membership and capability composition, lifecycle and structural change, operating interfaces and footprint, measurement binding, and the governance of team records. Storage and interface (JSON, YAML, Markdown, Git, MCP, MongoDB) are projections and carry no semantics here.", "in_scope": [ "Team instance identity, naming, classification and capability tier", "Charter, mandate, decision rights, accountable owner and reporting line", "Time-bounded membership assignments, in-team roles, external and non-human participants", "Capacity, minimum composition constraints, competence coverage and qualification currency", "Team status lifecycle and structural change events (formation, merge, split, transfer, dissolution)", "Operating interfaces, dependencies, site footprint and time coverage", "Binding of team-level metrics and evidence to a stated observation window", "Provenance, access scope, privacy, retention and interoperability projections of team records" ], "out_of_scope": [ "Legal-entity attributes, registration, LEI and corporate structure of the containing organization (WM-ORG-001)", "Reusable position definitions, job architecture, grading and job descriptions (WM-ORG-004)", "Person master data, employment contract terms, payroll and benefits (worker/person models and HR Open payroll/compensation domains)", "Project, product, work-item and portfolio semantics; a team is not a project", "Definition of individual competences and occupations, which are referenced to ESCO/ISCO-08 rather than restated", "Metric formulae for human capital disclosure, which are referenced to ISO 30414:2025 rather than restated" ], "boundary_notes": [ { "neighbor": "WM-ORG-001 Organization (legal or formal organization)", "distinction": "FHIR states that Organization is 'a formally recognized entity' while a Group 'represents an undifferentiated collection lacking formal legal recognition'; W3C org distinguishes org:FormalOrganization from org:OrganizationalUnit, which is only meaningful as a part of a formal organization. A team instance therefore never carries legal-entity identity or LEI eligibility; it references exactly one containing organization context.", "source_refs": [ "SRC-001", "SRC-003", "SRC-015" ] }, { "neighbor": "WM-ORG-004 Position", "distinction": "org:Post is a reusable position that exists independently of who holds it (org:holds / org:heldBy), whereas the in-team role is the n-ary binding of an agent to this team for a period (org:Membership, CareTeam.participant.role). Position definitions stay in WM-ORG-004; the binding stays in this aggregate.", "source_refs": [ "SRC-001", "SRC-002" ] }, { "neighbor": "Identity-provider group / SCIM Group", "distinction": "A SCIM Group is an access-control grouping whose membership is authoritative for entitlement, with members mutable only through the Group resource. A team may project to a Group but is not defined by it: teams carry mandate, capability typing and lifecycle that SCIM does not model.", "source_refs": [ "SRC-003", "SRC-004" ] }, { "neighbor": "Undifferentiated cohort or list (FHIR Group, definitional membership)", "distinction": "FHIR Group supports 'definitional' membership by characteristic; a team requires 'enumerated' membership with identified participants and roles. Rule-defined cohorts are not teams under this model.", "source_refs": [ "SRC-003" ] }, { "neighbor": "Care team / clinical team", "distinction": "FHIR CareTeam is subject-scoped (bound to a Patient or Group) and carries security category Patient. This model is subject-agnostic; subject-scoped teams are an EXTEND profile, not the base case.", "source_refs": [ "SRC-002" ] }, { "neighbor": "NIMS typed resource team", "distinction": "FEMA types a team definition by minimum capability (Type 1-4) and publishes it as a versioned catalogue entry with its own identifier; that is a team *type* artifact, not a team *instance*. Instance identity must not reuse the typing definition identifier.", "source_refs": [ "SRC-007", "SRC-008" ] }, { "neighbor": "Public-facing department (schema.org)", "distinction": "schema.org department is intended for divisions with a distinguishable public presence (separate URL, logo or hours). Most internal teams do not qualify, so department is an optional publication projection only.", "source_refs": [ "SRC-011" ] } ] }, "sources": [ { "id": "SRC-001", "title": "The Organization Ontology (W3C Recommendation)", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vocab-org/", "version_or_date": "W3C Recommendation 16 January 2014", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:05:00Z", "relevance": "Normative vocabulary for OrganizationalUnit, OrganizationalCollaboration, Membership (n-ary, memberDuring), Post, Role, Site, ChangeEvent, reportsTo, headOf, purpose, classification, subOrganizationOf." }, { "id": "SRC-002", "title": "FHIR R5 Resource CareTeam", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/R5/careteam.html", "version_or_date": "FHIR R5 (5.0.0), published 2023-03-26; maturity level 2, Trial Use", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:07:00Z", "relevance": "The most explicit normative schema for a team entity: identifier, status lifecycle, category, name, period, participant with role/member/onBehalfOf/coverage, reason, managingOrganization, telecom." }, { "id": "SRC-003", "title": "FHIR R5 Resource Group", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/R5/group.html", "version_or_date": "FHIR R5 (5.0.0); maturity level 3, Trial Use", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:09:00Z", "relevance": "Provides the definitional-versus-enumerated membership distinction, member.period/inactive, managingEntity, quantity, and the explicit boundary statements between Group, CareTeam, Organization and List." }, { "id": "SRC-004", "title": "RFC 7643 - System for Cross-domain Identity Management: Core Schema", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc7643", "version_or_date": "September 2015, Standards Track (Proposed Standard)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:11:00Z", "relevance": "Group resource: server-assigned immutable id, client externalId, meta (created, lastModified, version, location), members with value/$ref/type, nested groups, and the rule that membership changes are applied via the Group resource." }, { "id": "SRC-005", "title": "RFC 3339 - Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339", "version_or_date": "July 2002, Proposed Standard (updated by RFC 9557)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:13:00Z", "relevance": "Mandatory timestamp profile: full-date, full-time with seconds, explicit offset or Z, optional fractional seconds, and -00:00 for unknown local offset." }, { "id": "SRC-006", "title": "PROV-O: The PROV Ontology (W3C Recommendation)", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-o/", "version_or_date": "W3C Recommendation 30 April 2013", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:15:00Z", "relevance": "Entity/Activity/Agent, wasGeneratedBy, wasAttributedTo, wasDerivedFrom, startedAtTime, endedAtTime, actedOnBehalfOf, qualifiedAssociation with hadRole and hadPlan, plus Person/Organization/SoftwareAgent." }, { "id": "SRC-007", "title": "NIMS Resource Typing Definition: Emergency Operations Center Management Support Team (RTLT 23-508-1289)", "organization": "U.S. Federal Emergency Management Agency (FEMA), National Integration Center", "url": "https://rtlt.preptoolkit.fema.gov/Public/Resource/View/23-508-1289", "version_or_date": "Version 1.1, original release 2022-08-30, last updated 2022-11-10, status Published", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:18:00Z", "relevance": "Concrete normative structure of a typed team: category, kind = Team, Type 1-3 tiers, overall function, composition and ordering specifications, minimum personnel and equipment components, primary core capability, delegated authorities." }, { "id": "SRC-008", "title": "Resource Typing Library Tool (RTLT) - Help", "organization": "U.S. Federal Emergency Management Agency (FEMA), National Integration Center", "url": "https://rtlt.preptoolkit.fema.gov/Public/Home/Help", "version_or_date": "Tool version v1.8.2, accessed 2026-08-24", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:20:00Z", "relevance": "Registry of resource typing definitions, job titles/position qualifications, Position Task Books and skillsets, each with unique identifier, document type, category, core capability and status." }, { "id": "SRC-009", "title": "ISO 30414:2025 - Strengthening Human Capital Reporting and Disclosure", "organization": "ISO/TC 260 Human resource management", "url": "https://committee.iso.org/sites/tc260/home/news/content-left-area/news-and-updates/iso-30414-2025-strengthening-hum.html", "version_or_date": "ISO 30414:2025, second edition, published 2025-08-24", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:23:00Z", "relevance": "Human capital reporting requirements: 11 human capital areas, 14 baseline required metrics, materiality declaration, consolidation guidance for multi-unit entities, data governance/AI/digital tagging guidance." }, { "id": "SRC-010", "title": "ESCO Occupations pillar", "organization": "European Commission (DG EMPL)", "url": "https://esco.ec.europa.eu/en/classification/occupation_main", "version_or_date": "ESCO v1.2.1, updated 2025-12-10", "source_type": "classifier", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:25:00Z", "relevance": "Governed occupation and skill URIs under data.europa.eu/esco, built on ISCO-08 (ISCO supplies the top four levels); each occupation maps to exactly one ISCO-08 code and carries knowledge/skill/competence links." }, { "id": "SRC-011", "title": "schema.org Organization", "organization": "Schema.org Community Group", "url": "https://schema.org/Organization", "version_or_date": "Schema.org version 30.0, released 2026-03-19", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:27:00Z", "relevance": "member, memberOf, employee, department, parentOrganization, subOrganization, foundingDate, dissolutionDate, location, numberOfEmployees, and OrganizationRole with roleName/startDate/endDate for time-qualified membership." }, { "id": "SRC-012", "title": "HR Open Standards - Standards releases", "organization": "HR Open Standards Consortium, Inc.", "url": "https://www.hropenstandards.org/standards", "version_or_date": "Release 4.5 Final (2026-02-05); 4.6 Candidate Release (2026-05-08)", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:29:00Z", "relevance": "Consensus HR data-exchange suite (JSON Schema and XSD) and the OrganizationChart model of organization units, positions and incumbents used for alignment of team-to-position bindings." }, { "id": "SRC-013", "title": "HR Open Standards 4.5R specification index", "organization": "HR Open Standards Consortium, Inc.", "url": "https://www.hropentech.org/4.5R/specifications", "version_or_date": "Release 4.5R, accessed 2026-08-24", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:31:00Z", "relevance": "Enumerates the shipped domains (Common, Assessments, Benefits, Compensation, Interviewing, Payroll, Recruiting, Screening, Timecard, Wellness); no Team noun is published, which is direct evidence that team is not a first-class HR interchange object." }, { "id": "SRC-014", "title": "NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations", "organization": "U.S. National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final", "version_or_date": "Revision 5, September 2020; updated 2020-12-10; control release 5.2.0 issued 2025-08-27", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:33:00Z", "relevance": "Access Control and Personnel Security control families that govern group/role membership provisioning, separation of duties, least privilege and access revocation on transfer or termination." }, { "id": "SRC-015", "title": "Introducing the Legal Entity Identifier (LEI)", "organization": "Global Legal Entity Identifier Foundation (GLEIF)", "url": "https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei", "version_or_date": "ISO 17442 (2012; Part 2 2019); GLEIF established 2014; page accessed 2026-08-24", "source_type": "registry", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:35:00Z", "relevance": "Evidence that the only widely governed global organizational identifier scheme targets legal entities and their Level 1/Level 2 relationship data, not internal teams; establishes that team instances have no external authoritative register." }, { "id": "SRC-016", "title": "The 2020 Scrum Guide", "organization": "Scrum.org / Ken Schwaber and Jeff Sutherland", "url": "https://scrumguides.org/scrum-guide.html", "version_or_date": "November 2020, CC BY-SA 4.0", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-08-24T09:37:00Z", "relevance": "A widely adopted methodology constraint set: typically 10 or fewer people, cross-functional, self-managing, three accountabilities, and the assertion that there are no sub-teams or hierarchies within a Scrum Team." }, { "id": "SRC-017", "title": "29 CFR 1910.156 - Fire brigades", "organization": "U.S. Occupational Safety and Health Administration (OSHA)", "url": "https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.156", "version_or_date": "29 CFR Part 1910 Subpart L, current text accessed 2026-08-24", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:39:00Z", "relevance": "A rare binding requirement that a team be constituted by a written organizational statement establishing its existence, basic organizational structure, type/amount/frequency of training, expected number of members and expected functions, plus physical capability and recurring training duties." }, { "id": "SRC-018", "title": "Principles of the GDPR - what data can we process and under which conditions", "organization": "European Commission", "url": "https://commission.europa.eu/law/law-topic/data-protection/reform/rules-business-and-organisations/principles-gdpr_en", "version_or_date": "Regulation (EU) 2016/679; page accessed 2026-08-24", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:41:00Z", "relevance": "Purpose limitation, data minimisation, accuracy, storage limitation ('shortest time possible'), integrity and confidentiality, and accountability, which constrain how team membership and team-level performance data may be retained and disclosed." }, { "id": "SRC-019", "title": "HL7 FHIR Release 5 Resource CareTeam", "organization": "HL7 International", "url": "https://www.hl7.org/fhir/careteam.html", "version_or_date": "FHIR v5.0.0 (R5), 2023-03-26; page retrieved 2026-08-24", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T20:00:00Z", "relevance": "Clinical and operational CareTeam resource covering identifier, status, category, name, subject, period, nested participants, role-only members, onBehalfOf, managingOrganization, telecom, notes and the Group boundary." }, { "id": "SRC-020", "title": "REST API endpoints for teams", "organization": "GitHub, Inc.", "url": "https://docs.github.com/en/rest/teams/teams", "version_or_date": "GitHub REST API version 2026-03-10", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T20:00:00Z", "relevance": "Workplace team resource with numeric id, node_id, slug, name, description, privacy, parent, organization, created_at, updated_at, maintainer assignment and nested parent_team_id." }, { "id": "SRC-021", "title": "team resource type - Microsoft Graph v1.0", "organization": "Microsoft", "url": "https://learn.microsoft.com/en-us/graph/api/resources/team?view=graph-rest-1.0", "version_or_date": "Microsoft Graph v1.0, last updated 2024-10-18", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T20:00:00Z", "relevance": "Collaboration team bound to a Microsoft 365 group, with id, displayName, classification, visibility, createdDateTime, isArchived, specialization, member and guest settings, archive, unarchive, clone, members and schedule." }, { "id": "SRC-022", "title": "RFC 7643 System for Cross-domain Identity Management: Core Schema", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc7643.html", "version_or_date": "RFC 7643, September 2015", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T20:00:00Z", "relevance": "SCIM Group schema urn:ietf:params:scim:schemas:core:2.0:Group with id, externalId, meta, displayName and nested User or Group members used when teams are provisioned as identity groups." }, { "id": "SRC-023", "title": "SportsTeam - Schema.org Type", "organization": "Schema.org", "url": "https://schema.org/SportsTeam", "version_or_date": "Schema.org SportsTeam canonical type; usage stats Google July 2026; accessed 2026-08-24", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T20:00:00Z", "relevance": "Sports team as an Organization subtype with athlete, coach, sport, member, memberOf, OrganizationRole startDate and endDate, founding and dissolution dates, and home location." }, { "id": "SRC-024", "title": "ISO 30400:2022 Human resource management — Vocabulary", "organization": "International Organization for Standardization (ISO)", "url": "https://www.iso.org/standard/78044.html", "version_or_date": "ISO 30400:2022, published 2022-11, Edition 2", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T20:00:00Z", "relevance": "Defines organization as a person or group of people that has its own functions with responsibilities, authorities and relationships to achieve its objectives, supporting Team as a purpose-bearing group without supplying a public Team-specific term." }, { "id": "SRC-025", "title": "About organization teams", "organization": "GitHub, Inc.", "url": "https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams", "version_or_date": "GitHub Docs, retrieved 2026-08-24", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T20:00:00Z", "relevance": "Defines teams as groups of organization members for access and mentions; visible versus secret teams; nested parent and child teams; inherited permissions; and the rule that child-team members are not direct members of the parent." }, { "id": "SRC-026", "title": "REST API endpoints for team members", "organization": "GitHub, Inc.", "url": "https://docs.github.com/en/rest/teams/members", "version_or_date": "GitHub REST API version 2026-03-10", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T20:00:00Z", "relevance": "Membership role member or maintainer, inherited flag, membership state active, pending invitations, and identity-provider team synchronization that blocks local membership writes." }, { "id": "SRC-027", "title": "FOAF Vocabulary Specification 0.99", "organization": "FOAF Project (Dan Brickley and Libby Miller)", "url": "https://xmlns.com/foaf/spec/", "version_or_date": "FOAF 0.99 Paddington Edition, 14 January 2014", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T20:00:00Z", "relevance": "Stable Agent, Person, Group, Organization and Project classes with member and membershipClass, used to keep Team distinct from a generic class of agents and from FOAF Organization or Project." } ], "structure": { "bundles": [ { "id": "identity-and-boundary", "name": "Identity and boundary", "description": "What makes a team instance the same thing over time, and what it is not.", "rationale": "Three independent standards (W3C org, FHIR, SCIM) each draw the team boundary differently, and no external register issues identifiers for team instances, so identity and boundary must be settled before any other context is asserted.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-015" ], "layers": [ { "id": "team-identity", "name": "Team identity", "description": "Identifier assignment, naming and the entity distinctions that keep a team from collapsing into an organization, a group or a position.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-015" ], "findings": [ { "id": "team-identifier-assignment", "name": "Team instance identifier assignment", "description": "A team instance normally has no authoritative external register. SCIM supplies a server-assigned immutable id plus a client-supplied externalId; FHIR CareTeam and Group both carry 0..* business identifiers; GLEIF/ISO 17442 covers legal entities only. Identity therefore resolves in priority order: authoritative master-system identifier (HRIS org-unit key or IdP group id), then a governed IRI in the adopting Dimension's namespace, then a Dimension-minted UUID or ULID. Names and dates are never identifiers.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-015" ], "questions": [ { "id": "q-master-system", "text": "Which system of record is authoritative for this team's identifier, and what is the key?", "kind": "identity", "answer_data": [ "Master system name and instance", "Native key value", "Key immutability and reuse policy" ] }, { "id": "q-id-fallback", "text": "If no master-system key exists, which governed IRI or Dimension-minted UUID/ULID is assigned, and by whom?", "kind": "identity", "answer_data": [ "Assigned identifier value and scheme", "Minting authority", "Assignment timestamp (RFC 3339)" ] }, { "id": "q-alt-ids", "text": "Which alternate business identifiers must be carried, and which are merely correlational?", "kind": "interoperability", "answer_data": [ "Identifier system URI", "Identifier value", "Authoritative or correlational flag" ] }, { "id": "q-merge-identity", "text": "When two records are found to describe the same team, which survives and how is the loser tombstoned?", "kind": "exception", "answer_data": [ "Surviving identifier", "Superseded identifier", "Merge decision record reference" ] } ], "data_elements": [ { "id": "team-id", "name": "team_id", "description": "Canonical identifier for the team instance in the adopting Dimension.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "team-external-id", "name": "external_identifier", "description": "Identifier assigned by an external or upstream system, qualified by its issuing system URI.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "team-display-name", "name": "display_name", "description": "Human-readable label; mutable and explicitly not an identifier.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-004" ] } ], "artifacts": [ { "id": "team-registry-entry", "name": "Team registry entry", "description": "The authoritative record that binds the canonical identifier to the team, its alternate identifiers and the minting decision.", "media_or_form": [ "structured record", "registry entry" ], "serial": false, "identity_strategy": "Keyed by team_id; alternate identifiers held as system-qualified pairs.", "source_refs": [ "SRC-004", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "team-boundary-and-entity-distinction", "name": "Boundary against organization, group and position", "description": "FHIR states that Organization is a formally recognized entity while Group is an undifferentiated collection lacking formal legal recognition, and that CareTeam participants are differentiated individuals. W3C org separates FormalOrganization, OrganizationalUnit and OrganizationalCollaboration. HR Open publishes no Team noun at all. Each instance must therefore declare which of these it actually is, or be rejected as a team.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-013" ], "questions": [ { "id": "q-formal-status", "text": "Is this collective an internal unit of one formal organization, a cross-organization collaboration, or a rule-defined cohort?", "kind": "classification", "answer_data": [ "Boundary class (unit, collaboration, cohort)", "Containing organization reference", "Participating organizations for collaborations" ] }, { "id": "q-enumerated", "text": "Is membership enumerated by identified participants or defined by characteristics?", "kind": "composition", "answer_data": [ "Membership basis (enumerated or definitional)", "Characteristic expressions if definitional" ] }, { "id": "q-legal-recognition", "text": "Does the team have any separate legal recognition, and if not, which legal entity bears its obligations?", "kind": "authority", "answer_data": [ "Legal recognition flag", "Bearing legal entity identifier", "Evidence reference" ] }, { "id": "q-not-a-team", "text": "What disqualifies this record from being a team under this model?", "kind": "validation", "answer_data": [ "Disqualifying condition list", "Rejection rationale" ] } ], "data_elements": [ { "id": "boundary-class", "name": "boundary_class", "description": "Declared class: organizational unit, organizational collaboration, or non-team cohort.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "membership-basis", "name": "membership_basis", "description": "Whether membership is enumerated or definitional.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "containing-organization", "name": "containing_organization_ref", "description": "Reference to the organization context that contains or hosts the team.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "These are classification assertions on the team record itself; they produce no separate document and are resolved by reference to the containing organization model." }, { "id": "team-names-and-labels", "name": "Names, slugs and descriptions", "description": "Human-readable names, alternative labels, generated slugs or mail nicknames, and optional descriptions that distinguish like teams without serving as identity.", "source_refs": [ "SRC-001", "SRC-019", "SRC-020", "SRC-021", "SRC-022" ], "questions": [ { "id": "team-names-and-labels-q01", "text": "What is the preferred human-readable name of the team, and in which language or locale is it expressed?", "kind": "identity", "answer_data": [ "preferred_name", "language_tag", "locale" ] }, { "id": "team-names-and-labels-q02", "text": "What alternative names, generated slugs, mail nicknames or notations exist, and which system derives them from the preferred name?", "kind": "identity", "answer_data": [ "alternative_names", "slug", "mail_nickname", "derivation_rule" ] }, { "id": "team-names-and-labels-q03", "text": "What description or comment distinguishes this team from similarly named teams, such as red versus green trauma teams?", "kind": "definition", "answer_data": [ "description", "disambiguating_label" ] }, { "id": "team-names-and-labels-q04", "text": "Who is authorized to change the team name, description or profile picture?", "kind": "authority", "answer_data": [ "name_change_authority", "profile_maintainers" ] } ], "data_elements": [ { "id": "team-names-and-labels-data01", "name": "Preferred name", "description": "Primary display name, corresponding to skos:prefLabel, FHIR name, GitHub name, Microsoft displayName or SCIM displayName.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-019", "SRC-020", "SRC-021", "SRC-022" ] }, { "id": "team-names-and-labels-data02", "name": "Alternative names", "description": "Trading, colloquial or historical names using skos:altLabel or equivalent.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "team-names-and-labels-data03", "name": "Slug or mail nickname", "description": "URL or mention handle derived from the name, such as a GitHub slug or Microsoft mailNickname. Not an identifier.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-021" ] }, { "id": "team-names-and-labels-data04", "name": "Description", "description": "Optional description; Microsoft Graph limits description to 1024 characters.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-021" ] } ], "artifacts": [ { "id": "team-names-and-labels-artifact01", "name": "Team profile page", "description": "The team page or profile from which name, description and picture are maintained, such as a GitHub team page.", "media_or_form": [ "web page", "image" ], "serial": false, "identity_strategy": "Team master identifier plus profile resource locator from the host organization directory", "source_refs": [ "SRC-025" ] } ], "inline_only_rationale": null }, { "id": "containing-and-managing-organization", "name": "Containing and managing organization", "description": "Most workplace teams are units of one FormalOrganization or Microsoft tenant. FHIR separately records managingOrganization as the organization responsible for the care team. GitHub teams exist only inside an organization.", "source_refs": [ "SRC-001", "SRC-019", "SRC-020", "SRC-021", "SRC-025" ], "questions": [ { "id": "containing-and-managing-organization-q01", "text": "Which Organization instance contains this team, and is the team a unit with meaning only inside that organization?", "kind": "relationship", "answer_data": [ "containing_organization_id", "unit_of_flag" ] }, { "id": "containing-and-managing-organization-q02", "text": "Which organization is responsible for managing the team, if that is different from the containing organization?", "kind": "ownership", "answer_data": [ "managing_organization_ids" ] }, { "id": "containing-and-managing-organization-q03", "text": "Which tenant, directory or provisioning domain hosts the team record?", "kind": "identity", "answer_data": [ "tenant_id", "directory_id", "provisioning_domain" ] }, { "id": "containing-and-managing-organization-q04", "text": "Must every member already belong to the containing organization, as GitHub requires, or may outsiders participate?", "kind": "constraint", "answer_data": [ "members_must_be_org_members", "outsider_participation_rule" ] } ], "data_elements": [ { "id": "containing-and-managing-organization-data01", "name": "Containing organization", "description": "Reference to the Organization of which this team is a unit or child.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-020" ] }, { "id": "containing-and-managing-organization-data02", "name": "Managing organizations", "description": "Organizations responsible for the team, as in FHIR managingOrganization.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "containing-and-managing-organization-data03", "name": "Tenant identifier", "description": "Microsoft Entra tenant or equivalent directory that hosts the team.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021" ] } ], "artifacts": [ { "id": "containing-and-managing-organization-artifact01", "name": "Organization chart extract", "description": "Chart or directory extract showing the team as a unit of a containing organization.", "media_or_form": [ "diagram", "canonical record" ], "serial": true, "identity_strategy": "Containing organization master identifier plus chart version timestamp in RFC 3339", "source_refs": [ "SRC-001" ] } ], "inline_only_rationale": null } ] }, { "id": "team-classification", "name": "Team classification and capability typing", "description": "Two orthogonal axes: what kind of team it is, and what capability tier it can deliver.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-007", "SRC-011" ], "findings": [ { "id": "team-type-and-category", "name": "Team type and category", "description": "FHIR CareTeam carries category 0..* and Group carries a required type from a closed value set; org:classification allows an organization-specific scheme; schema.org offers department and subOrganization as publication projections. Classification is multi-valued and scheme-qualified, never a single free-text label.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-011" ], "questions": [ { "id": "q-scheme", "text": "Which controlled classification schemes apply, and what is the code in each?", "kind": "classification", "answer_data": [ "Scheme URI", "Code value", "Code display term" ] }, { "id": "q-permanence", "text": "Is the team standing, time-boxed or incident-activated, and what evidence supports that?", "kind": "classification", "answer_data": [ "Permanence code", "Expected duration", "Constituting document reference" ] }, { "id": "q-public-projection", "text": "Does the team qualify as a publicly presented department with its own URL, logo or hours?", "kind": "interoperability", "answer_data": [ "Public presence flag", "Public URL", "Projection decision rationale" ] } ], "data_elements": [ { "id": "team-category", "name": "category", "description": "Scheme-qualified classification codes for the team.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "permanence-code", "name": "permanence", "description": "Standing, time-boxed, or activated-on-demand.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Classification is inline coded data on the team record; the controlled vocabularies themselves are external registries referenced by URI rather than artifacts owned by this model." }, { "id": "capability-typing-and-tier", "name": "Capability typing and tier", "description": "FEMA types a team by minimum capability into Type 1-4, where each tier fixes an overall function, minimum personnel with qualification codes, equipment and communications, plus composition and ordering specifications. This is a type-level artifact with its own identifier and version, distinct from the team instance that claims to meet it.", "source_refs": [ "SRC-007", "SRC-008" ], "questions": [ { "id": "q-typing-def", "text": "Against which published typing definition and version does this team claim a tier?", "kind": "evidence", "answer_data": [ "Typing definition identifier", "Definition version", "Publisher" ] }, { "id": "q-tier-claim", "text": "Which capability tier is claimed, and what verified evidence supports the claim?", "kind": "quality", "answer_data": [ "Claimed tier", "Verification method", "Verifier identity and date" ] }, { "id": "q-shortfall", "text": "Where does the current composition fall short of the claimed tier, and what compensating measure applies?", "kind": "constraint", "answer_data": [ "Shortfall component", "Gap quantity", "Compensating measure and expiry" ] }, { "id": "q-ordering", "text": "What must a requester agree before this team can be deployed or engaged?", "kind": "process", "answer_data": [ "Ordering specification items", "Delegated authorities required", "Logistics preconditions" ] } ], "data_elements": [ { "id": "capability-tier", "name": "capability_tier", "description": "Claimed capability tier against a named typing definition.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "typing-definition-ref", "name": "typing_definition_ref", "description": "Identifier and version of the external typing definition the claim is made against.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "tier-verified-at", "name": "tier_verified_at", "description": "Instant at which the tier claim was last verified.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-007" ] } ], "artifacts": [ { "id": "capability-typing-sheet", "name": "Capability typing definition sheet", "description": "The versioned type-level document stating overall function, tiers, minimum personnel and equipment, and ordering specifications.", "media_or_form": [ "published definition document", "structured record" ], "serial": true, "identity_strategy": "External publisher identifier plus version; never reused as the team instance identifier.", "source_refs": [ "SRC-007", "SRC-008" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "mandate-and-authority", "name": "Mandate and authority", "description": "Why the team exists, what it may decide, and who is accountable for it.", "rationale": "OSHA 1910.156(b)(1) shows that a documented constituting statement can be a binding legal requirement, and W3C org supplies purpose, reportsTo and headOf; without a mandate a membership list is not a team.", "source_refs": [ "SRC-001", "SRC-002", "SRC-017" ], "layers": [ { "id": "charter-and-purpose", "name": "Charter and purpose", "description": "The constituting record: existence, purpose, expected functions, structure and training obligations.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007", "SRC-016", "SRC-017" ], "findings": [ { "id": "team-charter-and-mandate", "name": "Team charter and mandate", "description": "OSHA requires an employer to prepare and maintain a written statement establishing the existence of the brigade, its basic organizational structure, the type, amount and frequency of training, the expected number of members and the functions to be performed. W3C org supplies org:purpose, FHIR supplies CareTeam.reason, FEMA supplies overall function, and the Scrum Guide supplies the pattern of a single shared objective. The charter is the authoritative statement of scope and is versioned.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007", "SRC-016", "SRC-017" ], "questions": [ { "id": "q-charter-exists", "text": "Is there a written constituting statement, who approved it, and when did it take effect?", "kind": "authority", "answer_data": [ "Charter document reference", "Approver identity and role", "Effective timestamp (RFC 3339)" ] }, { "id": "q-purpose", "text": "What is the team's purpose and the specific functions it is expected to perform?", "kind": "definition", "answer_data": [ "Purpose statement", "Enumerated expected functions", "Explicit non-functions" ] }, { "id": "q-mandated-by-law", "text": "Is any element of the charter mandated by law, regulation or contract rather than chosen?", "kind": "requirement", "answer_data": [ "Obligation source citation", "Mandated element", "Jurisdiction" ] }, { "id": "q-objective-window", "text": "What objective is the team accountable for, over what period, and how is attainment judged?", "kind": "measurement", "answer_data": [ "Objective statement", "Objective period start and end", "Attainment criteria" ] }, { "id": "q-charter-review", "text": "When must the charter be reviewed or revalidated, and what triggers an out-of-cycle review?", "kind": "lifecycle", "answer_data": [ "Review interval", "Trigger conditions", "Last review timestamp" ] } ], "data_elements": [ { "id": "purpose-statement", "name": "purpose", "description": "Declared purpose of the team.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-017" ] }, { "id": "expected-functions", "name": "expected_functions", "description": "Enumerated functions the team is constituted to perform.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007", "SRC-017" ] }, { "id": "charter-effective-period", "name": "charter_effective_period", "description": "Start and optional end of charter validity, expressed as RFC 3339 instants.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-002" ] }, { "id": "mandate-obligation-ref", "name": "mandate_obligation_ref", "description": "Citation of any legal or contractual instrument that compels the team's existence or composition.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [ { "id": "team-charter", "name": "Team charter / organizational statement", "description": "The written, approved and maintained statement establishing the team, its structure, expected membership, training obligations and functions.", "media_or_form": [ "approved written statement", "policy document" ], "serial": true, "identity_strategy": "Charter identifier plus monotonically increasing version, each version carrying its own approval and effective timestamps.", "source_refs": [ "SRC-017", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "authority-and-accountability", "name": "Authority and accountability", "description": "Decision rights, the accountable owner and the placement of the team in reporting structures.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-014", "SRC-016" ], "findings": [ { "id": "decision-rights-ownership-and-reporting-line", "name": "Decision rights, ownership and reporting line", "description": "W3C org gives headOf, reportsTo, unitOf and hasPost; FHIR gives CareTeam.managingOrganization 0..* and Group.managingEntity; FEMA requires delegated authorities to be agreed before deployment; the Scrum Guide assigns distinct accountabilities within a single team. NIST separation of duties and least privilege constrain which decision rights may be concentrated in one holder.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-007", "SRC-014", "SRC-016" ], "questions": [ { "id": "q-accountable-owner", "text": "Which single party is accountable for the team's outcomes, and through which post is that held?", "kind": "ownership", "answer_data": [ "Accountable party reference", "Post reference in WM-ORG-004", "Accountability period" ] }, { "id": "q-managing-orgs", "text": "Which organizations manage or co-manage the team, and how are conflicts between them resolved?", "kind": "authority", "answer_data": [ "Managing organization references", "Co-management arrangement", "Escalation path" ] }, { "id": "q-decision-rights", "text": "Which decisions may the team make autonomously, which need approval, and up to what threshold?", "kind": "authority", "answer_data": [ "Decision class", "Autonomy level", "Approval threshold and approver" ] }, { "id": "q-sod", "text": "Which combinations of decision rights must not be held by the same person?", "kind": "security", "answer_data": [ "Incompatible right pairs", "Enforcement mechanism", "Documented exception and compensating control" ] }, { "id": "q-reporting-line", "text": "Where does the team sit in the reporting structure, and is that line solid or matrixed?", "kind": "relationship", "answer_data": [ "Parent unit reference", "Line type (solid, dotted, matrixed)", "Secondary reporting references" ] } ], "data_elements": [ { "id": "accountable-owner-ref", "name": "accountable_owner_ref", "description": "Reference to the party accountable for the team.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "managing-org-ref", "name": "managing_organization_ref", "description": "Organizations that manage the team, allowing more than one for co-managed teams.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "reports-to-ref", "name": "reports_to_ref", "description": "Parent unit or post the team reports to.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "decision-right", "name": "decision_right", "description": "A named decision class with autonomy level, threshold and approver.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-014" ] } ], "artifacts": [ { "id": "delegation-of-authority-record", "name": "Delegation of authority record", "description": "Signed record of decision rights delegated to the team or its lead, including thresholds, duration and separation-of-duties exceptions.", "media_or_form": [ "signed delegation instrument", "structured record" ], "serial": true, "identity_strategy": "Delegation identifier plus version; superseded versions retained with their effective periods.", "source_refs": [ "SRC-007", "SRC-014" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "composition-and-capability", "name": "Composition and capability", "description": "Who is on the team, in what role, at what capacity, and whether the collective can actually do the work.", "rationale": "Every consulted standard models team composition as time-bounded n-ary assignment facts rather than a flat member list, and FEMA and OSHA both make minimum composition and qualification currency binding conditions of operation.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-007", "SRC-017" ], "layers": [ { "id": "membership-records", "name": "Membership records", "description": "The time-bounded assignment facts that constitute the team.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-011" ], "findings": [ { "id": "membership-assignment-record", "name": "Membership assignment record", "description": "W3C org expresses membership as an n-ary org:Membership with memberDuring so that duration, remuneration and contract references can be attached; FHIR CareTeam.participant carries role, member, onBehalfOf and coverage; FHIR Group.member carries period and an inactive flag; schema.org OrganizationRole carries roleName with startDate and endDate; SCIM requires membership changes to be applied via the Group resource. Membership is a first-class dated record, never a mutable array of names.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-011" ], "questions": [ { "id": "q-member-period", "text": "For each member, when did participation start and when did or will it end?", "kind": "temporal", "answer_data": [ "Member reference", "Start instant (RFC 3339)", "End instant or open-ended flag" ] }, { "id": "q-write-authority", "text": "Which system is authoritative for writing membership, and how are conflicting writes from HR and IdP reconciled?", "kind": "authority", "answer_data": [ "Authoritative writer", "Reconciliation rule", "Conflict log reference" ] }, { "id": "q-inactive-vs-removed", "text": "Is a departed member marked inactive with a closed period or removed from the record entirely?", "kind": "state", "answer_data": [ "Retention treatment code", "Inactive flag semantics", "Basis for erasure if removed" ] }, { "id": "q-retroactive", "text": "How are backdated or corrected memberships recorded without losing the prior assertion?", "kind": "provenance", "answer_data": [ "Correction record reference", "Original asserted values", "Correction timestamp and author" ] } ], "data_elements": [ { "id": "membership-id", "name": "membership_id", "description": "Identifier of the individual assignment fact.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "member-ref", "name": "member_ref", "description": "Reference to the person, organization or agent participating.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "member-during", "name": "member_during", "description": "Closed or open interval of participation with RFC 3339 endpoints.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-005" ] }, { "id": "member-inactive", "name": "inactive", "description": "Flag marking a retained but no longer effective membership.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "membership-assignment-artifact", "name": "Membership assignment record", "description": "The durable dated record binding an agent to the team in a role for a period, with its own provenance.", "media_or_form": [ "structured record", "assignment instrument" ], "serial": true, "identity_strategy": "membership_id; supersession chain preserved so no assignment fact is overwritten in place.", "source_refs": [ "SRC-001", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "role-and-position-binding", "name": "In-team role and position binding", "description": "org:Post is a reusable position held by an agent via holds/heldBy; HR Open OrganizationChart models units, positions and incumbents; CareTeam.participant.role types the participation itself. The in-team role is the binding, and is distinct from the position definition owned by WM-ORG-004 and from the occupation code owned by ESCO/ISCO-08.", "source_refs": [ "SRC-001", "SRC-002", "SRC-010", "SRC-012" ], "questions": [ { "id": "q-role-vs-post", "text": "Does this member occupy a defined position, or hold only a team-scoped role with no position behind it?", "kind": "composition", "answer_data": [ "Position reference or null", "Team-scoped role code", "Scheme URI for the role code" ] }, { "id": "q-occupation-code", "text": "Which governed occupation code describes the work performed, and under which classification version?", "kind": "classification", "answer_data": [ "Occupation URI", "Classification and version", "Mapping confidence" ] }, { "id": "q-multiple-roles", "text": "May one member hold several roles in the same team at once, and how is that recorded?", "kind": "constraint", "answer_data": [ "Multiplicity rule", "Concurrent role records", "Conflict rule" ] }, { "id": "q-lead-role", "text": "Which role carries leadership of the team, and is it the same as the accountable owner?", "kind": "authority", "answer_data": [ "Lead role reference", "Divergence from accountable owner", "Rationale" ] } ], "data_elements": [ { "id": "in-team-role", "name": "in_team_role", "description": "Scheme-qualified role played by the member within this team.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "position-ref", "name": "position_ref", "description": "Reference to a reusable position governed by WM-ORG-004.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-012" ] }, { "id": "occupation-uri", "name": "occupation_uri", "description": "Governed occupation identifier such as an ESCO or ISCO-08 URI.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "The binding is inline on the membership record; the reusable position definition and the occupation taxonomy are artifacts owned by WM-ORG-004 and by the external classifier respectively." }, { "id": "external-and-non-human-participants", "name": "External and non-human participants", "description": "CareTeam.participant.onBehalfOf lets a participant act for another organization; Group.type admits practitioner, device and organization members; SCIM supports nested groups; org:OrganizationalCollaboration covers teams spanning organizations; PROV distinguishes Person, Organization and SoftwareAgent. Contractors, partner-org members, nested sub-teams and software or robotic agents must be representable without pretending they are employees.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-006" ], "questions": [ { "id": "q-onbehalfof", "text": "On whose behalf does each external participant act, and under which contract?", "kind": "relationship", "answer_data": [ "Participant reference", "onBehalfOf organization reference", "Contract or agreement reference" ] }, { "id": "q-nonhuman", "text": "Are any participants software agents, devices or robots, and who is the responsible human principal?", "kind": "ownership", "answer_data": [ "Agent type code", "Agent identifier", "Responsible principal reference" ] }, { "id": "q-nested", "text": "Does the team contain nested sub-teams, and is that permitted by the governing method or policy?", "kind": "composition", "answer_data": [ "Nested team references", "Permission basis", "Depth limit" ] }, { "id": "q-external-access", "text": "What data may an external participant see, and what is withheld?", "kind": "access", "answer_data": [ "Permitted scope", "Withheld elements", "Policy reference" ] } ], "data_elements": [ { "id": "participant-kind", "name": "participant_kind", "description": "Person, organization, software agent or device.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-006" ] }, { "id": "on-behalf-of-ref", "name": "on_behalf_of_ref", "description": "Organization the participant represents when not an employee of the containing organization.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "nested-team-ref", "name": "nested_team_ref", "description": "Reference to a contained sub-team where nesting is permitted.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] } ], "artifacts": [ { "id": "engagement-agreement", "name": "External participation agreement", "description": "The contract, secondment letter or inter-agency agreement authorising a non-employee or partner-organization participant.", "media_or_form": [ "contract", "agreement record" ], "serial": true, "identity_strategy": "Agreement identifier plus amendment sequence; linked to the membership record it authorises.", "source_refs": [ "SRC-001", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "nesting-and-inherited-membership", "name": "Parent-child and team-of-teams", "description": "GitHub allows one parent team and many children; child teams inherit parent permissions; listed members of a parent include child members but those members are not direct parent members. Secret teams cannot nest. Scrum forbids sub-teams and instead splits oversized teams into multiple teams sharing a Product Goal. SCIM Groups may nest Groups. FHIR CareTeam may have another CareTeam as a participant.", "source_refs": [ "SRC-019", "SRC-020", "SRC-022", "SRC-016", "SRC-025" ], "questions": [ { "id": "nesting-and-inherited-membership-q01", "text": "What is the parent team, if any, and does this team have exactly one parent as in GitHub or an open unit hierarchy as in ORG?", "kind": "relationship", "answer_data": [ "parent_team_id", "hierarchy_cardinality_rule" ] }, { "id": "nesting-and-inherited-membership-q02", "text": "Which child teams exist, and do their members count as inherited members of this team for listing, mentions or permissions?", "kind": "composition", "answer_data": [ "child_team_ids", "inherited_member_semantics" ] }, { "id": "nesting-and-inherited-membership-q03", "text": "Is nesting forbidden because this is a Scrum Team, a secret team, or another profile that rejects sub-teams?", "kind": "constraint", "answer_data": [ "nesting_forbidden", "forbidding_profile" ] }, { "id": "nesting-and-inherited-membership-q04", "text": "When size or complexity requires change, should the team split into sibling teams sharing a goal rather than adding a child team?", "kind": "decision", "answer_data": [ "split_recommendation", "shared_goal_after_split" ] } ], "data_elements": [ { "id": "nesting-and-inherited-membership-data01", "name": "Parent team", "description": "Reference to a single parent team where the platform uses a tree, such as GitHub parent.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-025" ] }, { "id": "nesting-and-inherited-membership-data02", "name": "Child teams", "description": "Teams nested under this team.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-025" ] }, { "id": "nesting-and-inherited-membership-data03", "name": "Nesting forbidden", "description": "True when the chosen profile or privacy class, such as Scrum or GitHub secret, forbids parent or child teams.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-025" ] } ], "artifacts": [ { "id": "nesting-and-inherited-membership-artifact01", "name": "Team hierarchy snapshot", "description": "Point-in-time tree of parent and child teams used to audit inherited permissions.", "media_or_form": [ "diagram", "canonical record" ], "serial": true, "identity_strategy": "Containing organization identifier plus snapshot observation time in RFC 3339", "source_refs": [ "SRC-025" ] } ], "inline_only_rationale": null }, { "id": "membership-provisioning-and-sync-authority", "name": "Invitation, synchronization and dynamic rules", "description": "Membership may be pending invitation, locked to an identity-provider group, or computed from a dynamic membership rule. Local writes may be forbidden while synchronization is active.", "source_refs": [ "SRC-021", "SRC-026" ], "questions": [ { "id": "membership-provisioning-and-sync-authority-q01", "text": "Which invitations to join the team are pending, who invited them, and when were the invitations created?", "kind": "event", "answer_data": [ "invitee", "inviter", "invitation_created_at", "invitation_role" ] }, { "id": "membership-provisioning-and-sync-authority-q02", "text": "Is membership synchronized from an identity-provider group, and does that block local add or remove operations?", "kind": "interoperability", "answer_data": [ "idp_sync_enabled", "idp_group_id", "local_write_blocked" ] }, { "id": "membership-provisioning-and-sync-authority-q03", "text": "Is membership computed from a directory rule, and is processing on or paused?", "kind": "process", "answer_data": [ "dynamic_membership_flag", "membership_rule", "processing_state" ] }, { "id": "membership-provisioning-and-sync-authority-q04", "text": "Who may add or remove members when local writes are allowed: organization owner, team maintainer, team owner or another role?", "kind": "authority", "answer_data": [ "membership_admin_roles" ] } ], "data_elements": [ { "id": "membership-provisioning-and-sync-authority-data01", "name": "IdP synchronization enabled", "description": "True when GitHub team synchronization or equivalent binds membership to an identity-provider group.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026" ] }, { "id": "membership-provisioning-and-sync-authority-data02", "name": "Dynamic membership rule", "description": "Rule that determines members when the associated group uses dynamic membership.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021" ] }, { "id": "membership-provisioning-and-sync-authority-data03", "name": "Local write blocked", "description": "True when API or local membership changes are rejected because an IdP owns membership.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026" ] } ], "artifacts": [ { "id": "membership-provisioning-and-sync-authority-artifact01", "name": "Team invitation", "description": "Pending invitation to a person to join the team, including inviter, role and creation time.", "media_or_form": [ "canonical record", "message" ], "serial": true, "identity_strategy": "Invitation master identifier from the host organization; else Dimension UUID", "source_refs": [ "SRC-026" ] } ], "inline_only_rationale": null }, { "id": "team-post-establishment-and-holding", "name": "Posts, positions and assignments", "description": "A Post exists independently of the incumbent and is the join to WM-ORG-004. A team may have posts even when vacant. Assignment of a holder is a time-qualified hold relation, not identity of the post.", "source_refs": [ "SRC-001" ], "questions": [ { "id": "team-post-establishment-and-holding-q01", "text": "Which posts or positions exist on this team, including vacant posts that currently have no holder?", "kind": "composition", "answer_data": [ "post_id", "post_label", "vacant_flag" ] }, { "id": "team-post-establishment-and-holding-q02", "text": "Who currently holds each post, and may a post be held by more than one person at once?", "kind": "relationship", "answer_data": [ "post_id", "holder_agent_id", "multiple_holders_allowed" ] }, { "id": "team-post-establishment-and-holding-q03", "text": "What is the assignment interval for each holder, with RFC 3339 start and end?", "kind": "temporal", "answer_data": [ "assignment_start", "assignment_end" ] }, { "id": "team-post-establishment-and-holding-q04", "text": "Is the agent a member of the team ex officio because they hold a post, rather than by personal appointment?", "kind": "relationship", "answer_data": [ "ex_officio_flag", "qualifying_post_id" ] } ], "data_elements": [ { "id": "team-post-establishment-and-holding-data01", "name": "Post or position", "description": "Reference to a WM-ORG-004 Position or org:Post that exists on the team independently of the holder.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "team-post-establishment-and-holding-data02", "name": "Post holder", "description": "Agent currently holding the post.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "team-post-establishment-and-holding-data03", "name": "Ex officio membership", "description": "True when team membership follows from holding the post rather than personal appointment.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "team-post-establishment-and-holding-artifact01", "name": "Team post register", "description": "Register of posts on the team and current or historical holders.", "media_or_form": [ "canonical record", "document" ], "serial": true, "identity_strategy": "Team identifier plus post master identifier from the position register", "source_refs": [ "SRC-001" ] } ], "inline_only_rationale": null } ] }, { "id": "capacity-and-constraints", "name": "Capacity and composition constraints", "description": "How much of each member the team actually has, and the floors the composition must not fall below.", "source_refs": [ "SRC-002", "SRC-007", "SRC-009", "SRC-016", "SRC-017" ], "findings": [ { "id": "allocation-and-capacity", "name": "Allocation and capacity", "description": "CareTeam.participant.coverage expresses when a participant is available to the team; ISO 30414 reports workforce availability and productivity at organizational level; HR Open ships Timecard and Compensation domains that hold the underlying worker-level time data. Allocation is a property of the membership, expressed as a fraction or a schedule, and is the only defensible basis for team capacity.", "source_refs": [ "SRC-002", "SRC-009", "SRC-012" ], "questions": [ { "id": "q-allocation", "text": "What share of each member's working time is committed to this team, and over which period?", "kind": "measurement", "answer_data": [ "Allocation fraction or FTE", "Applicable period", "Source system" ] }, { "id": "q-competing", "text": "Which other teams hold competing claims on the same member, and does the total exceed 1.0 FTE?", "kind": "constraint", "answer_data": [ "Competing team references", "Aggregate allocation", "Over-allocation flag" ] }, { "id": "q-coverage-window", "text": "During which hours and days is the team required to be staffed?", "kind": "temporal", "answer_data": [ "Coverage window with offsets", "On-call arrangement", "Exception days" ] }, { "id": "q-capacity-basis", "text": "Is reported capacity a planned commitment or an observed actual, and from which record?", "kind": "evidence", "answer_data": [ "Basis code (planned or actual)", "Underlying record reference", "Observation window" ] } ], "data_elements": [ { "id": "allocation-fraction", "name": "allocation", "description": "Committed share of a member's capacity to this team.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-009" ] }, { "id": "coverage-window", "name": "coverage_window", "description": "Required staffing window with explicit UTC offsets.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-005" ] }, { "id": "headcount", "name": "headcount", "description": "Count of active members at a stated instant.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-009" ] } ], "artifacts": [ { "id": "roster-snapshot", "name": "Roster and allocation snapshot", "description": "A point-in-time statement of active members, roles, allocations and coverage, used as the evidential basis for capacity claims.", "media_or_form": [ "structured snapshot", "report" ], "serial": true, "identity_strategy": "Team identifier plus snapshot instant in RFC 3339; snapshots are immutable once issued.", "source_refs": [ "SRC-002", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "minimum-composition-constraints", "name": "Minimum composition and staffing constraints", "description": "FEMA fixes minimum personnel and equipment per tier with qualification codes per position; OSHA requires the expected number of members to be stated and bars unfit members from interior structural firefighting absent a physician's certification; the Scrum Guide caps a Scrum Team at typically ten or fewer and forbids sub-teams. These are constraint profiles attached to the team, and they conflict with one another, so the applicable profile must be declared.", "source_refs": [ "SRC-007", "SRC-016", "SRC-017" ], "questions": [ { "id": "q-min-composition", "text": "What is the minimum viable composition by role, and what happens when it is not met?", "kind": "constraint", "answer_data": [ "Minimum count per role", "Breach consequence", "Grace period" ] }, { "id": "q-profile-source", "text": "Which constraint profile applies, and is it legally binding, contractual or methodological?", "kind": "requirement", "answer_data": [ "Profile identifier", "Binding force", "Citation" ] }, { "id": "q-size-limits", "text": "Are there maximum size or nesting limits, and what evidence supports them?", "kind": "constraint", "answer_data": [ "Maximum size", "Nesting permission", "Supporting source" ] }, { "id": "q-fitness", "text": "Are there fitness, medical or physical prerequisites for any role in this team?", "kind": "requirement", "answer_data": [ "Prerequisite description", "Certifying authority", "Recheck interval" ] } ], "data_elements": [ { "id": "min-role-count", "name": "minimum_role_count", "description": "Required minimum number of members holding a given role.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-017" ] }, { "id": "constraint-profile-ref", "name": "constraint_profile_ref", "description": "Reference to the governing constraint profile and its binding force.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-016", "SRC-017" ] }, { "id": "composition-compliant", "name": "composition_compliant", "description": "Whether current composition satisfies the declared profile at the evaluation instant.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Constraint values are inline on the team record; the authoritative profile document is the external typing definition or the charter artifact already registered under other findings." } ] }, { "id": "capability-and-qualification", "name": "Capability and qualification", "description": "Whether the collective holds the competences required, and whether those competences are currently valid.", "source_refs": [ "SRC-007", "SRC-008", "SRC-009", "SRC-010", "SRC-016", "SRC-017" ], "findings": [ { "id": "competence-coverage", "name": "Competence coverage", "description": "ESCO links each occupation to essential and optional knowledge, skills and competences with governed URIs built over ISCO-08; FEMA publishes skillsets that can be assembled into Position Task Books; ISO 30414 reports a skills and capabilities area; the Scrum Guide requires cross-functionality, meaning the team holds all skills needed to create value. Coverage is a set relation between required competences and those actually held by active members.", "source_refs": [ "SRC-008", "SRC-009", "SRC-010", "SRC-016" ], "questions": [ { "id": "q-required-competences", "text": "Which competences does the team's mandate require, expressed in which governed vocabulary?", "kind": "requirement", "answer_data": [ "Competence URI list", "Vocabulary and version", "Requirement level (essential or optional)" ] }, { "id": "q-coverage-gap", "text": "Which required competences are held by only one active member or by none?", "kind": "quality", "answer_data": [ "Single-point-of-failure competences", "Uncovered competences", "Assessment date" ] }, { "id": "q-evidence-of-skill", "text": "What evidence supports each claimed competence, and who assessed it?", "kind": "evidence", "answer_data": [ "Evidence type", "Assessor identity", "Assessment timestamp" ] }, { "id": "q-cross-functional", "text": "Can the team complete its expected functions without external hand-off, and if not, where does it depend on others?", "kind": "composition", "answer_data": [ "Self-sufficiency assessment", "Dependency points", "Mitigation" ] } ], "data_elements": [ { "id": "required-competence", "name": "required_competence_uri", "description": "Governed identifier of a competence the team must hold.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "competence-coverage-ratio", "name": "coverage_ratio", "description": "Proportion of required competences covered by at least one active member at the evaluation instant.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "bus-factor", "name": "single_holder_competences", "description": "Required competences held by exactly one active member.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-016" ] } ], "artifacts": [ { "id": "skill-matrix", "name": "Team competence coverage matrix", "description": "Dated matrix mapping required competence URIs to active members and evidence references.", "media_or_form": [ "matrix report", "structured record" ], "serial": true, "identity_strategy": "Team identifier plus evaluation instant; each edition immutable and superseded rather than edited.", "source_refs": [ "SRC-008", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "qualification-currency-and-credentials", "name": "Qualification currency and credentials", "description": "FEMA publishes job titles with position qualifications and Position Task Books, and its typing definitions carry per-position qualification codes; OSHA requires training before duty, at least annually for all brigade members and at least quarterly for interior structural firefighters, plus physician certification where fitness is in doubt. A credential held is not a credential current, and expiry must be modelled explicitly.", "source_refs": [ "SRC-007", "SRC-008", "SRC-017" ], "questions": [ { "id": "q-credential-required", "text": "Which licences, certifications or task-book completions are required for each role in this team?", "kind": "requirement", "answer_data": [ "Credential type", "Issuing authority", "Roles affected" ] }, { "id": "q-currency", "text": "When does each held credential expire, and what recurrence keeps it current?", "kind": "temporal", "answer_data": [ "Issue instant", "Expiry instant", "Recurrence interval" ] }, { "id": "q-lapsed", "text": "Which members are currently lapsed, and are they suspended from the affected duties?", "kind": "state", "answer_data": [ "Lapsed member references", "Affected duties", "Suspension decision and date" ] }, { "id": "q-verification", "text": "How is a credential verified against the issuing authority rather than self-asserted?", "kind": "validation", "answer_data": [ "Verification method", "Verification timestamp", "Verifier identity" ] } ], "data_elements": [ { "id": "credential-ref", "name": "credential_ref", "description": "Reference to a credential held by a member and relied on by this team.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-017" ] }, { "id": "credential-expiry", "name": "credential_expiry", "description": "Instant at which a relied-on credential ceases to be current.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-017" ] }, { "id": "currency-status", "name": "currency_status", "description": "Current, expiring, or lapsed against the required recurrence.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [ { "id": "position-task-book", "name": "Position qualification record or task book", "description": "The qualification sheet or task book evidencing that a member meets a position's requirements, with completion and currency dates.", "media_or_form": [ "qualification sheet", "task book", "training record" ], "serial": true, "identity_strategy": "Issuing-authority credential identifier where available; otherwise Dimension-minted identifier plus the member and position it evidences.", "source_refs": [ "SRC-008", "SRC-017" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "lifecycle-and-change", "name": "Lifecycle and structural change", "description": "How a team comes into being, changes state, mutates structurally and ends.", "rationale": "FHIR gives an explicit team status value set, W3C org gives ChangeEvent with originalOrganization and resultingOrganization, and schema.org gives founding and dissolution dates, so team change is directly modellable rather than inferred from diffs.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-011" ], "layers": [ { "id": "state-and-effective-time", "name": "State and effective time", "description": "The state machine of a team record and the time semantics that make its assertions checkable.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-005", "SRC-006" ], "findings": [ { "id": "team-status-lifecycle", "name": "Team status lifecycle", "description": "FHIR CareTeam.status is proposed, active, suspended, inactive or entered-in-error, and Group carries a modifier active flag. The entered-in-error value matters: it separates a team that ended from a team that never should have been recorded, which is an erasure-relevant distinction that a simple active boolean cannot express.", "source_refs": [ "SRC-002", "SRC-003" ], "questions": [ { "id": "q-status-now", "text": "What is the team's current status and since when?", "kind": "state", "answer_data": [ "Status code", "Status effective instant", "Prior status" ] }, { "id": "q-transitions", "text": "Which status transitions are permitted, and who may authorise each?", "kind": "lifecycle", "answer_data": [ "Allowed transition pairs", "Authorising role", "Required evidence" ] }, { "id": "q-error-vs-ended", "text": "How is an erroneously created team distinguished from one that ended normally?", "kind": "exception", "answer_data": [ "Error marking rule", "Downstream retraction obligations", "Notification list" ] }, { "id": "q-suspension", "text": "What does suspension mean operationally for memberships, access and obligations?", "kind": "process", "answer_data": [ "Effect on memberships", "Effect on entitlements", "Maximum suspension duration" ] } ], "data_elements": [ { "id": "team-status", "name": "status", "description": "Lifecycle status of the team record.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "status-changed-at", "name": "status_changed_at", "description": "Instant the current status took effect.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Status is inline state on the team record; the durable evidence of each transition is captured by the change-event artifact registered in the structural-change layer." }, { "id": "effective-dating-and-time-semantics", "name": "Effective dating and time semantics", "description": "RFC 3339 requires a full date, a full time with seconds and an explicit offset or Z, and reserves -00:00 for an unknown local offset. SCIM meta separates created from lastModified; PROV separates startedAtTime and endedAtTime on activities from generation of records. Event time (when the team changed) must be recorded separately from observation time (when the system learned of it).", "source_refs": [ "SRC-004", "SRC-005", "SRC-006" ], "questions": [ { "id": "q-event-vs-observation", "text": "For each assertion, when did the fact become true and when was it recorded?", "kind": "temporal", "answer_data": [ "Event instant (RFC 3339)", "Observation or ingestion instant", "Recording system" ] }, { "id": "q-offset", "text": "Is the local UTC offset known for each timestamp, or must -00:00 be used?", "kind": "temporal", "answer_data": [ "Offset value", "Known or unknown flag", "Governing time zone identifier" ] }, { "id": "q-open-intervals", "text": "How are open-ended and future-dated periods represented and queried as-of an instant?", "kind": "temporal", "answer_data": [ "Open-interval convention", "As-of query semantics", "Future-dating policy" ] }, { "id": "q-precision", "text": "What timestamp precision is required, and where is a date alone acceptable?", "kind": "constraint", "answer_data": [ "Required precision", "Fields permitting date-only values", "Rationale" ] } ], "data_elements": [ { "id": "event-time", "name": "event_time", "description": "RFC 3339 instant at which the asserted fact became true.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "observed-at", "name": "observed_at", "description": "RFC 3339 instant at which the fact was observed or ingested.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "validity-interval", "name": "validity_interval", "description": "Interval over which an assertion holds, with explicit open-end handling.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Time semantics are cross-cutting constraints on every record in the aggregate; they generate no artifact of their own but govern the timestamps carried by all other artifacts." } ] }, { "id": "structural-change-events", "name": "Structural change events", "description": "Formation, dissolution, merge, split and transfer expressed as first-class events.", "source_refs": [ "SRC-001", "SRC-006", "SRC-009", "SRC-011" ], "findings": [ { "id": "formation-and-dissolution", "name": "Formation and dissolution", "description": "schema.org supplies foundingDate and dissolutionDate; org:ChangeEvent records organizational change with resultedFrom links; FEMA's ordering specifications frame mobilization and demobilization preconditions. Formation and dissolution are events with their own authority, evidence and downstream obligations, not merely the endpoints of an interval.", "source_refs": [ "SRC-001", "SRC-007", "SRC-011" ], "questions": [ { "id": "q-formation-authority", "text": "Who authorised the team's formation and on what instrument?", "kind": "authority", "answer_data": [ "Authorising party", "Instrument reference", "Authorisation instant" ] }, { "id": "q-dissolution-trigger", "text": "What condition triggers dissolution, and is it time-based, objective-based or discretionary?", "kind": "lifecycle", "answer_data": [ "Trigger type", "Trigger condition", "Evaluation owner" ] }, { "id": "q-wind-down", "text": "On dissolution, where do open obligations, artifacts and members go?", "kind": "process", "answer_data": [ "Receiving team or unit", "Artifact custody transfer", "Member reassignment records" ] }, { "id": "q-access-revocation", "text": "What entitlements must be revoked on dissolution, and within what window?", "kind": "security", "answer_data": [ "Entitlement inventory", "Revocation deadline", "Revocation evidence" ] } ], "data_elements": [ { "id": "formed-at", "name": "formed_at", "description": "Instant the team came into existence.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-011" ] }, { "id": "dissolved-at", "name": "dissolved_at", "description": "Instant the team ceased to exist.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "successor-ref", "name": "successor_ref", "description": "Team or unit that inherits the dissolved team's obligations.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "lifecycle-event-record", "name": "Team lifecycle event record", "description": "Dated record of a formation or dissolution event with authorising instrument, effective instant and downstream obligations.", "media_or_form": [ "event record", "decision minute" ], "serial": true, "identity_strategy": "Event identifier plus event instant; events are append-only and never edited.", "source_refs": [ "SRC-001", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "merge-split-and-transfer-events", "name": "Merge, split and transfer events", "description": "org:ChangeEvent explicitly links originalOrganization to resultingOrganization so that reorganizations are traceable; PROV wasDerivedFrom carries the same lineage semantics for records; ISO 30414 adds guidance on when multi-unit entities consolidate or report separately, which determines whether merged teams keep separate metric histories.", "source_refs": [ "SRC-001", "SRC-006", "SRC-009" ], "questions": [ { "id": "q-change-lineage", "text": "Which predecessor teams produced this team, and which successors did it produce?", "kind": "provenance", "answer_data": [ "Original team references", "Resulting team references", "Change event reference" ] }, { "id": "q-continuity", "text": "Does the team retain its identifier through the change, or is a new identity minted?", "kind": "identity", "answer_data": [ "Identity continuity decision", "Rationale", "Superseded identifiers" ] }, { "id": "q-history-consolidation", "text": "Are historical metrics and memberships consolidated, split or left with the predecessor?", "kind": "decision", "answer_data": [ "Consolidation rule applied", "Affected metric series", "Restatement note" ] }, { "id": "q-transfer", "text": "When a team moves to a different parent unit, what changes and what must not?", "kind": "relationship", "answer_data": [ "New parent reference", "Preserved attributes", "Attributes requiring revalidation" ] } ], "data_elements": [ { "id": "change-event-type", "name": "change_event_type", "description": "Formation, merge, split, transfer, rename or dissolution.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "original-team-ref", "name": "original_team_ref", "description": "Predecessor team references for the change event.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "resulting-team-ref", "name": "resulting_team_ref", "description": "Successor team references for the change event.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "reorganization-record", "name": "Reorganization change record", "description": "Append-only record linking predecessor and successor teams, the authorising decision and the metric-continuity ruling.", "media_or_form": [ "event record", "structured lineage record" ], "serial": true, "identity_strategy": "Change event identifier plus effective instant; lineage edges are immutable once published.", "source_refs": [ "SRC-001", "SRC-006", "SRC-009" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "operations-and-performance", "name": "Operations and performance", "description": "How the team works with others, where and when it operates, and how its performance and conditions are evidenced.", "rationale": "W3C org supplies Site and linkedTo, ISO 30414 supplies the reporting frame for workforce metrics, and OSHA supplies binding duties on training and fitness, giving each of these a normative anchor rather than management convention.", "source_refs": [ "SRC-001", "SRC-002", "SRC-009", "SRC-017" ], "layers": [ { "id": "operating-model", "name": "Operating interfaces and footprint", "description": "External dependencies, contact routes, sites and time coverage.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005", "SRC-011" ], "findings": [ { "id": "interfaces-dependencies-and-collaborations", "name": "Interfaces, dependencies and collaborations", "description": "org:linkedTo relates organizations engaged in unspecified relationships and org:OrganizationalCollaboration models teams drawn from several organizations; CareTeam.telecom provides a central contact route for the team as a whole rather than for individuals. Dependencies between teams are typed edges with direction, criticality and an agreed interface.", "source_refs": [ "SRC-001", "SRC-002" ], "questions": [ { "id": "q-dependencies", "text": "Which other teams does this team depend on, and which depend on it?", "kind": "relationship", "answer_data": [ "Counterparty team reference", "Direction", "Criticality" ] }, { "id": "q-interface", "text": "Through what agreed interface and service expectation does each dependency operate?", "kind": "process", "answer_data": [ "Interface description", "Response expectation", "Agreement reference" ] }, { "id": "q-contact", "text": "What is the authoritative contact route for the team as a whole, distinct from any individual?", "kind": "interoperability", "answer_data": [ "Contact channel type", "Channel value", "Monitoring hours" ] }, { "id": "q-collaboration", "text": "Is the team part of a wider standing collaboration, and who convenes it?", "kind": "composition", "answer_data": [ "Collaboration reference", "Convening party", "Participating organizations" ] } ], "data_elements": [ { "id": "dependency-edge", "name": "dependency_edge", "description": "Typed directed edge to another team with criticality and interface reference.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "team-telecom", "name": "team_contact", "description": "Contact route attributed to the team rather than to a member.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "dependency-register", "name": "Team dependency register", "description": "Maintained register of inbound and outbound dependencies, their interfaces, criticality and agreements.", "media_or_form": [ "register", "structured record" ], "serial": true, "identity_strategy": "Team identifier plus register version; each edge carries its own validity interval.", "source_refs": [ "SRC-001", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "site-footprint-and-time-coverage", "name": "Site footprint and time coverage", "description": "org:Site with basedAt, hasSite, hasPrimarySite, hasRegisteredSite and siteAddress locates organizational activity; schema.org supplies location. Because RFC 3339 requires explicit offsets, a distributed team's coverage must be expressed with offsets or a named time zone, not local wall-clock text.", "source_refs": [ "SRC-001", "SRC-005", "SRC-011" ], "questions": [ { "id": "q-primary-site", "text": "Which site is primary for the team, and which secondary sites are in use?", "kind": "spatial", "answer_data": [ "Primary site reference", "Secondary site references", "Site address" ] }, { "id": "q-distribution", "text": "How is the team distributed across sites, jurisdictions and time zones?", "kind": "spatial", "answer_data": [ "Member-to-site distribution", "Jurisdictions represented", "Time zone identifiers" ] }, { "id": "q-jurisdiction-effect", "text": "Which obligations change because members sit in different jurisdictions?", "kind": "requirement", "answer_data": [ "Jurisdiction", "Divergent obligation", "Governing instrument" ] }, { "id": "site-footprint-and-time-coverage-q-coverage-gap", "text": "Are there hours in the required coverage window with no staffed member?", "kind": "validation", "answer_data": [ "Uncovered intervals with offsets", "Mitigation", "Assessment instant" ] } ], "data_elements": [ { "id": "primary-site-ref", "name": "primary_site_ref", "description": "Reference to the team's primary site.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "site-location", "name": "site_location", "description": "Geospatial or postal location of a site associated with the team.", "value_kind": "geometry", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-011" ] }, { "id": "time-zone-id", "name": "time_zone_identifier", "description": "Named time zone used to interpret the team's coverage windows.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Site records are owned by the organization model and referenced here; the team contributes only the assignment of members to those sites, which is inline on the membership record." } ] }, { "id": "measurement-and-evidence", "name": "Measurement, evidence and working conditions", "description": "What is measured about the team, on what evidence, and what duties protect the people in it.", "source_refs": [ "SRC-005", "SRC-006", "SRC-009", "SRC-017", "SRC-018" ], "findings": [ { "id": "team-level-metrics-binding", "name": "Team-level metrics binding", "description": "ISO 30414:2025 sets 11 human capital areas with 14 baseline required metrics, requires organizations to state their materiality interpretation, gives guidance on when multi-unit entities consolidate rather than report separately, and strengthens data governance and digital tagging. This model binds metrics to a team, a definition and an observation window; it does not restate formulae, and it must record that team-level granularity can breach both materiality and data minimisation.", "source_refs": [ "SRC-009", "SRC-018" ], "questions": [ { "id": "q-metric-definition", "text": "Which metric definition and version is being reported, and who owns it?", "kind": "measurement", "answer_data": [ "Metric identifier and version", "Definition source", "Definition owner" ] }, { "id": "q-observation-window", "text": "Over what window is each value measured, and at what instant was it computed?", "kind": "temporal", "answer_data": [ "Window start and end (RFC 3339)", "Computation instant", "Population basis" ] }, { "id": "q-consolidation", "text": "Is the value reported at team level, consolidated upward, or suppressed for materiality or re-identification risk?", "kind": "decision", "answer_data": [ "Reporting level", "Suppression decision and threshold", "Rationale" ] }, { "id": "q-restatement", "text": "How are values restated after a merge, split or definition change?", "kind": "quality", "answer_data": [ "Restatement policy", "Affected series", "Restatement note reference" ] } ], "data_elements": [ { "id": "metric-value", "name": "metric_value", "description": "Reported value for a named metric over a stated window.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "metric-definition-ref", "name": "metric_definition_ref", "description": "Versioned reference to the external metric definition.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "suppression-flag", "name": "suppressed_for_small_population", "description": "Whether the value is withheld because the team population is too small to publish safely.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] } ], "artifacts": [ { "id": "team-metric-report", "name": "Team metric report", "description": "Issued report carrying metric values, definitions, windows, materiality and suppression decisions.", "media_or_form": [ "report", "structured disclosure" ], "serial": true, "identity_strategy": "Team identifier plus reporting period and issue instant; reissues carry an explicit restatement link.", "source_refs": [ "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "evidence-quality-and-safety-duties", "name": "Evidence quality and health, safety and workload duties", "description": "PROV-O attributes every assertion to an agent through an activity, with qualifiedAssociation carrying hadRole and hadPlan; ISO 30414 moves human capital reporting toward auditable requirements and covers health, safety and wellbeing. OSHA imposes concrete recurring duties: training before duty, at least annually for all members and at least quarterly for interior structural firefighting, plus physician certification where a known condition is present.", "source_refs": [ "SRC-006", "SRC-009", "SRC-017" ], "questions": [ { "id": "q-attribution", "text": "Which agent asserted each team fact, acting on whose behalf and under what plan?", "kind": "provenance", "answer_data": [ "Asserting agent", "actedOnBehalfOf party", "Plan or procedure reference" ] }, { "id": "q-evidence-grade", "text": "Is each value system-derived, self-reported or audited, and what is its known error?", "kind": "quality", "answer_data": [ "Evidence grade", "Derivation method", "Known limitations" ] }, { "id": "q-safety-duty", "text": "Which recurring health, safety or training duties attach to this team, and are they current?", "kind": "requirement", "answer_data": [ "Duty description and interval", "Last completion instant", "Next due instant" ] }, { "id": "q-workload", "text": "What workload or exposure limits apply, and how are breaches detected and escalated?", "kind": "constraint", "answer_data": [ "Limit definition", "Detection mechanism", "Escalation path" ] }, { "id": "q-audit-readiness", "text": "What would an auditor need to reconstruct a reported team fact end to end?", "kind": "validation", "answer_data": [ "Required evidence chain", "Retention location", "Reconstruction procedure" ] } ], "data_elements": [ { "id": "assertion-agent", "name": "asserted_by", "description": "Agent responsible for an assertion about the team.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "evidence-grade", "name": "evidence_grade", "description": "System-derived, self-reported, verified or audited.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-009" ] }, { "id": "safety-duty-due", "name": "safety_duty_next_due", "description": "Instant at which a recurring safety or training duty next falls due.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [ { "id": "training-and-safety-record", "name": "Training, fitness and safety compliance record", "description": "Dated evidence of recurring training, education sessions and fitness certifications required for the team's duties.", "media_or_form": [ "training record", "certification record" ], "serial": true, "identity_strategy": "Member and duty identifiers plus completion instant; records are append-only and support currency computation.", "source_refs": [ "SRC-017" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "governance-and-interoperability", "name": "Record governance and interoperability", "description": "How the team record itself is provenanced, protected, retained and projected to other systems.", "rationale": "Team records are almost entirely personal data about identifiable workers, so GDPR principles and NIST access controls govern them, while SCIM, FHIR, schema.org and the W3C org ontology define the projections that other systems expect.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-014", "SRC-018" ], "layers": [ { "id": "provenance-access-retention", "name": "Provenance, access and retention", "description": "Custody, disclosure scope and disposal of team records.", "source_refs": [ "SRC-004", "SRC-006", "SRC-014", "SRC-018" ], "findings": [ { "id": "record-provenance-and-artifacts", "name": "Record provenance and artifact integrity", "description": "SCIM meta carries created, lastModified, location and a version usable for optimistic concurrency; PROV-O supplies wasGeneratedBy, wasAttributedTo and wasDerivedFrom; FEMA publishes each definition with a version, original release date and last-updated date. Every artifact in this aggregate carries an integrity value and a supersession link rather than being edited in place.", "source_refs": [ "SRC-004", "SRC-006", "SRC-007" ], "questions": [ { "id": "q-record-origin", "text": "Which system generated each record, and from which upstream record was it derived?", "kind": "provenance", "answer_data": [ "Generating system", "Upstream record reference", "Derivation activity" ] }, { "id": "q-version-control", "text": "How is concurrent modification detected and rejected?", "kind": "validation", "answer_data": [ "Version or ETag value", "Concurrency rule", "Conflict handling" ] }, { "id": "q-integrity", "text": "What integrity value proves an artifact has not changed since issue?", "kind": "evidence", "answer_data": [ "Digest algorithm", "Digest value", "Computation instant" ] }, { "id": "q-supersession", "text": "When a record is corrected, how is the superseded version preserved and located?", "kind": "provenance", "answer_data": [ "Superseded version identifier", "Supersession reason", "Retention location" ] } ], "data_elements": [ { "id": "record-created-at", "name": "record_created_at", "description": "Instant the record was created in the governing store.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "record-version", "name": "record_version", "description": "Opaque version value used for concurrency control and supersession.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "content-digest", "name": "content_digest", "description": "Algorithm-qualified digest of an issued artifact.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "provenance-ledger", "name": "Team record provenance ledger", "description": "Append-only ledger of generation, derivation, attribution and supersession events for every artifact in the aggregate.", "media_or_form": [ "append-only ledger", "structured record" ], "serial": true, "identity_strategy": "Ledger entry identifier plus recording instant; entries reference the artifact identifier and version they describe.", "source_refs": [ "SRC-004", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "access-privacy-and-retention", "name": "Access scope, privacy and retention", "description": "The European Commission states the GDPR principles of purpose limitation, data minimisation, accuracy, storage limitation for the shortest time possible, integrity and confidentiality, and accountability, and notes longer retention is possible for archiving or research with safeguards such as anonymisation. NIST SP 800-53 Access Control and Personnel Security families govern provisioning, least privilege and revocation on transfer or termination. FHIR assigns CareTeam the Patient security category and Group the Business category, showing that team records inherit sensitivity from their members.", "source_refs": [ "SRC-002", "SRC-003", "SRC-014", "SRC-018" ], "questions": [ { "id": "q-default-visibility", "text": "What is the default visibility of the team record, and which elements are more restricted?", "kind": "access", "answer_data": [ "Default scope", "Restricted element list", "Restriction basis" ] }, { "id": "q-purpose-limitation", "text": "For what declared purpose is each personal element held, and what use is out of scope?", "kind": "privacy", "answer_data": [ "Declared purpose", "Lawful basis", "Prohibited secondary uses" ] }, { "id": "q-retention-period", "text": "How long is each class of team record retained, and what starts the clock?", "kind": "retention", "answer_data": [ "Record class", "Retention period", "Retention trigger event" ] }, { "id": "q-erasure", "text": "On erasure or objection, which elements are deleted, which anonymised and which must be kept?", "kind": "exception", "answer_data": [ "Deletable elements", "Anonymisation method", "Overriding legal obligation" ] }, { "id": "q-revocation", "text": "When a membership ends, within what window are entitlements revoked and how is that evidenced?", "kind": "security", "answer_data": [ "Revocation deadline", "Systems in scope", "Revocation evidence reference" ] } ], "data_elements": [ { "id": "sensitivity-class", "name": "sensitivity_class", "description": "Sensitivity classification inherited from the members and content of the record.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "retention-period", "name": "retention_period", "description": "Retention duration for a record class, with its triggering event.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "legal-hold", "name": "legal_hold", "description": "Whether disposal is suspended by a legal hold, with its authority and expiry.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] } ], "artifacts": [ { "id": "disposition-record", "name": "Access and disposition record", "description": "Record of access decisions, disclosures, retention schedules applied and disposal or anonymisation actions taken.", "media_or_form": [ "audit log", "disposition certificate" ], "serial": true, "identity_strategy": "Decision or disposal identifier plus action instant; entries are immutable and retained beyond the data they describe.", "source_refs": [ "SRC-014", "SRC-018" ] } ], "inline_only_rationale": null }, { "id": "visibility-discoverability-and-sensitivity", "name": "Visibility, privacy and sensitivity", "description": "GitHub contrasts visible and secret teams, with API values secret and closed; secret teams cannot nest and still leak their name if @mentioned. Microsoft visibility defaults to Public and classification must match a tenant-preconfigured sensitivity label. People outside the organization cannot view GitHub teams.", "source_refs": [ "SRC-020", "SRC-021", "SRC-025" ], "questions": [ { "id": "visibility-discoverability-and-sensitivity-q01", "text": "What is the visibility or privacy class of the team, and which vocabulary is in use: GitHub secret or closed, GitHub visible or secret, or Microsoft Public or Private?", "kind": "access", "answer_data": [ "visibility_code", "visibility_vocabulary" ] }, { "id": "visibility-discoverability-and-sensitivity-q02", "text": "What sensitivity or business-data classification applies, and does it match a preconfigured directory label?", "kind": "security", "answer_data": [ "classification_label", "directory_label_set" ] }, { "id": "visibility-discoverability-and-sensitivity-q03", "text": "Who can discover, view or @mention the team, and does a mention of a secret team reveal its name?", "kind": "access", "answer_data": [ "discoverability_audience", "mention_leak_rule" ] }, { "id": "visibility-discoverability-and-sensitivity-q04", "text": "What privacy duty applies when distributing membership lists across provisioning domains, as SCIM warns?", "kind": "privacy", "answer_data": [ "privacy_agreement_ref", "cross_domain_propagation_rule" ] } ], "data_elements": [ { "id": "visibility-discoverability-and-sensitivity-data01", "name": "Visibility code", "description": "Privacy or visibility class of the team.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-021", "SRC-025" ] }, { "id": "visibility-discoverability-and-sensitivity-data02", "name": "Sensitivity classification", "description": "Tenant directory sensitivity label or equivalent.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021" ] }, { "id": "visibility-discoverability-and-sensitivity-data03", "name": "Discoverability audience", "description": "Who may find the team in search or mention it.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021", "SRC-025" ] } ], "artifacts": [], "inline_only_rationale": "Visibility and sensitivity are coded policy fields on the team record." }, { "id": "team-entitlements-and-member-capabilities", "name": "Entitlements and member capabilities", "description": "Teams hold permissions on resources such as repositories, inherit child-team access from parents, and expose member, guest and messaging capability settings. Entitlements are relationships to resources, not the team itself.", "source_refs": [ "SRC-020", "SRC-021", "SRC-022", "SRC-025" ], "questions": [ { "id": "team-entitlements-and-member-capabilities-q01", "text": "Which resources can the team access, at what permission level, and are those entitlements inherited by child teams?", "kind": "access", "answer_data": [ "resource_id", "permission_level", "inherited_by_children" ] }, { "id": "team-entitlements-and-member-capabilities-q02", "text": "What may ordinary members create, update or delete inside the team, such as channels, apps, tabs or connectors?", "kind": "access", "answer_data": [ "member_capability_settings" ] }, { "id": "team-entitlements-and-member-capabilities-q03", "text": "What may guests do, and how does that differ from member and owner capabilities?", "kind": "access", "answer_data": [ "guest_capability_settings" ] }, { "id": "team-entitlements-and-member-capabilities-q04", "text": "What exception grants a person or child team broader access than the team default, and who authorized it?", "kind": "exception", "answer_data": [ "access_exception", "exception_authority" ] } ], "data_elements": [ { "id": "team-entitlements-and-member-capabilities-data01", "name": "Team entitlements", "description": "Permissions the team holds on repositories or other resources.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-020", "SRC-025" ] }, { "id": "team-entitlements-and-member-capabilities-data02", "name": "Member capability settings", "description": "Settings for whether members may create channels, add apps and similar actions.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021" ] }, { "id": "team-entitlements-and-member-capabilities-data03", "name": "Guest capability settings", "description": "Settings for guest actions inside the team.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021" ] } ], "artifacts": [ { "id": "team-entitlements-and-member-capabilities-artifact01", "name": "Team entitlement grant", "description": "Grant of a permission on a resource to the team, including inheritance notes.", "media_or_form": [ "canonical record", "access-control list" ], "serial": true, "identity_strategy": "Resource master identifier plus team identifier plus grant identifier", "source_refs": [ "SRC-020", "SRC-025" ] } ], "inline_only_rationale": null } ] }, { "id": "interoperability-and-alignment", "name": "Interoperability and alignment", "description": "Projections to external schemas and the limits of any conformance claim.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-010", "SRC-011", "SRC-012", "SRC-013" ], "findings": [ { "id": "external-system-mappings-and-conformance", "name": "External mappings and conformance claims", "description": "A team can project to org:OrganizationalUnit or org:OrganizationalCollaboration, to a SCIM Group, to a FHIR CareTeam or Group, to schema.org Organization with OrganizationRole, and to HR Open OrganizationChart units and positions. None of these is lossless: SCIM lacks mandate and lifecycle, FHIR CareTeam is subject-scoped, HR Open ships no Team noun at all, and FHIR Group deliberately denotes an undifferentiated collection. Conformance must be claimed per profile with evidence, never asserted globally.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-011", "SRC-012", "SRC-013" ], "questions": [ { "id": "q-target-profiles", "text": "Which external profiles must this team be projected into, and at which versions?", "kind": "interoperability", "answer_data": [ "Target profile identifier", "Profile version", "Projection direction" ] }, { "id": "q-lossy-fields", "text": "Which fields are lost or distorted in each projection, and how is the loss disclosed?", "kind": "quality", "answer_data": [ "Lost element list", "Distortion description", "Disclosure mechanism" ] }, { "id": "q-conformance-evidence", "text": "What evidence supports a conformance claim against a given profile?", "kind": "evidence", "answer_data": [ "Validation tool and version", "Validation result", "Validation instant" ] }, { "id": "q-round-trip", "text": "Can a projection be reimported without losing identity or membership history?", "kind": "validation", "answer_data": [ "Round-trip test result", "Non-recoverable elements", "Mitigation" ] } ], "data_elements": [ { "id": "projection-profile", "name": "projection_profile", "description": "Named external profile and version a projection targets.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "mapping-rule", "name": "mapping_rule", "description": "Element-level mapping from this model to a target profile, including unmapped elements.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-011" ] }, { "id": "conformance-claim", "name": "conformance_claim", "description": "Scoped claim of conformance to a profile, with supporting validation evidence.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-012" ] } ], "artifacts": [ { "id": "mapping-specification", "name": "Projection and mapping specification", "description": "Versioned specification of element mappings to each target profile, with an explicit unmapped-element list and validation results.", "media_or_form": [ "mapping specification", "structured crosswalk" ], "serial": true, "identity_strategy": "Source model version plus target profile identifier and version.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-011" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "resolve-team-identity", "name": "Resolve team identity", "description": "Determine the canonical identifier for a team, applying the identity priority order and minting only when no authoritative or governed identifier exists.", "inputs": [ "Candidate identifiers with issuing system URIs", "Containing organization reference", "Boundary class declaration" ], "outputs": [ "Canonical team_id", "Identity resolution record with priority tier applied" ], "preconditions": [ "Containing organization is resolvable", "Boundary class is declared and is not a non-team cohort" ], "effects": [ "Canonical identifier bound and published", "Alternate identifiers recorded as system-qualified correlations" ], "source_refs": [ "SRC-002", "SRC-004", "SRC-015" ] }, { "id": "assert-membership", "name": "Assert membership", "description": "Create a time-bounded membership assignment binding an agent to the team in one or more roles, optionally on behalf of another organization.", "inputs": [ "Member reference", "In-team role codes", "Start instant (RFC 3339)", "Optional position reference and onBehalfOf organization" ], "outputs": [ "Membership assignment record", "Updated active-member set as of the start instant" ], "preconditions": [ "Team status permits membership changes", "Writing system holds membership write authority", "Start instant carries an explicit offset or Z" ], "effects": [ "Membership fact appended with event and observation times", "Composition and qualification validation triggered" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-005" ] }, { "id": "end-membership", "name": "End membership", "description": "Close a membership by setting its end instant and inactive flag, preserving the historical assertion rather than deleting it.", "inputs": [ "Membership identifier", "End instant", "Reason code" ], "outputs": [ "Closed membership record", "Entitlement revocation task list" ], "preconditions": [ "Membership exists and is currently open", "End instant is not earlier than the start instant" ], "effects": [ "Membership marked inactive with a closed interval", "Access revocation obligations raised with a deadline" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-014" ] }, { "id": "validate-composition", "name": "Validate composition and qualification", "description": "Evaluate current membership against the declared constraint profile, capability tier and credential currency requirements as of a given instant.", "inputs": [ "Team identifier", "Evaluation instant", "Constraint profile reference" ], "outputs": [ "Compliance verdict", "Enumerated shortfalls by role, competence and credential" ], "preconditions": [ "A constraint profile is declared", "Membership records carry validity intervals" ], "effects": [ "Compliance state recorded with the evaluation instant", "Non-compliance escalated to the accountable owner" ], "source_refs": [ "SRC-007", "SRC-016", "SRC-017" ] }, { "id": "transition-team-state", "name": "Transition team state", "description": "Move the team between proposed, active, suspended, inactive and entered-in-error, enforcing permitted transitions and authorisation.", "inputs": [ "Target status", "Effective instant", "Authorising party" ], "outputs": [ "Updated status with effective instant", "Transition event record" ], "preconditions": [ "Transition is permitted from the current status", "Authorising party holds the delegated right" ], "effects": [ "Status changed and downstream obligations raised", "Erroneous records marked entered-in-error rather than deleted" ], "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "record-structural-change", "name": "Record structural change", "description": "Register a formation, merge, split, transfer, rename or dissolution as an append-only change event linking predecessor and successor teams.", "inputs": [ "Change event type", "Original and resulting team references", "Effective instant", "Authorising instrument" ], "outputs": [ "Change event record with lineage edges", "Identity continuity ruling" ], "preconditions": [ "All referenced teams resolve", "Effective instant is supplied with an explicit offset" ], "effects": [ "Lineage published and immutable", "Metric continuity and consolidation decision recorded" ], "source_refs": [ "SRC-001", "SRC-006", "SRC-009" ] }, { "id": "compute-team-metrics", "name": "Compute team metrics", "description": "Compute or ingest team-level metric values bound to a versioned definition and an observation window, applying suppression where the population is too small.", "inputs": [ "Metric definition reference and version", "Observation window", "Population basis" ], "outputs": [ "Metric values with computation instant", "Suppression and materiality decisions" ], "preconditions": [ "Metric definition is versioned and resolvable", "Underlying membership and allocation data cover the window" ], "effects": [ "Metric report issued and immutable", "Re-identification risk assessed before publication" ], "source_refs": [ "SRC-009", "SRC-018" ] }, { "id": "evaluate-access-request", "name": "Evaluate access request", "description": "Decide what portion of the team record a requester may see, applying least privilege, purpose limitation and the record's sensitivity class.", "inputs": [ "Requester identity and role", "Requested scope", "Declared purpose" ], "outputs": [ "Access decision with permitted scope", "Audit entry" ], "preconditions": [ "Sensitivity class is set", "Declared purpose is compatible with the collection purpose" ], "effects": [ "Decision enforced and logged", "Denials recorded with reason for later review" ], "source_refs": [ "SRC-014", "SRC-018" ] }, { "id": "apply-retention-policy", "name": "Apply retention and disposal", "description": "Apply the retention schedule to each class of team record, honouring legal holds and preferring anonymisation over deletion where history must be preserved.", "inputs": [ "Record class", "Retention schedule", "Legal hold status" ], "outputs": [ "Disposal or anonymisation actions", "Disposition certificate" ], "preconditions": [ "Retention trigger event has occurred", "No active legal hold applies" ], "effects": [ "Personal elements disposed or anonymised", "Disposition evidence retained beyond the disposed data" ], "source_refs": [ "SRC-018" ] }, { "id": "export-alignment-projection", "name": "Export alignment projection", "description": "Emit the team as a named external profile such as W3C org, SCIM Group, FHIR CareTeam or schema.org Organization, disclosing every unmapped element.", "inputs": [ "Target profile and version", "Scope filter", "As-of instant" ], "outputs": [ "Projected representation", "Loss report listing unmapped elements" ], "preconditions": [ "A versioned mapping specification exists for the target profile", "Access decision permits the requested scope" ], "effects": [ "Projection issued with an explicit as-of instant", "Conformance claim limited to the validated profile" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-011" ] }, { "id": "verify-tier-claim", "name": "Verify capability tier claim", "description": "Test a claimed capability tier against the referenced typing definition, recording verifier identity, method and result.", "inputs": [ "Claimed tier", "Typing definition reference and version", "Current roster and equipment inventory" ], "outputs": [ "Verification result", "Shortfall list with compensating measures" ], "preconditions": [ "Typing definition is published and resolvable", "Roster snapshot exists for the verification instant" ], "effects": [ "Tier claim marked verified or withdrawn", "Verification timestamp recorded for currency tracking" ], "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "attach-post-and-assign-holder", "name": "Compose via post", "description": "Attach a reusable post to the team and optionally assign a holder for an interval, without creating the post definition.", "inputs": [ "team identity", "post identity from WM-ORG-004", "optional holder and assignment interval" ], "outputs": [ "team-post link", "optional assignment" ], "preconditions": [ "Referenced post exists in the Position model", "Assignment interval uses RFC 3339 timestamps if present" ], "effects": [ "Team composition includes the post even if vacant", "Holder may become an ex-officio member" ], "source_refs": [ "SRC-001" ] }, { "id": "nest-or-reparent-team", "name": "Nest or reparent team", "description": "Set, change or clear a parent team, or split an oversized team into sibling teams sharing a goal.", "inputs": [ "child team identity", "optional new parent team identity", "optional split plan" ], "outputs": [ "updated hierarchy", "optional new sibling team identities" ], "preconditions": [ "Secret or Scrum profiles are not asked to nest", "New parent is not a descendant of the child", "Actors have maintainer or owner rights on both teams when required" ], "effects": [ "Child inherits parent entitlements where the platform so defines", "Direct versus inherited membership listings change", "A Scrum-style split shares Product Goal rather than creating hierarchy" ], "source_refs": [ "SRC-016", "SRC-025" ] }, { "id": "grant-team-entitlement", "name": "Grant team entitlement", "description": "Grant, inherit or revoke a permission held by the team on a resource.", "inputs": [ "team identity", "resource identity", "permission level" ], "outputs": [ "entitlement grant" ], "preconditions": [ "Actor may manage access on the resource", "Child-team inheritance implications have been reviewed" ], "effects": [ "Team members and, where defined, child-team members gain or lose resource access" ], "source_refs": [ "SRC-020", "SRC-025" ] }, { "id": "provision-from-external-group", "name": "Provision from external group", "description": "Create or update a Team from a SCIM Group or identity-provider group, or bind an existing team to that group.", "inputs": [ "SCIM or IdP group identity", "target organization", "optional team identity" ], "outputs": [ "team identity", "sync binding" ], "preconditions": [ "Group displayName and members are available", "Privacy agreements for cross-domain personal data have been considered" ], "effects": [ "Team membership is sourced from the external group", "Local membership writes may be blocked" ], "source_refs": [ "SRC-022", "SRC-026" ] }, { "id": "resolve-effective-members", "name": "Resolve effective members", "description": "Compute the effective member set, distinguishing direct, inherited, guest, role-only and nested-group members at an observation time.", "inputs": [ "team identity", "observation time", "inclusion flags for inherited guests and nested groups" ], "outputs": [ "effective member list", "counts by role or kind" ], "preconditions": [ "Caller may read membership of the team" ], "effects": [ "No write; returns an observation of membership at the stated time" ], "source_refs": [ "SRC-019", "SRC-021", "SRC-026" ] } ], "composition": [ { "target": "WM-ORG-001 (Organization)", "relation": "REFERENCE", "purpose": "Every team instance resolves to exactly one containing organization context that supplies legal recognition, obligations and the formal-organization frame; the Team model never restates legal-entity attributes.", "required": true, "source_refs": [ "SRC-001", "SRC-003", "SRC-015" ] }, { "target": "WM-ORG-004 (Position)", "relation": "COMPOSE", "purpose": "Team composition is expressed through reusable positions and their assignments; org:Post remains defined once and is bound to the team through membership records rather than copied into the team.", "required": true, "source_refs": [ "SRC-001", "SRC-012" ] }, { "target": "Membership assignment record (nested record type owned by WM-ORG-003)", "relation": "CHILD", "purpose": "The n-ary membership fact is governed inside this aggregate because it carries the team-specific role, period and allocation that no sibling model owns.", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "Person / Worker context model (target model id not yet registered in the vr registry)", "relation": "REFERENCE", "purpose": "Members are referenced, never embedded; personal master data, contract terms and pay remain with the person and employment models to satisfy data minimisation.", "required": true, "source_refs": [ "SRC-004", "SRC-018" ] }, { "target": "Provenance mix-in aligned to W3C PROV-O", "relation": "MIX-IN", "purpose": "Supplies generation, attribution, derivation and qualified-association semantics to every record in the aggregate without duplicating provenance structure per finding.", "required": true, "source_refs": [ "SRC-006" ] }, { "target": "W3C Organization Ontology (org:OrganizationalUnit, org:Membership, org:Post, org:ChangeEvent)", "relation": "ALIGN", "purpose": "Primary structural alignment for units, n-ary membership with memberDuring, posts, sites and change events; alignment only, no conformance claimed.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "HL7 FHIR R5 CareTeam and Group", "relation": "ALIGN", "purpose": "Alignment for team status lifecycle, participant role and coverage, managing organization, and the enumerated-versus-definitional membership distinction.", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "target": "IETF RFC 7643 SCIM Group", "relation": "ALIGN", "purpose": "Alignment for identity-provider projection: immutable server id, externalId, meta versioning and the rule that membership is written through the Group resource.", "required": false, "source_refs": [ "SRC-004" ] }, { "target": "schema.org Organization and OrganizationRole", "relation": "ALIGN", "purpose": "Publication projection for externally visible teams, including time-qualified roles and founding or dissolution dates; only where the team has a genuine public presence.", "required": false, "source_refs": [ "SRC-011" ] }, { "target": "ESCO v1.2.1 and ISCO-08 occupation and skill URIs", "relation": "ALIGN", "purpose": "Governed vocabulary for occupations and competences so that capability coverage is expressed in external identifiers rather than local strings.", "required": false, "source_refs": [ "SRC-010" ] }, { "target": "ISO 30414:2025 human capital reporting", "relation": "ALIGN", "purpose": "Reference frame for metric definitions, materiality declaration and consolidation of multi-unit reporting; metric formulae are cited, not restated.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "FEMA NIMS resource typing definitions and National Qualification System", "relation": "ALIGN", "purpose": "Reference frame for capability tiering, minimum composition, position qualification and task-book evidence for operationally deployable teams.", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "target": "HR Open Standards 4.5R OrganizationChart and Timecard domains", "relation": "ALIGN", "purpose": "Interchange alignment for units, positions and incumbents and for the worker time data underlying allocation; note that no Team noun exists in the suite.", "required": false, "source_refs": [ "SRC-012", "SRC-013" ] }, { "target": "Subject-scoped care team profile (FHIR CareTeam-aligned specialization)", "relation": "EXTEND", "purpose": "Specialization for teams bound to a specific subject, adding subject reference and the elevated sensitivity handling that entails.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "Typed emergency response team profile (NIMS-aligned specialization)", "relation": "EXTEND", "purpose": "Specialization adding mobilization state, ordering specifications, equipment inventory and deployment tracking for typed deployable teams.", "required": false, "source_refs": [ "SRC-007" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must name a single accountable owner for the Team model package and record that owner as a resolvable party reference, not a free-text name.", "The Dimension must publish the identifier-minting policy it uses when no authoritative master-system key exists, including whether UUID or ULID is used and who may mint.", "The Dimension must declare which constraint profile (regulatory, contractual or methodological) governs composition for each team category it operates, since these profiles conflict.", "The Dimension must register the retention schedule and lawful basis for team membership data before any instance is created." ], "namespace_guidance": "Team instance IRIs live in a Dimension-controlled namespace segregated from person and organization namespaces so that a team identifier can never be mistaken for a legal-entity identifier; external identifiers from HRIS, IdP or typing catalogues are carried as system-qualified pairs and never rewritten into the local namespace.", "registry_links": [ "vr.wm-org-003 (this model) as the governing registry entry", "WM-ORG-001 for the containing organization context and WM-ORG-004 for reusable positions", "External governed registries referenced by URI: ESCO/ISCO-08 occupations and skills, FEMA RTLT typing definitions and position qualifications, GLEIF LEI for the containing legal entity only" ] }, "canon_and_patch": { "canonicalization_rules": [ "All instants are canonicalized to RFC 3339 with seconds and an explicit offset or Z; -00:00 is reserved for a known UTC time with an unknown local offset and must not be written as +00:00.", "Membership sets are canonicalized as ordered lists of membership identifiers sorted by start instant then membership identifier, so that a set with unchanged content always yields an identical digest.", "Codes are canonicalized as scheme URI plus code value; bare display labels are never canonical.", "Open-ended intervals are canonicalized by omitting the end value rather than by writing a sentinel far-future date." ], "patch_rules": [ "Membership facts are append-only: a correction creates a new record that supersedes the prior one and cites the reason, and the superseded record remains retrievable.", "Status changes are applied through the state-transition function only, never by direct field assignment, so that every transition produces an event record.", "Patches carry the record version they were computed against and are rejected on version mismatch rather than merged.", "Deletion is reserved for the entered-in-error case and for lawful erasure; ordinary endings are expressed by closing an interval." ], "compatibility_rules": [ "Adding an optional element or a new code to an open scheme is a minor change; narrowing cardinality, removing an element or closing a scheme is a breaking change.", "Changing the identity priority order or the canonical timestamp rule is always breaking and requires a new major version with a migration note.", "External alignments may be added freely, but changing an existing mapping's target element is breaking for any consumer relying on the projection.", "Conformance claims are scoped to a named profile version and expire when either this model or the target profile issues a major version." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier from the system of record for the artifact (for example an HRIS assignment key, an IdP group id, or a publisher's typing definition identifier with version)", "Governed global identifier or IRI issued under a recognized scheme or the Dimension's registered namespace", "UUID or ULID minted by the adopting Dimension, recorded together with its minting authority and instant" ], "timestamp_rule": "All artifact timestamps use RFC 3339 with seconds and an explicit UTC offset or Z; event time and observation or ingestion time are recorded as separate fields, and -00:00 is used only when the local offset is genuinely unknown.", "serial_naming_rule": "Serial artifacts are named by their stable artifact identifier plus a monotonically increasing version or the issue instant, for example charter/{team_id}/v{n} or roster/{team_id}/{issue_instant}; a superseded serial is never renamed or overwritten and always carries a forward link to its successor.", "integrity_rule": "Every issued artifact carries an algorithm-qualified content digest and the record version it was generated from; consumers must verify the digest before relying on the artifact, and any artifact whose digest cannot be verified is treated as unevidenced." }, "policies": [ "Personal data minimisation: the team record holds references to members and the team-specific facts about them, and never a copy of person master data, contract terms or pay.", "Small-population suppression: team-level metrics are suppressed or consolidated upward when the population is small enough that a value could identify an individual.", "No global conformance: alignment to an external standard is recorded per profile and per version with validation evidence, and is never asserted for the model as a whole.", "Append-only history: membership, status and structural change are never edited in place, so that any as-of query can be answered from the record itself.", "Revocation on ending: closing a membership raises a bounded entitlement-revocation obligation whose completion must be evidenced.", "Default deny read of secret or private team membership to non-members and non-owners; visible workplace teams may be listed to organization members according to the host directory.", "Membership lists are personal data when they identify persons; cross-domain SCIM or IdP propagation requires a recorded privacy agreement.", "Do not claim FHIR, SCIM, ORG or Scrum conformance unless a named profile and evidence are attached to the instance.", "Nested entitlement inheritance must be audited before a parent-child link is created, because child teams inherit parent resource permissions in GitHub-like systems." ], "crud": { "read": [ "Read the team record as-of a supplied instant, defaulting to now, with membership resolved to those active at that instant.", "Read a projection into a named external profile, accompanied by the loss report for unmapped elements.", "Read the lineage of a team across merges, splits and transfers in both directions.", "Read metric values only together with their definition version, observation window and suppression decision." ], "create": [ "Create a team only after boundary class, containing organization, purpose and expected functions are supplied.", "Mint the identifier through the identity-resolution function so the applied priority tier is recorded.", "Create the charter artifact in the same transaction as the team record where a written constituting statement is legally required.", "Reject creation of records whose membership basis is definitional rather than enumerated; those are cohorts, not teams." ], "update": [ "Update membership only through the assert and end functions, never by replacing a member array.", "Update status only through the state-transition function with an authorising party and effective instant.", "Update classification and capability tier only with a reference to the scheme or typing definition version relied on.", "Every update records both the event instant and the observation instant, plus the asserting agent." ], "delete": [ "Ordinary endings are recorded by closing intervals and setting inactive, not by deletion.", "Records created in error are marked entered-in-error and retained, with downstream consumers notified to retract.", "Lawful erasure removes or anonymises the personal elements while retaining the non-personal structural skeleton and the disposition evidence.", "Deletion is blocked while a legal hold is active, and the block is itself logged." ] }, "roles": [ { "name": "Model steward", "responsibilities": [ "Owns the Team model package, its versioning and its compatibility rulings", "Approves changes to identity priority, canonicalization and constraint profiles", "Maintains the register of external alignments and their validated versions" ] }, { "name": "Team data owner", "responsibilities": [ "Accountable for the correctness of a team's charter, classification and reporting line", "Approves formation, structural change and dissolution records", "Resolves conflicts between HR-side and identity-provider-side membership writes" ] }, { "name": "Membership administrator", "responsibilities": [ "Creates and closes membership assignments within the authoritative write path", "Ensures start and end instants carry explicit offsets and correct event versus observation times", "Initiates entitlement revocation when a membership ends" ] }, { "name": "Compliance and privacy officer", "responsibilities": [ "Sets the lawful basis, retention schedule and suppression thresholds for team records", "Reviews access denials, disclosures and erasure requests", "Signs off metric publication where re-identification risk exists" ] }, { "name": "Qualification verifier", "responsibilities": [ "Verifies credential and task-book evidence against issuing authorities rather than self-assertion", "Maintains currency status and raises lapses that suspend affected duties", "Verifies capability tier claims against the referenced typing definition" ] } ], "access": { "default_rule": "Default deny with least privilege: the existence, name, purpose and accountable owner of a team are readable within the containing organization, while membership detail, allocations, credentials, safety records and metric values require an explicit grant tied to a declared purpose.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Members may always read their own membership record and the credentials attributed to them.", "Safety and emergency-response duties may require immediate broad disclosure of roster and qualification data, logged as a break-glass event with post-hoc review.", "Regulators and auditors receive scoped, time-boxed access to charter, qualification and disposition evidence without access to unrelated personal elements.", "External participants receive only the scope defined in their participation agreement and never see other members' credentials or metrics.", "Break-glass clinical or security access to a CareTeam or secret team must be time-bounded, logged and tied to a named incident", "IdP administrators may mutate membership in the identity provider even when the Team API rejects local writes", "Public sports-team facts such as name, sport and listed athletes may be published without implying access to workplace membership rosters" ], "audit_requirements": [ "Every access decision records requester, requested scope, declared purpose, decision, permitted scope and instant.", "Break-glass access triggers mandatory review by the compliance and privacy officer within a defined window.", "Disclosures to parties outside the containing organization are logged with the recipient and the agreement relied on.", "Audit entries are immutable and retained beyond the retention period of the data they describe.", "Log create, membership add and remove, parent change, entitlement grant, archive, unarchive, clone and delete with actor, event time and observation time", "Log IdP-sync failures and rejected local writes", "Retain audit records at least as long as the team membership history retention period" ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Registry ID", "Model Version" ], "read_order": [ "AGENTS.md first, to obtain Name, Type, Specification URL, Storage type URL, Interface URL, Processes URL, Registry ID and Model Version before any read or write", "The Specification URL, to load scope, boundary notes and the identity priority order", "The Storage type URL, to learn the concrete projection in use (file tree, Git, MongoDB collection or MCP resource) without treating it as semantics", "The Interface URL, to discover the available functions and their preconditions", "The Processes URL, to learn the approval, validation and audit steps required before any create, update or delete" ] } }, "coverage": { "claim": "Merged model covers Team as an aggregate rooted on the team node with n-ary membership-assignment records governed inside it: identity, naming and boundary against organization, position, group and rule-defined cohort; classification and capability tier; charter, mandate and decision rights; membership including nesting, inherited members, post establishment, external and non-human participants and provisioning pipelines; capacity, minimum composition, competence and credential currency; status and structural-change lifecycle; operating interfaces and site footprint; metric binding; and record governance covering provenance, visibility, entitlements, retention and projections. Identity, membership, time, provenance, access and lifecycle are anchored in tier-1 primary sources; deployment-surface detail is tier-2 vendor evidence carried as projection detail only. Team economics, collective representation, shift rostering, virtual-only siting and subject-scoped care teams remain declared gaps. No claim of universal completeness is made.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Priority order grounded in SCIM immutable id and externalId, FHIR business identifiers, and GLEIF evidence that no global register issues identifiers to teams. Names and dates explicitly excluded as identifiers." }, { "dimension": "lifecycle", "status": "covered", "notes": "FHIR CareTeam status value set including entered-in-error, plus org:ChangeEvent with original and resulting organizations for merge, split and transfer." }, { "dimension": "relationships", "status": "covered", "notes": "org:subOrganizationOf, unitOf, reportsTo, headOf and linkedTo, CareTeam.managingOrganization, Group.managingEntity, and a typed dependency register with direction and criticality." }, { "dimension": "temporal", "status": "covered", "notes": "RFC 3339 with explicit offsets and the -00:00 convention; org:memberDuring, CareTeam.period, Group.member.period; event time separated from observation time throughout." }, { "dimension": "provenance", "status": "covered", "notes": "PROV-O generation, attribution, derivation and qualifiedAssociation with hadRole and hadPlan; SCIM meta created, lastModified and version; append-only ledger with content digests." }, { "dimension": "ownership", "status": "covered", "notes": "Single accountable owner bound through a post, managing organizations allowed to be multiple, and delegation of authority recorded as a serial instrument." }, { "dimension": "validation", "status": "covered", "notes": "Composition, tier and credential-currency validation functions with explicit evaluation instants; FEMA minimum composition and OSHA training intervals give concrete, testable rules." }, { "dimension": "access", "status": "covered", "notes": "Default deny with least privilege across bundle, layer, finding and artifact scopes; NIST access control and personnel security families; break-glass exception with mandatory review." }, { "dimension": "retention and deletion", "status": "covered", "notes": "GDPR storage limitation and accountability drive per-class schedules, legal holds, anonymisation in preference to deletion, and disposition evidence retained beyond the data." }, { "dimension": "interoperability", "status": "covered", "notes": "Projections to W3C org, SCIM, FHIR, schema.org and HR Open with a mandatory loss report; conformance claimed only per profile version with validation evidence." }, { "dimension": "classification", "status": "covered", "notes": "Two orthogonal axes kept separate: kind or category from FHIR and org:classification, and capability tier from FEMA typing definitions." }, { "dimension": "composition", "status": "covered", "notes": "N-ary membership reification from org:Membership and CareTeam.participant, with in-team role distinguished from the reusable position in WM-ORG-004." }, { "dimension": "capability and qualification", "status": "covered", "notes": "ESCO and ISCO-08 URIs for competences, FEMA skillsets and Position Task Books for qualification evidence, plus explicit currency and lapse handling." }, { "dimension": "authority and mandate", "status": "covered", "notes": "OSHA 1910.156(b)(1) supplies a binding example of a written constituting statement; org:purpose and CareTeam.reason supply the vocabulary; decision rights bounded by separation of duties." }, { "dimension": "measurement", "status": "covered", "notes": "ISO 30414:2025 referenced as the definition frame with materiality and consolidation, while formulae are deliberately not restated; small-population suppression is mandatory." }, { "dimension": "spatial", "status": "covered", "notes": "org:Site with basedAt, hasPrimarySite and siteAddress plus schema.org location; coverage windows must carry explicit offsets or named time zones." }, { "dimension": "privacy", "status": "covered", "notes": "European Commission statement of GDPR principles drives purpose limitation, minimisation and the reference-not-copy rule for person data; FHIR security categories justify sensitivity inheritance." }, { "dimension": "security", "status": "covered", "notes": "Separation of duties, least privilege, bounded revocation on membership end, version-checked patches and digest verification for artifacts." }, { "dimension": "exception", "status": "covered", "notes": "entered-in-error versus normal ending, break-glass access, tier shortfall with compensating measures, over-allocation, and legal hold blocking disposal." }, { "dimension": "team economics and cost", "status": "gap", "notes": "No authoritative source was found that assigns budget, cost centre or chargeback to a team as such; HR Open Compensation and Payroll are worker-level. Left out rather than invented." }, { "dimension": "culture, cohesion and psychological safety", "status": "gap", "notes": "ISO 30414 includes an organizational culture area but the announcement does not expose team-level constructs, and the Scrum Guide is a tier-3 methodology document. Structure not asserted." }, { "dimension": "collective representation and labour relations", "status": "gap", "notes": "ISO 30414:2025 adds labour relations as a topic, but no team-level normative structure was verified for works councils or bargaining units within the fetched sources." } ], "known_omissions": [ "Team budget, cost centre and chargeback semantics.", "Works council, bargaining unit and collective representation structures at team level.", "Shift rostering and rotation patterns as a modelled construct; only coverage windows and allocations are represented.", "Sports squad and military order-of-battle specifics, which have their own registries and constraint regimes.", "Governance of AI-agent teammates beyond representing them as PROV SoftwareAgent participants with a responsible human principal.", "Clause-level text of ISO 30414:2025 and ISO 21502:2020, which are paywalled; only the ISO/TC 260 announcement was verifiable.", "ISO 30400:2022 public pages define organization but do not expose a Team term in the freely retrievable text, so Team-as-HR-object remains an alignment gap.", "Schema.org has SportsTeam but no generic Team type.", "Crew, watch and shift-based operational teams in aviation and maritime domains lack a primary source in this pass.", "Military fireteam, squad and TO&E structures were not sourced.", "Committees, boards and works councils were excluded rather than modelled.", "IPTC Sport Schema Club and TeamMembership (noted in secondary discovery) were not fetched as primary.", "ISO 21502 project-team vocabulary was not fetched.", "Virtual-only teams without a Site have no primary location pattern beyond a gap flag.", "GDPR or other regional retention schedules for membership rosters are not specified by the team sources used.", "SAFe Agile Release Train and other named team-of-teams methods beyond Scrum's split guidance were not sourced." ], "conflicts": [ "FHIR draws a three-way split between Organization (formally recognized), CareTeam (differentiated participants with roles) and Group (undifferentiated, lacking formal legal recognition). W3C org has no equivalent split and would render most teams as org:OrganizationalUnit, which presupposes a parent formal organization; cross-company teams need org:OrganizationalCollaboration instead. The three are not interchangeable and a projection must choose deliberately.", "SCIM requires group membership changes to be applied via the Group resource, while HR interchange practice writes membership from the worker or position side through OrganizationChart incumbency. Write authority must be resolved per Dimension or the two will diverge silently.", "The Scrum Guide states there are no sub-teams or hierarchies within a Scrum Team and caps size at typically ten or fewer, while SCIM explicitly supports nested groups and org supports subOrganizationOf. This is a methodology constraint, not a schema constraint, and is modelled as an optional profile.", "FEMA types teams by minimum capability where Type 1 is strongest, whereas most HR taxonomies type teams by function or permanence. Collapsing the two axes into one field would destroy both.", "ISO 30414:2025 pushes auditable, often consolidated disclosure, while GDPR data minimisation and re-identification risk push against publishing metrics at small-team granularity. The model resolves this with a mandatory suppression decision rather than by preferring one source.", "schema.org department presumes a distinguishable public presence, which most internal teams lack, so the schema.org projection is optional and conditional rather than a default alignment.", "HR Open Standards 4.5R ships no Team noun at all, which is direct evidence against treating Team as a settled interchange object; this model therefore justifies Team as an aggregate on the strength of FHIR CareTeam and org:Membership rather than on HR interchange practice.", "Scrum Guide 2020 forbids sub-teams and hierarchies; GitHub nested teams, ORG unit hierarchy, SCIM nested Groups and FHIR nested CareTeam allow them.", "Schema.org SportsTeam is an Organization and may be a legal club; W3C OrganizationalUnit is not a legal entity.", "Microsoft Graph team is 1:1 with a Microsoft 365 group and is also a collection of channels; GitHub Team is not an organization and cannot include outside collaborators.", "GitHub Docs say visible versus secret while the Teams API uses privacy secret versus closed.", "FHIR allows role-only participants and non-organization members including patients and related persons; GitHub requires organization members.", "SCIM Group is an access-control grouping and does not require a purpose; this model requires purpose for Team.", "Scrum replaced roles with accountabilities that are not job descriptions; ORG Role, FHIR participant.role and GitHub maintainer remain role-like.", "Microsoft default visibility is Public; GitHub default for a non-nested team is secret." ], "regional_assumptions": [ "OSHA 29 CFR 1910.156 is United States law and is used as an existence proof that a written constituting statement can be legally required, not as a universal rule; EU obligations under the Framework Directive 89/391/EEC differ in wording and were not fetched.", "The retention, minimisation and erasure rules follow the European Commission's statement of GDPR principles and apply directly in the EEA; other jurisdictions impose different retention floors and erasure rights.", "ESCO is EU-centric and built over ISCO-08; deployments in the United States will more often need O*NET-SOC, which was not verified here.", "FEMA NIMS typing is United States emergency management practice and needs adaptation before use for commercial teams.", "ISO 30414 is voluntary unless incorporated by national law, listing rules or contract, so its requirements are alignments rather than obligations in most Dimensions.", "FHIR CareTeam is treated as the clinical projection, which is strongest in jurisdictions that adopt HL7 FHIR, including US Core profiles not made mandatory here.", "GitHub and Microsoft Graph represent widely deployed Anglo-American workplace directories, not statutory public-administration team registers.", "ISO 30400 is an international vocabulary; local labour-law definitions of team or crew may differ and were not surveyed.", "Schema.org sports gender and mixed-team text values follow Schema.org's own non-enumerative guidance and are not a legal sex classification." ], "adversarial_checks": [ "Tested whether Team is merely a view over Organization plus Position. HR Open publishes no Team noun and W3C org treats a unit as a subclass of Organization, which supports the sceptical reading; FHIR's separate CareTeam resource with participant roles and a status lifecycle refutes it. Conclusion: Team survives as a distinct aggregate only because it owns mandate, status and time-bounded in-team role bindings that neither neighbour owns. Where an instance has none of those, the model requires it to be rejected as a cohort.", "Searched for an authoritative external register issuing identifiers to team instances. None exists: GLEIF and ISO 17442 cover legal entities, and FEMA identifiers such as 23-508-1289 identify typing definitions, not instances. Identity therefore falls to master-system key then Dimension-minted UUID or ULID, and the model records this as a structural constraint rather than presenting a governed global identifier that does not exist.", "Tested whether team size limits and the prohibition on sub-teams should be structural rules. Rejected: the only support is the Scrum Guide, a tier-3 first-party methodology document that directly conflicts with SCIM nested groups and org:subOrganizationOf. Captured as an optional declared constraint profile instead of a model invariant.", "Tested whether team-level performance metrics belong in this model. Kept only the binding semantics (definition version, observation window, consolidation and suppression) and referred formulae to ISO 30414, because restating metric definitions would duplicate a standard the model cannot keep in sync and would invite unevidenced conformance claims.", "Tested whether in-team role duplicates WM-ORG-004 Position. Resolved by the n-ary evidence: org:Post is reusable and holder-independent while org:Membership and CareTeam.participant.role are the dated binding, so the position definition stays in the sibling model and only the binding lives here.", "Attempted to verify ArchiMate Business Collaboration and ISO 21502 project-team definitions as additional support for the collaboration and project-team cases. Both were behind authentication or paywall, so they were omitted entirely rather than cited from secondary summaries, leaving the cross-organization collaboration case supported only by W3C org:OrganizationalCollaboration.", "Checked whether a simple active boolean could replace the status value set. Rejected because FHIR's entered-in-error value carries erasure and downstream-retraction consequences that a boolean cannot express, and conflating the two would make lawful correction indistinguishable from normal ending.", "If a record has members but no purpose, it should be classified as Group or access list rather than Team, matching ORG and the FHIR Group versus CareTeam boundary.", "If members are only organizations, the record should move to OrganizationalCollaboration or Project rather than Team.", "If identity is a slug or founding date, the record fails the identity priority rule.", "If a Scrum Team is stored with parent-child hierarchy, a conflict flag is mandatory rather than silent nesting.", "If IdP synchronization is on, local membership writes must fail rather than drift.", "If a secret team is nested, the instance is invalid against GitHub's primary rule even if another profile allows hierarchy.", "If Microsoft delete is requested, the associated group fate must be explicit so that directory identity is not destroyed by accident." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": {}, "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "The base (claude) entry kind stands. Both providers independently model membership as a first-class, time-bounded, separately identified record with its own period, role, state and provenance (claude membership-assignment-record artifact serial:true; grok membership-record artifact serial:true), which is the n-ary reification pattern of org:Membership and FHIR CareTeam.participant. A membership record has no meaning outside its team root and is never referenced independently, which is exactly the aggregate test; grok's own structure satisfies it even though grok labelled the model 'entity'. Grok's 'entity' label is therefore treated as a naming choice, not as contrary evidence, and is rejected without escalating to a critical conflict. Model boundary is fixed before node acceptance: the team node references exactly one containing organization context and never carries legal-entity identity or LEI eligibility (WM-ORG-001), never owns reusable post definitions (WM-ORG-004), and requires enumerated rather than definitional membership, so rule-defined cohorts, access-control-only groups and organization-membered collaborations are rejected as instances." }, "decisions": [ { "concept": "Base provider selection", "disposition": "claude adopted as base", "rationale": "Claude carries seven source-backed boundary notes against organization, position, SCIM group, definitional cohort, care team, NIMS typed-resource team and public department, plus an explicit disqualification rule for records that are not teams. Its adversarial checks test the sceptical reading that Team is only a view over Organization plus Position and resolve it on evidence. Grok is larger on deployment surface but thinner on boundary derivation; size was not the deciding factor." }, { "concept": "Entry kind aggregate versus entity", "disposition": "aggregate retained, entity rejected", "rationale": "Membership is a separately identified, time-bounded, provenance-bearing record with no meaning outside its team root in both packs, which is the aggregate test under the org:Membership and CareTeam.participant n-ary pattern. Grok's own membership-record artifact satisfies the same test, so its entity label is a naming difference, not contrary evidence." }, { "concept": "Names, slugs and display labels", "disposition": "accepted from grok into team-identity", "rationale": "The base states only that names are never identifiers and provides no positive structure for preferred label, locale, derived slug or rename authority. The addition is evidence-backed across ORG, FHIR, SCIM and vendor directories and closes a real hole without touching the identity priority rule." }, { "concept": "Containing and managing organization", "disposition": "accepted from grok into team-identity", "rationale": "The base leaves the containment edge in prose while modelling only co-management as a question. Separating containing organization from managing organization and adding the hosting tenant makes the single most important team relationship explicit and testable." }, { "concept": "Parent-child nesting and inherited membership", "disposition": "accepted from grok into membership-records", "rationale": "Inherited membership changes what the member set means and the base resolves it nowhere; a single nesting question is not sufficient structure for listings, mentions and entitlement inheritance that behave differently for direct and inherited members." }, { "concept": "Membership provisioning, invitation and IdP synchronization", "disposition": "accepted from grok into membership-records with a boundary constraint", "rationale": "The base asks how HR and IdP write conflicts are reconciled but supplies no mechanism. Accepted on condition that any directory rule must materialise enumerated identified members, preserving the base rule that definitional rule-defined cohorts are not teams." }, { "concept": "Team post establishment and ex-officio membership", "disposition": "accepted from grok into membership-records", "rationale": "Both providers agree post definitions stay in WM-ORG-004, but only grok models org:hasPost attachment, vacant posts and membership arising ex officio from holding a post. Establishment separate from staffing is a genuine gap in the base, and the addition does not breach the sibling-model boundary." }, { "concept": "Visibility, discoverability and sensitivity labelling", "disposition": "accepted from grok into provenance-access-retention", "rationale": "The base covers default record visibility and GDPR principles but not discoverability class, sensitivity-label binding to a directory-preconfigured value, or the leakage case where mentioning a hidden team reveals its name. Competing visibility vocabularies are to be recorded side by side, never merged into one code list." }, { "concept": "Team entitlements on external resources", "disposition": "accepted from grok into provenance-access-retention", "rationale": "The base access layer is entirely inbound; a team holding and inheriting permissions on resources is a distinct concern that neither provider places out of scope. The granted resources themselves remain out of scope, so only the grant relation and member, guest and owner capability sets are taken." }, { "concept": "Grok canonical-team-identity", "disposition": "rejected as duplicative", "rationale": "Identical identity priority order to the base team-identifier-assignment finding, which additionally carries alternate business identifiers and duplicate-record tombstoning. Adding it would create a second identity finding with no new evidence." }, { "concept": "Grok defining-purpose", "disposition": "rejected as duplicative", "rationale": "The base team-charter-and-mandate already binds org:purpose, FHIR reason and the shared-objective pattern to a written constituting statement with approval, effective date and review trigger, and is additionally anchored by a binding legal example. The grok finding is a strict subset." }, { "concept": "Grok collaboration-versus-unit-boundary", "disposition": "rejected as duplicative", "rationale": "The base resolves this in two boundary notes and in the question asking whether the collective is an internal unit, a cross-organization collaboration or a rule-defined cohort. Promoting it to a finding would duplicate settled boundary work." }, { "concept": "Grok roles-accountabilities-and-leadership and size-autonomy-and-accountability", "disposition": "rejected as duplicative", "rationale": "Content is already split across the base role-and-position-binding, decision-rights-ownership-and-reporting-line and minimum-composition-constraints findings, including the lead-role question and the declared constraint profile. Accepting would fragment authority semantics across three layers." }, { "concept": "Grok operational-status and archive-error-and-deletion", "disposition": "rejected as duplicative; cascade hazard routed to the mapping specification", "rationale": "Status values, the entered-in-error versus normal-ending distinction, dissolution and retention are all covered by the base. Archive, unarchive and clone are vendor projection operations, and the hazard that deleting a team also destroys its backing directory group belongs in the projection and mapping specification artifact, not in a new lifecycle finding." }, { "concept": "Grok site-contact-and-schedule", "disposition": "rejected; shift schedule and virtual-only siting deferred", "rationale": "Sites, distribution, jurisdiction effects and coverage gaps are covered by the base site-footprint finding and the team-level contact route is already modelled. Shift rostering rests on a single tier-2 vendor schedule object and the base deliberately declared rostering an omission; virtual-only teams are flagged as a gap by grok itself." }, { "concept": "Grok subject-goal-or-sport", "disposition": "rejected; retained as an EXTEND profile candidate", "rationale": "The base explicitly places subject-scoped teams outside the base case because FHIR CareTeam is subject-bound and carries a patient security category. Accepting a subject binding into the base would contradict a boundary decision made on tier-1 evidence; it is deferred as a profile question instead." }, { "concept": "RFC 3339 cited in grok findings without a registered source entry", "disposition": "source reference rewired to the base RFC 3339 entry", "rationale": "Grok asserts RFC 3339 date-time requirements in membership and post-assignment findings while registering no RFC 3339 source in its own pack. The accepted post-establishment addition must be re-pointed at the base RFC 3339 source so no merged node carries an unregistered citation." }, { "concept": "Competing hierarchy, visibility and typing vocabularies", "disposition": "recorded as declared conflicts, not merged", "rationale": "Method-level prohibition of sub-teams conflicts with nested groups and unit hierarchy; two vendor visibility vocabularies disagree on their own labels; capability-tier typing and functional classification are orthogonal axes. Each is carried as a declared profile constraint with its source, and collapsing any of them into a single field is prohibited." } ], "publicationHolds": [ "Source and live-version verification is unresolved: all twenty-nine distinct URLs across both packs must be re-fetched and re-pinned before publication, with particular attention to fast-moving or forward-dated version strings including schema.org 30.0 dated 2026-03-19, ESCO v1.2.1 dated 2025-12-10, HR Open 4.5 Final and 4.6 Candidate, the GitHub REST API version 2026-03-10, the Microsoft Graph v1.0 page last updated 2024-10-18, the FEMA RTLT tool version, and the NIST SP 800-53 control release 5.2.0.", "Multi-profile domain validation is unresolved: the merged model has not been instantiated against the clinical care-team profile, the workplace-directory profile, the emergency-response typed-resource profile, or the agile-delivery profile. No conformance or alignment language may be published until at least these four profiles have been round-tripped and their loss reports recorded.", "Paywalled and landing-page-only evidence must not be published at clause level: ISO 30414:2025 is cited from a committee announcement, ISO 30400:2022 from a catalogue landing page that does not expose a Team term, and ISO 21502 and ArchiMate business collaboration were never obtained. Every claim resting on these must be marked as unverified at clause level or removed.", "All seven accepted additions and four of the five accepted functions rest wholly or partly on tier-2 vendor documentation. Each must be re-checked against tier-1 sources for contradiction before publication, and vendor-specific vocabularies for visibility, nesting and archive states must be published as projection detail rather than as base semantics.", "Citation provenance for the accepted additions must be repaired: grok asserts RFC 3339 timestamp requirements in membership and post-assignment findings without registering RFC 3339 as a source in its own pack, so every merged node inheriting that claim must be re-pointed at the base RFC 3339 source and re-validated." ], "deferredResearch": [ "Virtual and fully distributed teams with no physical site: both providers flag this as a gap and neither found a primary pattern for recording location without inventing a site. Needs an authoritative source before any siting rule is asserted.", "Shift rostering, watch and rotation patterns as a modelled construct at team granularity. Present evidence is a single tier-2 vendor schedule object; the base deliberately omitted it. Aviation, maritime and healthcare crew and watch structures should be sourced together.", "Team economics: budget, cost centre and chargeback assignment to a team as such. No authoritative source was found in either pack; HR interchange compensation and payroll domains are worker-level and cannot be lifted to team granularity without invention.", "Collective representation at team level: works councils, bargaining units and statutory governance bodies. One pack lists labour relations as a reporting topic without team-level structure and the other excludes such bodies outright; the boundary between a team and a statutory body needs primary evidence.", "Subject-scoped teams as an EXTEND profile: decide whether a team bound to a patient, product, event or competition is hosted by this model as a profile or by a sibling model, and source the binding trigger for teams constituted before a subject exists.", "Unfetched team-of-teams and domain registries: ISO 21502 project-team vocabulary, IPTC Sport Schema club and team-membership types, military order-of-battle structures, named scaled-agile team-of-teams constructs, and O*NET-SOC as the non-EU alternative to the ESCO occupation taxonomy.", "Governance of AI-agent and robotic teammates beyond representing them as software agents with a responsible human principal, including qualification, accountability and access semantics for non-human members." ] }, "statistics": { "sources": 27, "bundles": 6, "layers": 13, "findings": 31, "questions": 127, "artifacts": 23, "functions": 16 } }