macOS
Enable an AI agent to recognise a macOS installation, assess its operational and security state, and determine which changes are compatible, authorised and recoverable.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
Researched by: Codex + Grok
Purpose and description
Enable an AI agent to recognise a macOS installation, assess its operational and security state, and determine which changes are compatible, authorised and recoverable.
macOS is Apple's Unix-based operating system for Macintosh personal computers, combining a Darwin kernel and POSIX userland with proprietary Aqua, Cocoa, and system frameworks that license, update, and bind hardware to a given major version.
It can be Inspect and identify a macOS installation using observations whose source, time and execution context are recorded.; Evaluate a proposed application, extension or operating-system update against the installation and host constraints.; Diagnose startup, login, service and resource problems using macOS-specific evidence.; Adjust supported system settings and permissions when the acting agent has the required authority.; Plan and execute authorised installation or update operations after checking prerequisites and disruption.; Select and verify a recovery or migration procedure appropriate to the host, installation and available recovery material..
Distinguishing features
Confirm macOS identity using installed-system evidence such as product name, version and build; an Apple logo, desktop appearance or device name is insufficient.
Distinguish macOS from its host Mac: hardware identity can persist while the installed operating system changes.
Distinguish the installed operating system from macOS Recovery, an installer image or installation media before interpreting observations or attempting changes.
Distinguish macOS from Darwin alone by verifying the macOS product identity and expected platform environment rather than treating a Darwin kernel identifier as sufficient.
Distinguish separate macOS installations on the same host by their startup volume and installation context rather than merging their state under the hardware identifier.
Scope
+ Platform identity, installed macOS version and build, and evidence distinguishing an installed system from an installer or recovery environment
+ Compatibility between the installed release, host architecture, applications, extensions and required workflows
+ Operating-system services, startup behaviour, system storage relationships and resource constraints
+ macOS security controls, privacy permissions and effective administrative or device-management restrictions
+ Installation, update, migration and recovery readiness, including evidence needed before consequential changes
- The Mac's physical components, ownership and hardware repair history
- Application-specific business data, functionality and licensing
- People, organisational roles and identity-provider account lifecycles
- Network infrastructure and services external to the installation
- The contents and retention policies of user documents and backups
- Apple's corporate operations and the development histories of other Apple operating systems
Characteristics
- Observation context
- running installation | offline installation | recovery environment | installer | unknown Determines which installation an observation describes and which actions are meaningful.
- Installed release identity
- Recorded macOS product version and build identifier, with evidence and observation time Anchors compatibility, update and security assessments to an identifiable release.
- Host and startup installation
- References to the host Mac or virtual machine and the startup volume or volume group Prevents state and changes from being attributed to the wrong installation.
- Execution architecture context
- Host architecture, operating-system architecture and native or translated process context, each recorded separately Supports accurate application, extension and tooling compatibility decisions.
- Operational readiness
- ready | degraded | startup blocked | login blocked | recovery only | unassessed, with supporting symptoms Connects observed failures to the workflows the installation must support.
- Available installation storage
- Bytes available on relevant volumes, distinguishing free and reported reclaimable capacity Constrains updates, installation operations and normal application activity.
- Effective security posture
- Observed states of applicable controls, including FileVault, System Integrity Protection, Gatekeeper and startup security, with unknown and not-applicable states allowed Exposes protections and restrictions that affect the safety and feasibility of proposed actions.
- Effective management authority
- Relationships to local administrators, device management, enforced profiles and the authority approving the proposed action Distinguishes technical capability from permission to change the installation.
- Update disposition
- unassessed | eligible | deferred | blocked | staged | restart pending | failed, qualified by a specific target release Makes update readiness actionable without assuming that an offered update is suitable.
- Recovery readiness
- unassessed | prerequisites missing | prerequisites evidenced | recovery tested, qualified by a specific failure scenario Prevents an available backup or recovery interface from being mistaken for a verified restoration path.
Also called
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 6 bundles · 11 layers · 18 findings · 33 questions.
Platform and installation identity Establishes what macOS environment is being modelled and which installation observations belong to.
Version information and system state are unsafe to interpret without separating the product, installed instance and current execution environment.
Release identification
Records evidenced macOS product and build identity.
macOS product and build
The model should distinguish a verified macOS release identity from names inferred from appearance, hardware or a kernel string.
- Which observed product version and build identify this macOS installation? definition
- Which command, system interface or offline installation record supplied that identity, and when? provenance
Installation context
Separates the target installation from its host and the environment used to inspect it.
Target system boundary
The model should bind observations to a specific startup installation and identify whether inspection occurs from that installation, Recovery or another environment.
- Which host and startup volume or volume group identify the target installation? boundary
- Does the current session describe the target macOS installation, macOS Recovery, an installer or a different booted system? boundary
Mac and software compatibility Relates macOS release requirements to the host and the software that must run.
An installation can be identifiable and operational while still being unsuitable for a required application, extension or target release.
Host and release fit
Evaluates a particular macOS release against the actual host environment.
Supported host context
The model should distinguish documented host compatibility from an installation that merely appears to run.
- What Mac model or virtual-machine configuration and processor architecture host this installation? measurement
- What authoritative compatibility evidence covers this host and the installed or proposed macOS release? provenance
Application and extension fit
Assesses required software, architecture translation and system integration constraints.
Required software execution
The model should record whether required applications and extensions can execute and integrate under this macOS release and its effective policies.
- Which required applications or extensions depend on a particular architecture, Rosetta availability, macOS API or approval mechanism? boundary
- What vendor evidence or observed workflow test establishes compatibility with the installed or proposed build? provenance
- Which compatibility failures must be resolved before installing software or changing macOS? action
Startup and operational health Captures whether macOS reaches a usable session and sustains required system functions.
A useful state judgement must connect macOS symptoms to startup stages, system services and storage conditions.
Startup and session
Locates failures between system startup, volume unlocking, login and usable sessions.
Usable session readiness
The model should distinguish inability to start macOS from inability to unlock storage, authenticate or sustain a user session.
- At which observed stage does progress stop: startup selection, volume unlock, macOS startup, login or session operation? measurement
- Which macOS diagnostic records or directly observed symptoms support that assessment? provenance
Services and system storage
Assesses macOS service behaviour and the storage conditions relevant to operation.
System function constraints
The model should connect failed required functions to evidence about launchd-managed services, resource pressure and relevant system or data volumes.
- Which required macOS functions are failing, and what service status, crash reports or resource observations correspond to those failures? measurement
- What capacity, mount, access or volume-health conditions constrain the installation's system and data storage? measurement
- Which supported diagnostic or repair action fits the evidence and the agent's current execution context? action
Security, privacy and control Records applicable macOS protections and the effective authority governing changes.
Administrative access alone does not describe every security, privacy or management prerequisite for a macOS action.
Platform protections
Assesses macOS protection mechanisms individually and in host context.
Effective protection states
The model should retain separate evidence for applicable encryption, system-integrity, application-execution and startup protections.
- What are the evidenced states of FileVault, System Integrity Protection, Gatekeeper and the startup-security controls applicable to this host? measurement
- Which protections constrain the proposed action, and what supported procedure satisfies those constraints? action
Permissions and management
Relates local privileges, privacy consent and device-management policy to a specific action.
Action-specific authority
The model should distinguish user authorisation, process permissions and enforced management settings without recording secret credentials.
- Which local privileges, privacy permissions or interactive approvals does the acting process require for this action? action
- Which configuration profiles or device-management restrictions govern the setting or operation being changed? boundary
- What evidence establishes that the person or organisation authorising the change has authority over this installation? provenance
Updates, migration and recovery Evaluates transitions between macOS states and the means of recovering from unsuccessful changes.
Update availability, installation feasibility and recoverability are separate judgements requiring release-specific and installation-specific evidence.
Release transition readiness
Assesses a named target release and the conditions for reaching it.
Target update decision
The model should record the proposed target build, its provenance, compatibility gates and operational prerequisites.
- Which target macOS version and build are proposed, and what trusted release or update source establishes their identity? provenance
- What storage, power, connectivity, authorisation, management or restart conditions currently permit or block the transition? action
- Which post-update checks will demonstrate that macOS and the required workflows remain usable? action
Restoration and migration paths
Qualifies recovery and migration options against the actual failure or replacement scenario.
Verified recovery path
The model should distinguish reinstalling macOS, restoring user state, migrating to another installation and returning to an earlier release.
- For the specified failure scenario, which Recovery, reinstall, backup-restoration or migration procedure is applicable to this host and release? action
- What evidence verifies access to the necessary backups, recovery material and authorisation without exposing secrets? provenance
- What system state or user data would the selected procedure preserve, replace or leave unrecoverable? boundary
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.
A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.
Reported evidence
Findings from the breadth pass, kept separate from the structural claims.
Kinds and varieties
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Classic Mac OS (System 1 through Mac OS 9, pre-Unix lineage)
- Mac OS X / OS X desktop releases (10.0 Cheetah through 10.11 El Capitan)
- macOS desktop releases (10.12 Sierra onward, including 11 Big Sur and later major versions)
- macOS Server (server roles and tools, later folded into the desktop product)
- Developer and beta channels (Apple Beta Software Program, Seed, and Release Candidate builds)
- Apple silicon (arm64) versus Intel (x86_64) editions of the same named release
- Virtualized macOS guests (macOS Virtualization.framework / licensed VM installs on Apple hardware)
- Recovery, restore, and installer environments (macOS Recovery, Internet Recovery, IPSW/IPSW-like restore images)
- Which of these kinds and varieties hold for the sense of macOS this model covers, and on what evidence? provenance
Identifiers and schemes
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Wikidata - Q14116 - Item for the macOS operating-system family (Apple, Darwin-based).
- CPE 2.3 - cpe:2.3:o:apple:macos:<version>:*:*:*:*:*:*:* - NIST NVD product; older releases also appear as cpe:2.3:o:apple:mac_os_x and cpe:2.3:o:apple:os_x.
- IANA/OS uname - Darwin; sysname Darwin, with marketing version in sw_vers ProductVersion - Kernel reports Darwin; the marketed product string is macOS / OS X / Mac OS X depending on era.
- Apple software version - ProductVersion X.Y[.Z] plus BuildVersion e.g. 24A335 - Read from sw_vers or SystemVersion.plist; build letter encodes major train.
- User-Agent / HTTP - Macintosh; Intel Mac OS X <n>_<n>[_<n>] or Macintosh; ARM Mac OS X ... - Safari and many apps still send 'Mac OS X' in the UA even on current macOS.
- Which of these identifiers and schemes hold for the sense of macOS this model covers, and on what evidence? provenance
Standards and regulation
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- IEEE Std 1003.1 (POSIX) - IEEE / The Open Group: Darwin userland and many CLI utilities are POSIX-aligned; macOS has historically carried UNIX 03 certification on specific versions (e.g. OS X 10.5-10.8 era), later versions are Unix-like without a current Open Brand UNIX certificate.
- Open Brand UNIX 03 - The Open Group: certification applied to named Mac OS X / OS X releases, not to every later macOS train.
- IETF RFC 1034/1035 and related - hostname, mDNS/Bonjour (RFC 6762/6763) as shipped naming and discovery.
- Apple Platform Security / Apple Platform Security Guide - Apple Inc.: Secure Boot, signed system volume, System Integrity Protection, FileVault, TCC.
- EU Digital Markets Act (Regulation (EU) 2022/1925) - European Union: designated gatekeeper obligations affecting macOS app distribution, browser engines, and interoperability in the EU.
- IEC 62368-1 / regional electrical safety and EMC (FCC Part 15, CE RED/EMC) - apply to Mac hardware that runs macOS, not to the OS as a document, but they constrain what a Mac+macOS product may ship.
- NIST SP 800-179 / CIS Apple macOS Benchmarks - U.S. NIST and CIS: hardening baselines used in enterprise macOS fleets.
- App Store Review Guidelines and Notarization requirements - Apple Inc.: code signing, notarization (Gatekeeper), and distribution rules for software on macOS.
- Which of these standards and regulation hold for the sense of macOS this model covers, and on what evidence? provenance
Real-world use
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Primary OS on Apple Macintosh notebooks and desktops (MacBook Air/Pro, iMac, Mac mini, Mac Studio, Mac Pro) sold and supported for a sliding window of hardware generations.
- Creative-production workstation OS for video, audio, photography, and design shops using Final Cut, Logic, Adobe, and similar native apps.
- Developer workstation for iOS/iPadOS/watchOS/tvOS/visionOS toolchains; Xcode and the iOS Simulator officially run only on macOS.
- Enterprise-managed endpoint via MDM (Apple Business Manager, Jamf, Microsoft Intune, Kandji) with FileVault, configuration profiles, and software update deferrals.
- CI and build hosts, often as Mac minis or cloud Macs (AWS EC2 Mac, MacStadium, GitHub-hosted macOS runners) because Apple's license requires macOS to run on Apple-branded hardware.
- Consumer personal computer: Safari, Mail, iCloud, Continuity/Handoff, Sidecar, and iPhone/iPad companion features.
- Recovery and deployment: Internet Recovery, DFU restore, and MDM-enrolled zero-touch setup (ADE/ABM).
- Which of these real-world use hold for the sense of macOS this model covers, and on what evidence? provenance
Typical measurements
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Marketed major version (ProductVersion) - 10.0-10.15 historically; 11-16+ in the post-Big Sur numbering - dotted version string
- Darwin kernel version (uname -r) - roughly 1.x (early Mac OS X) through 24.x+ on current trains - kernel release string
- Supported hardware window - about 6-8 years of Mac models receive the current major macOS; security updates continue on N-1/N-2 for a shorter window - calendar years / model years
- Installer / system volume size - full installer ~12-15 GB; sealed system volume plus Data volume typically tens of GB on a working Mac - gigabyte (GiB)
- Minimum RAM for current major releases - 8 GB officially on recent trains; 16 GB common for development/creative work - gigabyte (GiB)
- Architecture - x86_64 (Intel, including Rosetta 2 guests) or arm64 (Apple silicon); Universal 2 binaries contain both - instruction-set architecture
- Update cadence - one named major release per year (autumn); point releases and rapid security responses in between - releases per year
- Which of these typical measurements hold for the sense of macOS this model covers, and on what evidence? provenance
Failure modes and hazards
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Unsigned or un-notarized code blocked by Gatekeeper; broken code signatures after disk clone or permission repair.
- Signed System Volume / Sealed System Volume seal break or failed update leaving the Mac unbootable until recovery reinstall.
- Firmware or T2/Apple silicon Secure Boot pairing failure; DFU restore required when the LocalPolicy or LLB chain is damaged.
- Kernel panic, third-party kext/system-extension incompatibility after a major upgrade (especially USB, VPN, and storage filters).
- FileVault recovery-key loss: ciphertext is unrecoverable without the password, recovery key, or institutional key.
- Malware and adware (typically user-level, not kernel) plus TCC/Full Disk Access social-engineering; historically Mac-specific families such as Shlayer, Bundlore, and Atomic Stealer.
- Rosetta 2 or architecture mismatch: Intel-only apps fail on Apple silicon without translation; old Carbon/32-bit apps already dropped after Catalina.
- MDM/profile lock and Activation Lock (Find My) making a device inoperable to a new owner.
- Privacy and data-exfiltration risk via Continuity, iCloud, screenshots, and always-on microphones/cameras on notebooks - mitigated by hardware indicators and TCC but still a deployment hazard.
- Licensing: running macOS on non-Apple hardware (Hackintosh) violates the software license and is operationally fragile across updates.
- Which of these failure modes and hazards hold for the sense of macOS this model covers, and on what evidence? provenance
Regional variation
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- EU (DMA): alternative app marketplaces, browser-engine choice, and extra interoperability obligations on macOS that do not apply in the same form in the US or most other regions.
- China: iCloud operated by GCBD (云上贵州) for mainland Apple IDs; different notarization/network endpoints and App Store catalog.
- Language and locale packs: input methods (Pinyin, Kotoeri, Hangul, Arabic) and region-specific first-run legal text; some features (Apple Pay, some iCloud+ capabilities) are country-gated.
- Product naming: Japanese and some markets long used 'Mac OS X' branding later than others; the 2016 shift from 'OS X' to 'macOS' was global but documentation lag remains in UAs and enterprise catalogs.
- Keyboard hardware: ISO vs ANSI vs JIS physical layouts; the Option/Alt and Command glyphs and key positions differ, which affects how 'macOS shortcuts' are taught.
- Which of these regional variation hold for the sense of macOS this model covers, and on what evidence? provenance
Neighbouring kinds and how to tell them apart
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Classic Mac OS (System 1-Mac OS 9) - Cooperative, non-Unix Mac OS; no Darwin kernel, no Aqua as later defined. Test: presence of Darwin/uname, Mach-O binaries, and a sealed APFS system volume - all indicate macOS/Mac OS X, not Classic.
- Darwin (open-source kernel + userland) - Darwin is the open kernel/userland subset. macOS is Darwin plus proprietary graphics, Aqua, Cocoa, Apple apps, and the license that binds it to Apple hardware. Test: whether Cocoa/AppKit, WindowServer, and Apple-signed system volume are present.
- iOS / iPadOS - Same Darwin/XNU family and many frameworks, but different UIKit-centric runtime, app sandbox, and device class. Test: UIDevice/idiom, presence of SpringBoard vs WindowServer/Dock, and whether the device is a Mac with a pointer-first AppKit desktop.
- iPadOS with Stage Manager / 'PC-like' iPad - Still iPadOS; cannot run Xcode as a full Mac IDE or arbitrary unsigned Mac apps. Test: uname/sysctl hardware model (iPad*) and lack of /System/Library/CoreServices/Finder.app as on a Mac.
- visionOS, watchOS, tvOS - Sibling Darwin-based Apple OSes for other device classes. Test: platform identifier in the SDK (macosx vs iphoneos vs xros vs watchos vs appletvos) and the hardware they boot on.
- Linux or BSD on Apple silicon (Asahi Linux, OpenBSD) - May boot on the same Mac hardware but is not macOS and cannot run most Mac apps or Apple's signed-system model. Test: kernel name (Linux/OpenBSD vs Darwin) and absence of Apple's signed system volume.
- Windows (Boot Camp historically, or VMs / Parallels / VMware) - Different kernel and ABI; Boot Camp was Intel-only. Test: NT vs Darwin; on Apple silicon, Windows is virtualized, not dual-booted as on Intel Boot Camp.
- OS X / Mac OS X as a separate product - Same lineage; 'Mac OS X' (10.0-10.7), 'OS X' (10.8-10.11), then 'macOS' from 10.12. Test: ProductName in sw_vers and the version number; treat as era names of one family unless a catalogue needs the 2012-2016 trademark split.
- Which of these neighbouring kinds and how to tell them apart hold for the sense of macOS this model covers, and on what evidence? provenance
Sources
- macOS - Current product identity, supported Mac hardware, and the public name of the shipping desktop OS.
- macOS - Lineage from Mac OS X through OS X to macOS, Darwin/Unix basis, version chronology, and distinction from Classic Mac OS.
- macOS (Q14116) - Stable identifier, official website, developer, and same-as links used as a registry key.
- Apple Platform Security - Secure Boot, signed system volume, SIP, FileVault, and hardware-bound trust as the security model of current macOS.
What the second pass must settle
- Does the existing Vercy catalogue already contain a macOS or operating-system model that this registry entry should reference rather than duplicate?
- How should the registry's PHY / PHY.OBJ placement distinguish macOS as a software platform from a concrete installation and its physical host?
- Which official sources establish host compatibility, update eligibility and security-maintenance status for each release without assuming a fixed support window?
- Which security, approval and recovery mechanisms vary by Mac hardware generation, macOS release and virtualised execution context?
- What minimum evidence and freshness requirements should establish operational readiness and tested recoverability for the intended agent workflows?