Tagged architecture¶

Tagged architecture attaches type, permission, provenance, capability, or other metadata to machine words or memory objects and makes hardware operations interpret or enforce those tags during execution.

Version: v1 · 2026-09-28 · History
Domain-specific #: 12445
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomains: Computer Architecture, Memory Protection → Computer Science & Software Engineering

Core Idea¶

A tagged architecture is a computer architecture in which memory words, pointers, or other machine values carry protected metadata that identifies their type, interpretation, authority, or permitted use. Hardware propagates and checks the tag during load, store, arithmetic, branching, and memory access, so a bit pattern cannot automatically be treated as an instruction, integer, or valid reference merely because software casts it. Tags make semantic distinctions part of machine state rather than an informal convention maintained only by compilers.

Designs vary in granularity and enforcement. Historical Burroughs systems tagged control and data words to support high-level languages; Lisp machines distinguished pointers and immediate values; some processors reserved tag bits for pointer or data classification. Capability systems such as CHERI attach an unforgeable validity tag and bounds, permissions, and provenance to a capability, preventing ordinary byte stores from manufacturing authority. Memory-tagging schemes instead associate allocation tags with addresses and memory regions to detect mismatched or stale accesses. Garbage collection, dynamic typing, descriptor validation, compartmentalization, and code–data separation can all exploit tags, but they require different tag meanings.

A tagged architecture is not simply a language's type annotation, spare pointer bits controlled entirely by software, or a Harvard separation of program and data memory. Security depends on protecting tag integrity, defining propagation rules, and covering DMA, caches, serialization, and untagged interfaces; a tag does not prove that the underlying program logic is correct. Tags also consume storage or encoding space and can constrain compatibility. The abstraction is hardware-enforced semantic accompaniment: values carry machine-recognized evidence about what they are or may do, allowing operations to reject invalid interpretation or authority at the point of use.

Structural Signature¶

Sig role-phrases:

the machine value — word, pointer, instruction, or datum whose bit pattern admits multiple interpretations
the protected tag — metadata encoding type, provenance, validity, authority, or permitted use
the coupled machine state — value and tag traveling together through storage and computation
the hardware propagation rules — operation-specific production, preservation, transformation, or clearing of tags
the use-time check — load, store, arithmetic, branch, or dereference validated against semantic metadata
the unforgeability boundary — ordinary data operations prevented from manufacturing privileged tag state
the architecture-specific meaning — type classification, capability authority, memory-allocation match, or code–data distinction
the supported system service — dynamic typing, garbage collection, compartmentalization, bounds enforcement, or stale-access detection
the whole-system coverage problem — caches, DMA, serialization, and untagged interfaces required to preserve integrity
the cost envelope — storage, encoding, compatibility, and propagation complexity exchanged for machine-enforced semantic rejection

What It Is Not¶

Not merely source-language type annotation. The tag is part of protected machine state and is checked by hardware at use.
Not spare pointer bits under unrestricted software control. Unforgeability requires ordinary data operations to be unable to manufacture privileged tag state.
Not identical to Harvard code–data separation. Tagged systems can distinguish many semantic or authority classes within a shared address architecture.
Not one standardized tag meaning. Historical type tags, capability validity, and memory-allocation tags enforce different properties.
Not proof that tagged data or code is logically correct. Tags reject unauthorized interpretation or access, not every program error.
Not secure if enforcement stops at the processor core. Caches, DMA, serialization, storage, and untagged interfaces must preserve the intended integrity boundary.
Not costless metadata. Tag storage, encoding space, propagation logic, compatibility, and fault handling shape feasible designs.

Scope of Application¶

Tagged architecture applies when protected metadata accompanies machine values or memory locations and hardware uses it at operation time to enforce type, interpretation, validity, bounds, provenance, or authority.

Historical computer architecture. Burroughs and Lisp-machine designs show hardware support for high-level semantic distinctions.
Capability systems. CHERI-like validity tags combine unforgeability with bounds, permissions, and provenance.
Memory tagging. Address and allocation tags detect mismatched, stale, or cross-object accesses under a defined reuse policy.
Dynamic-language execution. Machine-visible type classes accelerate dispatch and reject invalid operations.
Garbage collection. Pointer-versus-immediate distinctions support tracing and descriptor validation.
Compartmentalization. Tagged authority constrains which objects or operations a component may reach.
Code–data integrity. Use-time checks prevent unauthorized reinterpretation under the tag model.
Applicability boundary. This is not a source annotation, forgeable spare pointer bits, or Harvard separation, and a valid tag does not prove program correctness; the design must specify granularity, protected update path, propagation, checked instructions, exceptions, cache and DMA behavior, serialization, context switching, revocation or reuse, compatibility, and the threat model whose invariants the tag actually enforces.

Clarity¶

Tagged architecture makes protected metadata about type, interpretation, authority, or permitted use part of machine state and hardware enforcement. It is not merely software type information, spare pointer bits, or a debugging annotation. Clarity requires tag granularity, who may create or alter tags, propagation rules for each operation, exception behavior, and interaction with caches and memory. The sharper architecture question is which illegal reinterpretations or authority amplifications hardware prevents and whether tag integrity survives every data path, context switch, and external interface.

Manages Complexity¶

Tagged architecture compresses semantic and authority checks into protected metadata carried with values. The machine tracks tag class, creation rights, propagation rules, permitted operations, and exception behavior; hardware then rejects illegal reinterpretation at use time. Type tags, pointer tags, capability tags, memory-coloring tags, and information-flow labels form branches with different security goals. This structure prevents every instruction sequence from re-proving software invariants and makes violations local and diagnosable, while implementation review focuses on whether tags survive caches, registers, context switches, direct memory access, and external interfaces.

Abstract Reasoning¶

Tag-reading move. Interpret metadata attached to a word, pointer, capability, or memory unit before operating on its payload. Dispatch move. Use tags to select type-specific operations, access rules, representation, or garbage-collection treatment. Safety move. Detect invalid combinations or unauthorized uses at hardware, runtime, or language boundaries. Layout move. Trade tag width, alignment, address space, and checking cost against expressiveness and protection. Boundary move. Tagged architecture is not merely a software type annotation or a label in documentation; the tag must participate in machine or runtime semantics, and tags do not eliminate all memory errors.

Knowledge Transfer¶

Within the home domain. Tagged architecture transfers across processors, virtual machines, capability systems, garbage-collected runtimes, and dynamic-language hardware where metadata attached to words or references changes permitted interpretation or operation. Payload, tag, dispatch, access check, memory layout, and exception retain mechanistic roles. Beyond the home domain (B — shared abstract mechanism). Type-tagged data and labeled objects also pair content with control metadata, sharing metadata-governed semantics. Hardware enforcement, pointer representation, and machine instructions remain home-bound. A software annotation is not itself a tagged architecture, and tags do not guarantee full memory safety or semantic correctness.

Examples¶

Canonical¶

A capability machine stores an address together with a protected tag marking it as an authorized reference and encoding bounds or permissions. Loads, stores, arithmetic, and dereferences propagate or check the tag by architecture-defined rules. Treating ordinary integer bits as an address cannot forge the capability because regular operations cannot manufacture the privileged tag. If an operation invalidates provenance, hardware clears or rejects the tag. The semantic metadata travels with the value, making authority part of machine state rather than a compiler-only convention.

Mapped back: Address is the machine value, capability metadata the protected tag, and pair the coupled machine state. Operations follow the hardware propagation rules and the use-time check, while nonmanufacturability is the unforgeability boundary.

Applied / In Practice¶

An operating system uses tags for memory bounds and compartment authority. Designers audit caches, context switches, DMA, swapping, serialization, and devices so untagged interfaces cannot silently strip or counterfeit metadata. Compatibility shims and extra storage create costs, but invalid dereferences and stale access are rejected by hardware. Another tagged architecture may instead mark code versus data or aid garbage collection, so tag meaning is never inferred generically.

Mapped back: Bounds/capabilities are the architecture-specific meaning supporting the supported system service. Cache/DMA/interface auditing addresses the whole-system coverage problem, and storage/compatibility expose the cost envelope.

Structural Tensions¶

T1 — Identity versus admissible variation. Tagged architecture must remain recognizable across legitimate variants. Admissible variation is bounded by this condition: Burroughs and Lisp-machine designs show hardware support for high-level semantic distinctions. The stable element is expressed by this invariant: Tagged architecture attaches type, permission, provenance, capability, or other metadata to machine words or memory objects and makes hardware operations interpret or enforce those tags during execution. Treating every surface change as a new abstraction fragments the identity, while allowing a change to the constitutive relation produces a false positive.

Diagnostic: After the proposed variation, can an analyst still establish this invariant: Tagged architecture attaches type, permission, provenance, capability, or other metadata to machine words or memory objects and makes hardware operations interpret or enforce those tags during execution?

T2 — Recognition versus proxy. The domain needs observable or inferential evidence for Tagged architecture, but the evidence is not automatically the identity. The working recognition rule is: the unforgeability boundary — ordinary data operations prevented from manufacturing privileged tag state. A familiar indicator can occur without the defining relation, and the relation can persist when a customary detector is unavailable.

Diagnostic: Does the evidence establish the defining claim—Tagged architecture attaches type, permission, provenance, capability, or other metadata to machine words or memory objects and makes hardware operations interpret or enforce those tags during execution—or only a correlated sign?

T3 — Definition versus operational judgment. A compact definition aids reuse, whereas actual classification in computer architecture can require expert decisions about boundary conditions, measurements, conventions, or exceptions. Designs vary in granularity and enforcement. The definition must constrain those judgments without pretending that every admissible case can be recognized from a label alone.

Diagnostic: Which observation would make a competent practitioner reject the classification under the stated definition?

T4 — Scope versus overextension. Tagged architecture has a genuine habitat in which burroughs and Lisp-machine designs show hardware support for high-level semantic distinctions. Yet This is not a source annotation, forgeable spare pointer bits, or Harvard separation, and a valid tag does not prove program correctness; the design must specify granularity, protected update path, propagation, checked instructions, exceptions, cache and DMA behavior, serialization, context switching, revocation or reuse, compatibility, and the threat model whose invariants the tag actually enforces. A useful application map therefore has to be broad enough to cover recurring practice and narrow enough to exclude merely topical or metaphorical occurrences.

Diagnostic: Can the claimed application fill the same carrier and relation roles, or has only the name traveled?

T5 — Transfer versus domain accent. Knowledge about Tagged architecture can travel within its home domain, and some structural lessons may travel farther. Tagged architecture transfers across processors, virtual machines, capability systems, garbage-collected runtimes, and dynamic-language hardware where metadata attached to words or references changes permitted interpretation or operation. What transfers must be separated from the specialist vocabulary, warrant, and closure conditions that remain anchored in computer architecture.

Diagnostic: Is the receiving case a literal instance of Tagged architecture, a co-instance of Classification, or only an analogy?

T6 — Autonomous identity versus forced placement. Tagged architecture has a stable source-domain identity—Tagged architecture attaches type, permission, provenance, capability, or other metadata to machine words or memory objects and makes hardware operations interpret or enforce those tags during execution.—but no current live node supplies a necessary genus or structural prerequisite without distortion. Leaving the node unattached preserves the accepted identity and exposes a real gap in the present DAG rather than hiding it under a merely topical parent.

Diagnostic: Would the proposed parent be true of every Tagged architecture instance for a reason stronger than shared vocabulary or subject matter?

Structural–Framed Character¶

Tagged architecture is structural-leaning, with a bounded disciplinary frame. Its structural side consists of the carrier the machine value — word, pointer, instruction, or datum whose bit pattern admits multiple interpretations and the constitutive relation Tagged architecture attaches type, permission, provenance, capability, or other metadata to machine words or memory objects and makes hardware operations interpret or enforce those tags during execution. Its framed side comes from computer architecture, which fixes what the terms denote, what counts as evidence, and when a qualification or exception defeats the classification.

Across the principal tests, the entry is not merely a free-floating pattern. Evaluative weight: the identity can be stated descriptively even when its use has practical or normative consequences. Practice dependence: the unforgeability boundary — ordinary data operations prevented from manufacturing privileged tag state. Institutional stabilization: disciplinary conventions may stabilize the name and test without necessarily creating every underlying event or relation. Vocabulary portability: the invariant is Tagged architecture attaches type, permission, provenance, capability, or other metadata to machine words or memory objects and makes hardware operations interpret or enforce those tags during execution. Import versus recognition: an outside case qualifies literally only if the same typed roles and collapse condition are available; otherwise the comparison is analogical.

No current parent captures the reusable remainder without losing or distorting the defining relation. Tagged architecture is therefore admitted as an approved unparented root. This is an explicit graph disposition, not a claim that the abstraction has no relations or that a later densification pass cannot discover one.

Structural Core vs. Domain Accent¶

What is skeletal. The portable skeleton is a typed carrier organized by a constitutive relation, an invariant, a recognition test, and a collapse condition. Here the carrier is the machine value — word, pointer, instruction, or datum whose bit pattern admits multiple interpretations. The decisive relation is Tagged architecture attaches type, permission, provenance, capability, or other metadata to machine words or memory objects and makes hardware operations interpret or enforce those tags during execution, which also states the controlling invariant at this level. Stripped of specialist nouns, this organization is represented by Classification.

What is domain-bound. computer architecture supplies the actual objects or agents, admissible transformations, units or conventions, standards of warrant, and named exceptions. In this case, recognition requires evidence for the unforgeability boundary — ordinary data operations prevented from manufacturing privileged tag state. Admissible variation is bounded by the condition that burroughs and Lisp-machine designs show hardware support for high-level semantic distinctions, and the classification collapses when the tag is part of protected machine state and is checked by hardware at use. These are constitutive differentia, not illustrative decoration.

Why it remains a domain-specific node. The identity is stable within computer architecture, but no current live parent passes the necessary-relation test. The node is therefore an approved unparented root; future placement must preserve the unforgeability boundary — ordinary data operations prevented from manufacturing privileged tag state rather than attach the name by topical similarity.

This entry is a kind of Computer architecture.

Reviewed placement — approved unparented root. No current live node supplies a defensible necessary genus or structural prerequisite for Tagged architecture. The reviewed identity is: Tagged architecture attaches type, permission, provenance, capability, or other metadata to machine words or memory objects and makes hardware operations interpret or enforce those tags during execution. Attaching it to the accelerated suggestion would confuse topical similarity with hierarchy; the node is therefore admitted without a parent pending later graph densification.
Nearest catalog surface declined — domain_specific:machine_check_architecture. Its rematch score was 0.168533. Retrieval proximity did not establish synonymy or parentage; the carrier, invariant, and collapse condition remain different.
Related reasoning operations. Evidence, comparison, boundary testing, and representation can support a case without becoming additional DAG parents.

Relationships to Other Abstractions¶

Current abstraction Tagged architecture Domain-specific

Parents (1) — more general patterns this builds on

Tagged architecture is a kind of Computer architecture Domain-specific

Tagged architecture is a domain-specific kind of computer architecture under its frozen identity and differentia. Complete-catalog comparison found the corresponding live broader identity.

Hierarchy path (1) — routes to 1 parentless root

Tagged architecture → Computer architecture

Neighborhood in Abstraction Space¶

Tagged architecture sits in a moderately populated region (47^th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Digital Circuit & Memory Architecture (12 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With¶

A forced generic parent. No current live node passed the necessary-relation test. Tell: do not infer hierarchy from shared subject matter, method words, or retrieval proximity; preserve Tagged architecture as an approved root until a genuine broader identity is available.
Tagged Union. This is the closest catalog retrieval surface, not an accepted synonym or parent. Tell: Ask which entry's carrier, invariant, and collapse test the case actually satisfies; shared vocabulary or a score of 0.771333 is insufficient.
Not merely source-language type annotation. The tag is part of protected machine state and is checked by hardware at use. Tell: Require the positive recognition condition that the unforgeability boundary — ordinary data operations prevented from manufacturing privileged tag state.
Not spare pointer bits under unrestricted software control. Unforgeability requires ordinary data operations to be unable to manufacture privileged tag state. Tell: Replace the familiar surface feature and test whether tagged architecture attaches type, permission, provenance, capability, or other metadata to machine words or memory objects and makes hardware operations interpret or enforce those tags during execution.
A detector, representation, or consequence. A method may reveal Tagged architecture, a notation may describe it, and an outcome may follow from it without any of those being identical to the abstraction. Tell: Would the defining relation remain if the present detector, notation, or downstream effect changed?
A metaphorical transfer. A case outside the home domain may resemble the structure while lacking its native role types and standards of warrant. Tell: If only the general organization survives, route the comparison to Classification rather than treating it as another Tagged architecture instance.

References¶

Frozen Wikipedia revision: https://en.wikipedia.org/wiki/Tagged_architecture (revision 1364179895).
Supporting reference preserved in the packet: https://www.memorymanagement.org/glossary/t.html#tagged.architecture
Supporting reference preserved in the packet: http://www.feustel.us/Feustel%20&%20Associates/Advantages.pdf
Supporting reference preserved in the packet: https://web.archive.org/web/20130523121127/http://www.feustel.us/Feustel%20&%20Associates/Advantages.pdf
Supporting reference preserved in the packet: http://www.feustel.us/Feustel%20&%20Associates/R2.pdf
Supporting reference preserved in the packet: https://web.archive.org/web/20150924012031/http://www.feustel.us/Feustel%20&%20Associates/R2.pdf
Supporting reference preserved in the packet: https://bitsavers.org/pdf/burroughs/LargeSystems/B5000_5500_5700/5000-21005_B5000_operChar_1963.pdf
Supporting reference preserved in the packet: https://bitsavers.org/pdf/burroughs/LargeSystems/B5000_5500_5700/1021326_B5500_Reference_Manual_196809.pdf
Supporting reference preserved in the packet: http://www.princeton.edu/~adam/R1/r1rpt.html

The frozen Wikipedia revision is discovery provenance. The cited source set was reviewed for identity, formal or operational relation, and scope. The encyclopedia's structural synthesis is bounded to those claims; URL transport failure alone was not treated as substantive contradiction.