# USAT1024 — Universal Standard Articulated Taxonomy **Standard Specification, Version 1.1** **Published by:** urSynergy, Inc. **Publication Date:** 2026-04-21 **Canonical URL:** `https://ursynergy.com/standards/usat1024` **License:** Free for any use with required citation (see §10) --- ## Abstract USAT1024 is an open articulated classification standard for identifying professional concepts, occupational functions, tenancy relationships, regulatory credentials, verification claims, jurisdictions, and artificial intelligence agents across regulated workflows. It defines a 1024-bit canonical binary identifier with a deterministic dotted-decimal human-readable form, a concept/term/relationship data model for richly expressing hierarchy and synonymy, and a normative bounded-delegation authorization principle that applies uniformly to human and AI actors. USAT1024 is published and maintained by urSynergy, Inc. with the explicit intent that other platforms, regulators, educational institutions, and commercial systems adopt its codes as shared infrastructure. It cross-references ISCO-08, SOC-2018, O*NET-SOC, SNOMED CT, ESCO, and VeNom so that USAT1024 identifiers interoperate with existing occupational, clinical, and statistical classification systems. --- ## 1. Normative terminology This specification uses the following terms with their precise meanings. Key words **MUST**, **MUST NOT**, **SHOULD**, **SHOULD NOT**, **MAY** are as defined in RFC 2119. - **Concept** — A single stable, opaque, language-neutral meaning identified by a USAT1024 code. A concept does not change its meaning once published. Concepts may be deactivated or replaced but their codes are never reused. - **Term** — A human-readable label for a concept, classified by locale and term-type. A concept may have many terms; a term belongs to exactly one concept. - **Relationship** — A non-hierarchical directed edge between two concepts. Hierarchy is expressed through parent-child references on concepts, not through relationships. - **Taxonomy** — A collection of concepts with a shared prefix and a common domain of meaning. USAT1024 defines seven taxonomies at version 1.0 (see §5). - **Actor** — An entity capable of performing actions. Humans and AI agents are both actors. Organizations may be delegated actors in certain contexts. - **Delegation** — An action in which one actor (the **instructing actor**) causes another actor (the **executing actor**) to perform work. When the same entity instructs and executes, delegation is reflexive. - **Authorization** — A decision that a specific action by a specific actor or delegation chain is permitted under the governing rules. - **Conformant implementation** — A software system that implements USAT1024 in accordance with the normative requirements of this specification. --- ## 2. Design principles USAT1024's architecture rests on six principles. All normative requirements derive from these. ### 2.1 Stable opaque codes Every concept is identified by a stable opaque code. The code does not encode meaning in its characters. Applications that depend on USAT1024 codes reference them as whole identifiers; they do not parse segments to derive semantics. Meaning is carried by the concept's terms, relationships, and metadata — not by its code string. ### 2.2 Hierarchy plus relationships Hierarchy is expressed through a single parent reference per concept. Non-hierarchical connections between concepts — equivalence, replacement, credential requirements, supervision patterns — are expressed as relationships. This separation keeps the primary tree clean and allows arbitrary cross-references without hierarchical ambiguity. ### 2.3 Terms are separate from concepts A concept's display form is never fixed to the concept record. Terms live in their own table, classified by locale and term-type. One concept can have any number of terms across any number of languages and contexts. Preferred terms are selected by the resolver at render time based on the requester's locale. ### 2.4 Articulation through external references USAT1024 codes carry cross-references to other published taxonomies (ISCO-08, SOC-2018, SNOMED CT, ESCO, O*NET-SOC, VeNom) as first-class metadata. USAT1024 is a standards-interoperability hub, not an island. Any concept with a plausible equivalent in an external system carries that reference. ### 2.5 Bounded delegation as normative rule Authorization for any action is the intersection of the instructing actor's authority and the executing actor's permission. Neither party can exceed what both permit. This rule applies uniformly to human-to-human delegation (such as a veterinarian directing a technician), human-to-AI delegation (such as a clinician directing an AI to amend records), and AI-to-AI delegation (such as one agent delegating to another). This is normative — a conformant implementation MUST enforce bounded delegation. ### 2.6 Full provenance Every grant and every denial of authorization is recorded with attribution to the rules, policies, statutes, and administrators responsible. The audit trail answers who did what, on behalf of whom, under which authority, in which context, and (if denied) why. --- ## 3. The 1024-bit canonical binary code The normative representation of a USAT1024 identifier is a 1024-bit (128-byte) binary structure. All conformant implementations MUST support both the binary form and the dotted-decimal human-readable form (§4), and MUST provide bidirectional deterministic conversion between them. ### 3.1 Binary layout The 128 bytes are allocated as follows. Bit offset 0 is the most-significant bit of the first byte. | Offset (bits) | Length (bits) | Field name | Description | |---|---|---|---| | 0 | 32 | `magic` | Fixed value `0x55534154` (ASCII "USAT"). Marks the identifier for any parser. | | 32 | 16 | `binary_format_version` | Which revision of the USAT1024 binary encoding this identifier uses. Current value: `0x0001`. | | 48 | 16 | `usat_major_version` | USAT semantic version major. Current value: `0x0001`. | | 64 | 16 | `usat_minor_version` | USAT semantic version minor. Current value: `0x0000`. | | 80 | 16 | `usat_patch_version` | USAT semantic version patch. Current value: `0x0000`. | | 96 | 32 | `taxonomy_identifier` | Unique identifier for the taxonomy. See §5 for allocation. | | 128 | 32 | `flags` | Concept flags (deprecated, provisional, locale-neutral, self-claimable, etc.). See §3.2. | | 160 | 8 | `depth` | Number of hierarchy segments present (0-20). | | 168 | 8 | `reserved_alignment` | Must be zero. Reserved for future alignment use. | | 176 | 320 | `hierarchy_segments` | Twenty 16-bit segments. Unused segments are zero. See §3.3. | | 496 | 256 | `external_reference_hashes` | Four 64-bit hashes of cross-referenced codes. See §3.4. | | 752 | 32 | `crc32` | CRC-32 of bits 0-751, using the IEEE 802.3 polynomial. | | 784 | 240 | `reserved_extension` | Must be zero in version 1.0. Reserved for future extension. | | **1024** | | | **Total.** | ### 3.2 Flag bits The 32-bit `flags` field is a bitmap. Bits 0-7 are defined in version 1.0; bits 8-31 are reserved. | Bit | Name | Meaning | |---|---|---| | 0 | `deprecated` | The concept is inactive; readers should follow `deprecated_replacement_code` metadata. | | 1 | `provisional` | The concept is newly added and subject to change. | | 2 | `locale_neutral` | No translation is necessary; preferred term is universal. | | 3 | `self_claimable` | An individual user may assert this concept about themselves without curator review. | | 4 | `requires_verification` | The claim is considered authoritative only after verification. | | 5 | `platform_curated` | Concept is system-maintained; users may not self-claim. | | 6 | `ai_agent` | Concept identifies an AI agent (specific to USAT1024-PC branch PC.100.160). | | 7 | `other_unspecified` | Concept is a `.999` pressure-release leaf pending curation. | | 8-31 | reserved | Must be zero. | ### 3.3 Hierarchy segments The twenty 16-bit segments encode the concept's position in its taxonomy's tree. Each segment holds a value 0-65535. The `depth` field indicates how many segments are meaningful; segments beyond `depth` must be zero. Segment values allocate by 10 (decimal 10, 20, 30, ...) leaving 1-9 and 11-19 as insertion points between published concepts. This is a published convention, not a binary-level requirement — the format allows any value 0-65535, but the published USAT1024 taxonomies follow the increment-by-10 practice. ### 3.4 External reference hashes Four 64-bit hashes record cross-references to external classification systems. Each hash is a SHA-256 truncated to 64 bits, computed over a UTF-8 encoded string of the form `{system_identifier}:{code}`. Allocation in version 1.0: | Offset within 256-bit block | System | |---|---| | 0-63 | ISCO-08 | | 64-127 | SOC-2018 (US) | | 128-191 | SNOMED CT | | 192-255 | ESCO | A hash value of zero indicates no cross-reference is recorded for that system. Additional external systems (O*NET-SOC, VeNom, NAICS) are carried in concept metadata outside the binary identifier. ### 3.5 CRC-32 check Bits 752-783 contain a CRC-32 computed over bits 0-751 using the IEEE 802.3 polynomial (`0x04C11DB7`, initial value `0xFFFFFFFF`, final XOR `0xFFFFFFFF`). Conformant implementations MUST validate the CRC on ingestion and MUST compute it correctly on emission. ### 3.6 Reserved extension Bits 784-1023 are reserved in version 1.0. They MUST be zero on emission and MUST be ignored on ingestion in version 1.0. Future USAT versions may assign fields in this region; the `binary_format_version` field allows parsers to detect version differences. --- ## 4. The canonical human-readable form The human-readable form uses a two-character uppercase taxonomy prefix followed by dot-separated three-digit decimal segments: ``` {PREFIX}.{SEGMENT}.{SEGMENT}.{SEGMENT}... ``` Example: `PC.100.010.010.010.010.010` ### 4.1 Structural rules - The taxonomy prefix MUST be exactly two uppercase ASCII letters (A-Z). - Each segment MUST be exactly three decimal digits, zero-padded. - Segments MUST be separated by a single ASCII period. - No trailing period is permitted. - Maximum depth is 20 segments. - The canonical regex for a USAT1024 human-readable code is `^[A-Z]{2}(\.[0-9]{3}){1,20}$`. ### 4.2 Binary-to-human conversion The human-readable form is derived from the binary form by: 1. Mapping `taxonomy_identifier` (bits 96-127) to its two-character prefix via the registry in §5. 2. Emitting each hierarchy segment's decimal value formatted to three digits, separated by periods, up to `depth`. ### 4.3 Human-to-binary conversion Conversion from human-readable to binary requires access to the concept record to populate the flags, external reference hashes, and CRC. The human-readable form alone does not carry enough information to reconstruct the full 1024-bit binary. ### 4.4 Citation form The citation form for a USAT1024 code in documents, publications, and regulatory filings is: ``` USAT1024-{TAXONOMY}:{VERSION}:{HUMAN_READABLE_CODE} ``` Example: `USAT1024-PC:1.0:PC.100.010.010.010.010.010` This form unambiguously identifies the taxonomy, the standard version under which the code was published, and the code itself. --- ## 5. Taxonomy registry (version 1.0) Version 1.1 of USAT1024 defines seven taxonomies. Each has a reserved two-character prefix and a unique 32-bit `taxonomy_identifier`. | Prefix | Taxonomy name | `taxonomy_identifier` | Domain | |---|---|---|---| | `PC` | Professional Concepts | `0x00000001` | Professional identity (what kind of professional an actor is) | | `TR` | Tenancy Roles | `0x00000002` | Relationship between an actor and an organization (platform authority) | | `PF` | Professional Function | `0x00000003` | Functional role an actor performs at an organization (job function) | | `LC` | License Categories | `0x00000004` | Categories of regulated professional licenses | | `LS` | License Scopes | `0x00000005` | Atomic authorized acts that licenses may grant | | `VC` | Verification Claims | `0x00000006` | Classifications of verifiable identity/credential claims | | `JC` | Jurisdictions | `0x00000007` | Regulatory/legal jurisdictions with authority | Values `0x00000008` through `0x7FFFFFFF` are reserved for future USAT1024 standard taxonomies. Values `0x80000000` through `0xFFFFFFFF` are reserved for implementation-defined extensions (not portable). ### 5.1 USAT1024-PC (Professional Concepts) Root: `PC.100 = profession`. Ten top-level branches in version 1.0: | Code | Branch | |---|---| | `PC.100.010` | animal_health | | `PC.100.020` | animal_welfare | | `PC.100.030` | animal_production | | `PC.100.040` | animal_retail_service | | `PC.100.050` | education | | `PC.100.060` | research | | `PC.100.070` | regulatory_government | | `PC.100.080` | legal | | `PC.100.090` | insurance | | `PC.100.100` | advocacy_nonprofit | Additional branches reserved at `PC.100.110` (animal_aftercare), `PC.100.120` (animal_transport), `PC.100.150` (general_occupation for cross-domain occupational classification), and `PC.100.160` (artificial_intelligence). Each branch has its own structure documented in the accompanying Unified Identity Backbone Design specification. ### 5.2 USAT1024-TR (Tenancy Roles) Small, shallow taxonomy covering platform authority relationships. Version 1.1 includes `platform_admin`, `platform_staff`, `owner`, `admin`, `manager`, `staff`, `volunteer`, `content_creator`, `operated_by` (for AI agents), and `contracted_service`. ### 5.3 USAT1024-PF (Professional Function) Universal occupational-function taxonomy, applicable to any organization regardless of domain. Covers executive leadership, finance, marketing, sales, customer service, technology, HR, operations, legal, administrative support, facilities, field/hands-on work, and trades/skilled labor. ### 5.4 USAT1024-LC (License Categories) Categories of regulated professional licenses: veterinary practice, specialty board certification, adjacent healthcare, federal registration, operational permit, paraveterinary certification. ### 5.5 USAT1024-LS (License Scopes) Atomic authorized acts that licenses may grant: clinical examination, prescribing, procedural, nursing technical, regulatory, pharmacy. ### 5.6 USAT1024-VC (Verification Claims) Classifications of verifiable identity and credential claims: identity, professional credential, business entity, nonprofit status, operating permit. ### 5.7 USAT1024-JC (Jurisdictions) Regulatory and legal jurisdictions (nation, state/province, county, municipality) with authority. --- ## 6. The concept/term/relationship data model ### 6.1 Concepts Every concept has: - A USAT1024 code (binary 1024-bit and human-readable forms) - A parent concept reference (except for taxonomy roots) - A depth - A leaf flag (true if no other concept references this concept as parent) - An active flag - An optional deprecated-replacement code - An internal description (not a display term) - Metadata (taxonomy-specific, including external references and any taxonomy-specific fields) - Provenance (source and reference) ### 6.2 Terms A term belongs to one concept and has: - The concept code it names - The term text - A locale (IETF BCP 47 language tag) - A term-type (see §6.4) - An optional context - An active flag - Provenance ### 6.3 Relationships A relationship connects two concepts with: - A source concept code - A target concept code - A relationship-type (see §6.5) - Optional notes and metadata - An active flag - Provenance ### 6.4 Normative term-types Conformant implementations MUST support these six term-types. Additional term-types MAY be supported but MUST be namespaced with an `x-` prefix. | Term-type | Meaning | |---|---| | `preferred` | Canonical display term for this (concept, locale, context). At most one per (concept, locale, context). | | `acceptable` | Alternate valid term. Multiple permitted. | | `colloquial` | Informal usage. Searchable but not preferred for formal display. | | `abbreviation` | Shortened form. | | `legal` | Legal or regulatory authoritative name. | | `historical` | Previously-used term, retained for data migration and search. | ### 6.5 Normative relationship-types Conformant implementations MUST support these six relationship-types. Additional relationship-types MAY be defined by issuing a USAT1024 minor-version update; they MUST be namespaced with an `x-` prefix until standardized. | Relationship-type | Meaning | Direction | |---|---|---| | `equivalent_to` | Source and target name functionally the same thing. | Symmetric | | `replaced_by` | Source is deprecated; target is successor. | Source → Target | | `requires_credential` | Source concept requires the subject to hold the target concept. Primarily USAT1024-PC → USAT1024-LC. | Source → Target | | `may_supervise` | Source is authorized to supervise subjects holding target. | Source → Target | | `part_of` | Source is operationally a component of target. | Source → Target | | `references` | Weak cross-reference without specific semantic claim. | Source → Target | ### 6.6 Uniqueness and exclusion constraints - A concept code is globally unique within its taxonomy. - At most one `preferred` term may exist for any (concept, locale, context). - A (concept, locale, term) triple is unique within its taxonomy's terms. - A (source, target, relationship-type) triple is unique within its taxonomy's relationships. - A concept MUST NOT have a relationship to itself. ### 6.7 The `.999 other_unspecified` convention Every non-leaf branch at every level of every USAT1024 taxonomy MUST include a `.999` child concept with the semantic meaning "other, unspecified; pending curation." This is the pressure-release mechanism ensuring the standard can absorb real-world classifications that do not yet have a specific concept. Users or systems classifying against `.999` concepts SHOULD include a free-text `self_description` in the claim for subsequent curation. When a new specific concept is added to the taxonomy, existing `.999` claims matching the pattern SHOULD be migrated to the specific code, with the original claim preserved in audit history. --- ## 7. AI agents as first-class actors ### 7.1 AI agents in USAT1024-PC Artificial intelligence agents are represented as concepts under USAT1024-PC branch `PC.100.160`. Each AI agent version is a distinct concept. The concept's `ai_agent` flag (flag bit 6) is set. Version-specific capability profiles are carried in concept metadata. ### 7.2 AI agents as platform users A conformant implementation treats AI agents as first-class platform users. Specifically: - An AI agent has a record in the implementation's users table with `user_type = 'ai_agent'`. - The AI agent holds a professional concept claim referencing its `PC.100.160.*` concept code. - The AI agent is a member of its developer organization (Anthropic, OpenAI, Google, Meta, or other) via the implementation's organization membership mechanism, with tenancy role `operated_by`. - The AI agent MAY additionally be a member of operator organizations via tenancy role `contracted_service`. ### 7.3 Version-as-identity A new AI version is a new concept — not an update to an existing concept. When Claude Opus 4.7 is retired and replaced by Claude Opus 5.0, two concept records exist: `PC.100.160.010.010.040` (Claude Opus 4.7, marked inactive with `deprecated_replacement_code` pointing at 5.0) and `PC.100.160.010.010.050` (Claude Opus 5.0, active). Historical audit records correctly identify which version performed which action. ### 7.4 Approved-use metadata A conformant implementation MUST attach `approved_platform_uses` metadata to each AI agent concept, enumerating the action categories the agent is permitted to execute. A conformant implementation MUST NOT permit an AI agent to execute an action category not in its approved-use list. --- ## 8. Bounded delegation (normative) ### 8.1 The two-gate principle For any action where an instructing actor delegates work to an executing actor, a conformant implementation MUST compute authorization as the logical AND of: - **Gate 1: instructing-actor authority** — whether the instructing actor would be authorized to perform the action directly. This gate considers the instructing actor's professional concept claims, verified credentials, organization tenancy, jurisdictional authority, and time-of-action. - **Gate 2: executing-actor permission** — whether the executing actor is permitted to perform the action in the applicable organization context. This gate considers the executing actor's own professional concept, administrator-configured policies, and (for humans) statutory scope-of-practice restrictions. The action is authorized only if both gates pass. If either gate fails, the action is denied. The denial MUST be audited with identification of which gate failed and the governing rule. ### 8.2 Reflexive delegation When the instructing actor and executing actor are the same entity, Gate 2 still applies. An actor cannot bypass their own permission restrictions by self-instruction. ### 8.3 Chained delegation When an instructing actor delegates to an executing actor who then further delegates, each link in the chain MUST pass both gates. The chain is audited link-by-link. ### 8.4 Administrator policy precedence Administrator-configured prohibitions in the implementation's permission tables MUST take precedence over individual actor authority. An administrator who sets a policy prohibiting AI agents from amending finalized medical records has caused that action to be denied even when an otherwise-authorized clinician attempts to delegate it. ### 8.5 Statutory precedence Statutory scope-of-practice restrictions (encoded via USAT1024-LS scope grants on USAT1024-LC license categories in applicable USAT1024-JC jurisdictions) MUST take precedence over organization-level administrator policy. An organization administrator cannot lawfully grant authority that statute withholds. ### 8.6 Ordering The precedence order is (from strongest override to weakest): 1. Statutory scope-of-practice 2. Administrator prohibition 3. Individual actor authority 4. Default permissive behavior (which does not apply in USAT1024 — the default is deny) --- ## 9. Interoperability and cross-references ### 9.1 External reference hashes in the binary code Four 64-bit external reference hashes are embedded in every USAT1024 binary code (§3.4). These enable rapid equivalence lookup across ISCO-08, SOC-2018, SNOMED CT, and ESCO without requiring access to the concept's full metadata. ### 9.2 Extended cross-references in concept metadata Additional external references beyond the four slots in the binary code are carried in concept metadata. Version 1.1 conformant implementations SHOULD populate `external_references` metadata with any or all of: - ISCO-08 code (redundant with binary; included for human inspection) - SOC-2018 code (US; redundant with binary) - O*NET-SOC code (US) - SNOMED CT concept identifier (redundant with binary) - ESCO URI (redundant with binary) - NAICS code (US industry classification) - VeNom code (UK veterinary clinical terminology) - HuggingFace model ID (for AI agent concepts) - Anthropic/OpenAI/Google/Meta API model string (for AI agent concepts) ### 9.3 Bidirectional cross-walks urSynergy publishes and maintains bidirectional cross-walk files mapping USAT1024 concepts to codes in each referenced external system. Cross-walks are available at `https://ursynergy.com/standards/usat1024/crosswalks/`. --- ## 10. License and citation ### 10.1 License USAT1024 — its specification, its code assignments, its term tables, its relationship definitions, and its cross-walk files — is published by urSynergy, Inc. for free use by any party for any purpose. Use of USAT1024 is subject to these conditions: 1. **Attribution.** Implementations that reference USAT1024 codes or claim conformance MUST cite USAT1024 by name and version (see §10.2). 2. **No modification without renaming.** A party that modifies the USAT1024 specification, adds to its code registry, or extends its taxonomies in incompatible ways MUST NOT represent the modified work as USAT1024. Extensions SHOULD be contributed back for curator review via the process in §11. 3. **No endorsement implied.** Use of USAT1024 does not imply endorsement of any implementation by urSynergy, Inc. 4. **No warranty.** USAT1024 is provided "as is" without warranty of any kind. ### 10.2 Citation format Citations to the USAT1024 specification: ``` USAT1024: Universal Standard Articulated Taxonomy, Version 1.1. urSynergy, Inc. Published 2026-04-21. https://ursynergy.com/standards/usat1024 ``` Citations to specific concepts: ``` USAT1024-PC:1.0:PC.100.010.010.010.010.010 ("Veterinarian") ``` --- ## 11. Governance ### 11.1 Maintainer USAT1024 is maintained by urSynergy, Inc. The maintainer is responsible for publishing the specification, coordinating curator review, issuing versioned releases, and operating the canonical URL. ### 11.2 Curator group Additions, deprecations, and cross-walk updates are proposed by a Curator Group that includes urSynergy staff and invited external curators from academic, regulatory, and industry bodies. The Curator Group meets at least quarterly. At version 1.0, the Curator Group charter is in formation; subsequent versions will name specific institutional participants. ### 11.3 Release cadence USAT1024 releases follow semantic versioning: - **Major version (X.0.0):** structural changes to the binary format, removal or renumbering of taxonomies, changes to normative term-types or relationship-types. - **Minor version (X.Y.0):** additive changes — new concepts, new taxonomies, new term-types/relationship-types defined through the curator process. - **Patch version (X.Y.Z):** corrections to terms, cross-walks, metadata; no code changes. Minor versions are released no more than twice per year. Patch versions are released as needed. ### 11.4 Addition process A party proposing a new concept, term, relationship, or cross-walk submits the proposal to the Curator Group via `https://ursynergy.com/standards/usat1024/propose`. The Curator Group reviews, accepts, revises, or declines proposals at its regular meetings. Accepted proposals are assigned codes and published in the next appropriate release. ### 11.5 Deprecation process Concepts are never deleted. A concept deemed incorrect or superseded is marked deprecated (flag bit 0 set), and a `deprecated_replacement_code` is published. Readers of USAT1024 data MUST be able to follow `deprecated_replacement_code` chains. --- ## 12. Conformance ### 12.1 Conformance claim An implementation that claims to conform to USAT1024 v1.0 MUST: 1. Support the 1024-bit binary code format per §3, including CRC validation and correct emission. 2. Support the human-readable form per §4, including bidirectional conversion. 3. Support all seven taxonomies in §5 (or a declared subset, with the subset listed in the conformance claim). 4. Support the concept/term/relationship data model per §6, including all normative term-types and relationship-types. 5. Enforce bounded delegation per §8, including the two-gate check, precedence ordering, and audit logging of grants and denials. 6. Treat AI agents as first-class actors per §7, if the implementation supports AI agents at all. 7. Carry external reference hashes per §3.4 and §9. 8. Cite USAT1024 by name and version in user-facing documentation that describes its classification behavior. ### 12.2 Conformance statement A conformant implementation SHOULD publish a conformance statement of the form: ``` [Implementation name] conforms to USAT1024 v1.0. Supported taxonomies: [list]. Supported locales for preferred terms: [list]. External cross-references populated: [list]. ``` ### 12.3 Non-conformance Implementations that adopt USAT1024 codes as informational references without implementing bounded delegation, the concept/term/relationship model, or the binary format are not conformant. Such implementations MAY cite USAT1024 but MUST NOT represent themselves as conformant implementations. --- ## 13. Reference implementation urSynergy, Inc. operates a reference implementation of USAT1024 within its identity backbone. The reference implementation is deployed across urbreed.com, lnfpet.com, theirlife.pet, ursmartid.com, myurpet.com, vetscript.net, animalrx.net, thevetregistry.com, and urpetlicense.com. Its schemas, service contracts, and migration patterns are published at the urSynergy developer documentation portal. The reference implementation is not the only way to build a conformant system; it is provided as an example. Conformance is determined by §12, not by similarity to the reference. --- ## 14. Temporal Authority Binding (normative) ### 14.1 Definition Temporal Authority Binding is the requirement that every action, record, order, citation, or delegated execution be evaluated against the authority state that exists at the exact time of execution, and that this authority state be preserved as an immutable component of the resulting record. A conformant implementation MUST treat authority as time-bound and MUST NOT evaluate past actions using current authority conditions. ### 14.2 Authority state at time-of-action At the moment an action is executed, the system MUST construct an authority evaluation using: - Actor identity (USAT1024-PC) - Tenancy role and/or professional function (USAT1024-TR, USAT1024-PF) - Credential and license category (USAT1024-LC) - Authorized scope(s) (USAT1024-LS) - Applicable jurisdiction(s) (USAT1024-JC) - Delegation chain (if present) - Verification status (USAT1024-VC) - Applicable policies, statutes, and rules - Execution timestamp The result of this evaluation is the authority state at time-of-action. ### 14.3 Binding requirement A conformant implementation MUST bind the authority state at time-of-action to the resulting record. ### 14.4 Immutability Once bound, the authority state MUST be treated as immutable. ### 14.5 Separation of temporal and current authority Systems MUST distinguish between current authority and historical authority. ### 14.6 Authority context envelope Each recorded action SHOULD include an authority context envelope capturing all relevant authority data. ### 14.7 Audit and interpretability Records MUST be auditable using stored authority context. ### 14.8 Interaction with bounded delegation Temporal Authority Binding MUST be applied after bounded delegation evaluation. ### 14.9 Prohibition of retroactive reinterpretation Past actions MUST NOT be reinterpreted based on future changes. ## 15. Changelog ### Version 1.1 (2026-04-21) Initial publication. Defines: - 1024-bit canonical binary code format - Dotted-decimal human-readable form - Seven taxonomies: PC, TR, PF, LC, LS, VC, JC - Concept/term/relationship data model with six normative term-types and six normative relationship-types - `.999 other_unspecified` convention - AI agents as first-class actors (USAT1024-PC branch PC.100.160) - Bounded delegation as normative authorization principle - External reference cross-walks to ISCO-08, SOC-2018, SNOMED CT, ESCO - Free-use license with required citation --- ## Appendix A: Complete binary layout reference ``` Bits Length Field ------ ------- ------------------------------------------- 0 32 magic (0x55534154 "USAT") 32 16 binary_format_version (0x0001) 48 16 usat_major_version (0x0001) 64 16 usat_minor_version (0x0000) 80 16 usat_patch_version (0x0000) 96 32 taxonomy_identifier 128 32 flags 160 8 depth 168 8 reserved_alignment 176 16 hierarchy_segment[0] 192 16 hierarchy_segment[1] 208 16 hierarchy_segment[2] 224 16 hierarchy_segment[3] 240 16 hierarchy_segment[4] 256 16 hierarchy_segment[5] 272 16 hierarchy_segment[6] 288 16 hierarchy_segment[7] 304 16 hierarchy_segment[8] 320 16 hierarchy_segment[9] 336 16 hierarchy_segment[10] 352 16 hierarchy_segment[11] 368 16 hierarchy_segment[12] 384 16 hierarchy_segment[13] 400 16 hierarchy_segment[14] 416 16 hierarchy_segment[15] 432 16 hierarchy_segment[16] 448 16 hierarchy_segment[17] 464 16 hierarchy_segment[18] 480 16 hierarchy_segment[19] 496 64 ext_ref_hash_isco08 560 64 ext_ref_hash_soc2018 624 64 ext_ref_hash_snomed_ct 688 64 ext_ref_hash_esco 752 32 crc32 784 240 reserved_extension ------ ------- ------------------------------------------- 1024 Total ``` ## Appendix B: Example encoding of PC.100.010.010.010.010.010 Human-readable: `PC.100.010.010.010.010.010` Citation form: `USAT1024-PC:1.0:PC.100.010.010.010.010.010` Meaning: Professional Concepts taxonomy → profession → animal_health → vet_med → clinical → licensed_physician Key binary fields: ``` magic = 0x55534154 binary_format_version = 0x0001 usat_major_version = 0x0001 usat_minor_version = 0x0000 usat_patch_version = 0x0000 taxonomy_identifier = 0x00000001 (PC) flags = 0x00000010 (requires_verification) depth = 0x06 reserved_alignment = 0x00 hierarchy_segment[0] = 0x0064 (100) hierarchy_segment[1] = 0x000A (10) hierarchy_segment[2] = 0x000A (10) hierarchy_segment[3] = 0x000A (10) hierarchy_segment[4] = 0x000A (10) hierarchy_segment[5] = 0x000A (10) hierarchy_segment[6..19] = 0x0000 (unused) ext_ref_hash_isco08 = SHA-256("isco08:2250") truncated to 64 bits ext_ref_hash_soc2018 = SHA-256("soc2018:29-1131") truncated to 64 bits ext_ref_hash_snomed_ct = SHA-256("snomedct:309343006") truncated to 64 bits ext_ref_hash_esco = SHA-256("esco:...") truncated to 64 bits crc32 = computed over bits 0..751 reserved_extension = all zeros ``` --- *End of USAT1024 Standard Specification, Version 1.1.*