Silicon Ledger: Ontologies for Semiconductor Design From Specification to Tapeout

Traceability From Specification to Tapeout Breaks Silently

A specification change lands in one place while its consequences surface in another, because no system the operator runs holds the requirement, its implementation and its proof together.

The abstract promised one governed model of the design, from specification to tapeout, owned outright by a fabless chip design company in Saudi Arabia and running on its own hardware. Ontologies for semiconductor design are what that promise takes literally, and this chapter states the problem such a model exists to solve: the trace a verification lead needs breaks silently between the tools that hold its pieces, and nobody sees it break.

1.1  The Question, the Data and the Regimes

The question the operation needs answered is narrow and daily: when an interface requirement changes on one block, which signals, checks, tests, coverage holes, open bugs and waivers does that change touch, and which requirements in the affected area have no proof at all. Answering it requires data no single system holds: specification sections and their revisions, requirement records with owners, the blocks, interfaces and signals that implement them, the checks and tests that prove them, coverage findings, bug records, waivers with justifications, and the revision history that binds the whole into a sequence of defensible states. Each fact must carry the tool, file and revision it came from, or the answer is an opinion. The regulatory ground is threefold. The kingdom's data protection law applies because the model holds people's decisions, and an impact assessment under its access provisions runs before go live. Export control applies to the compute itself, since the GPU class the design needs is a licensable item for its destination and a license determination is a named checkpoint. Trade secret law governs the record end to end, in the kingdom and wherever the design might travel, and the European directive codifying protection of undisclosed know-how is the reference regime the industry designs against (Europa 2016).

1.2  The Documented Cost

The cost of this problem has two documented faces. The first is the cost of the record leaving control: a foundry and its engineers pleaded guilty in the United States to trade secret theft and paid a 60 million dollar fine (Reuters 2020), a parallel Taiwanese proceeding fined the same company NT$100 million (Bloomberg 2020), and final sentences were handed down years later to former employees of another chipmaker in a separate leak (Focustaiwan 2026). Those cases are why design data cannot ride a hosted model service, and why the join must be built inside the boundary rather than exported to whoever can compute it. The second face is the cost of the join failing in place: escaped bugs found after tapeout instead of in verification, waivers that expire without anyone noticing, and requirements that reach silicon with no check ever having proved them. Regulators and funding bodies now write these expectations down: the United States commerce department's protection guidebook ties semiconductor funding to research security requirements, including access controls and provenance of technical data (NIST 2024). An operator of this class is expected to know where its design record came from and who touched it.

1.3  The Operation as a Scenario

The operator is a fabless semiconductor company in Saudi Arabia: it designs silicon in vendor design tool suites, verifies through simulation and formal tools, and hands tapeouts to an outside foundry whose relationship stays its own. Its specifications run to hundreds of pages and keep changing, which is the root of the traceability problem. The design reads five named source systems: the shared specification drives, the requirements site, the version control system, the bug records and the vendor design tool suites. Three roles are named in the loop: the verification lead who approves every check before it enters the regression, the design engineers who confirm each extracted requirement before it is used, and a senior verification expert who is the escalation path when the approval queue ages. The physical environment is one place, a design office and the company's own server room on its own premises; there is no fab floor, no cameras and no physical sensing, and the only location that matters is which block and which project a record belongs to. The regulatory ground combines the kingdom's data protection law, the export control determination on the GPU node, and trade secret regimes enforced by courts on three continents against companies exactly this size.

Every Tool Sees One Slice of the Chip

The specification drives, the requirements site, version control, the bug records and the vendor tool suites each hold part of the design record, and the join verification needs exists in none of them.

Chapter 1 stated the question and the documented cost of not answering it. This chapter shows why no system the operator runs today can answer it: each of the five holds one slice of the record, and the join verification needs exists in none of them, as Figure 2 sets side by side.

2.1  One Slice Per System

The shared specification drives hold the specification documents themselves, hundreds of pages revised as files. They see section text, owning authors and the revision history of each document, and they miss everything downstream: no file on a drive says which block implements a section, which signals carry an interface, or which check proves a requirement. The requirements site holds the structured requirement records with ids and owners. It sees the requirement text and its edit history, and it misses the implementation, the proof, and the specification revision and page each requirement was extracted from, so a requirement edited in the site silently diverges from the specification it came from. The version control system holds the design as it is: RTL file paths, blocks, interfaces, signal lists, design revisions, and the assertions the agents would draft. It sees structure and history, and it misses intent, because a commit message carries no requirement linkage and nothing in the tree says what the design is for. The bug records hold open bugs by block with severity and whether each was found in verification or after tapeout. They see failures, and they miss the context that would classify one: whether a bug is a coverage gap, a spec change nobody traced, or a waived check whose waiver expired. The vendor design tool suites each run simulation, formal verification and coverage in their own formats. Each sees its own runs and findings, and each misses the cross-vendor record; no tool's output cites a requirement id, and the vendor-neutral layer that would join them does not exist on any vendor's roadmap, because it is not any vendor's product.

2.2  What None of Them Sees Together

What no system sees is the whole argument: requirement to block to signal to check to test to coverage, each fact carrying the tool, file and revision it came from, with bugs and waivers hanging off the same trace. In practice the cost lands as manual work and late discovery. An interface change arrives and its impact list is assembled by hand across drives, sites and tools, so blocks are missed and the misses surface as escaped bugs found after tapeout, the most expensive kind. Requirements with no proof are invisible until they fail. Waivers age past expiry with no owner alerted. The verification lead cannot answer the daily question without days of cross-referencing, which is exactly the delay a change cycle cannot absorb.

Sovereignty and Vendor Neutrality Shape Everything Downstream

Four goals, design data staying in Saudi Arabia on the company's own hardware, vendor neutrality under the existing design tools, named approvals for every check, and a cheap first gate, are each hard in semiconductors and shape every choice after them.

Chapter 2 showed the join failing across five systems that each see one slice. This chapter states the four goals that shape every choice made after them, each hard in semiconductors for its own reason, and then the scoping decisions and rejected alternatives those goals force.

3.1  Design Data Stays on the Company's Own Hardware

The first goal is sovereignty in the literal sense: specifications, designs and models stay in Saudi Arabia on the company's own hardware, and nothing crosses outward. This is hard in semiconductors because the data is the company's core intellectual property and the industry's record of losing it is a matter of court records, from a 60 million dollar guilty plea (Reuters 2020) and a NT$100 million fine in a parallel proceeding (Bloomberg 2020) to final criminal sentences for leaked process knowledge (Focustaiwan 2026). The practical consequence is that no hosted frontier model service is available at any price, and the compute must be owned: one node of eight GPUs of the 141 GB high bandwidth memory class, drawing roughly ten kilowatts that the company's own facilities team must bear, and licensable under export controls, so the license determination is a named phase one checkpoint before any class is quoted. Funding regimes elsewhere now write such controls into contract terms (NIST 2024), and the operator's own constraint settles the question before it is argued.

3.2  Vendor Neutrality Under the Existing Design Tools

The second goal is that the model sits under the vendors' own tools and agents, so any of them can work from it. This is hard because an EDA estate is a set of vendor suites, each with its own property languages and formats, and a model bound to one vendor's syntax locks the operator into that vendor and breaks the goal. The design therefore drafts tool-neutral assertions into the version-controlled source and runs them in the existing regression, and the integration is the exposure of the ontology beneath the vendors' tools rather than a connector into any one vendor's silo. Each vendor's license terms are confirmed in discovery before its connector is built, because terms that restrict reading a vendor's outputs into a company-owned model would change the design, not the ambition.

3.3  Named Approvals for Every Check

The third goal is that agents draft and people decide: an engineer confirms each extracted requirement before it is used, and the verification lead approves every check before it enters the regression. This is hard because the control is structural, not cosmetic. A misread specification propagates into requirements, checks, coverage and impact lists, and the confirmation step is the only point where the error is caught cheaply, so the engineer rejection rate is a monitored gate signal rather than a courtesy. The bottleneck risk is equally real, since a single approver can age a queue: queue depth and ageing sit on the observability stack, and escalation to the senior verification expert after five working days is the designed relief.

3.4  A Cheap First Gate

The fourth goal is a first gate that can stop the work cheaply. This is hard in an industry where the temptation is to model the whole chip at once. Phase one is one block and one revision cycle, with baseline measures bound before any extension, and the simulated event that proves the design is deliberately small: one interface requirement change on one block. If the model cannot carry that trace end to end with citations, extension to the full chip would only scale the failure.

3.5  Scoping Decisions

Three scoping decisions follow from the four goals, each buying something specific at a stated cost, and Table 1 sets them out. Designs of this shape are still rare among industrial ontology examples precisely because most stop at the document layer and never reach the proof, which is the trade these rows refuse.

3.6  What the Design Chose Against

Each major choice was made against a live alternative, and Table 2 records the four that matter plus the boundary itself. The last row is the out-of-scope statement, read as a decision rather than a disclaimer: the design models the record from specification to tapeout and supplies none of the tools that make the silicon.

One Stack Runs From Records to the Command Center

Systems of record sit below, one governed object model sits in the middle, and agents, services and surfaces run above it, all inside the company's perimeter with no edge estate and no hosted service.

Chapter 3 fixed the constraints: sovereign on the operator's own hardware, vendor neutral under the existing design tools, an engineer confirming every extraction, and proof on one block before any chip-wide extension. This chapter lays out the stack those constraints produce, because the practical question behind ontologies for semiconductor design is not which component to buy but where each layer sits relative to the systems of record, and the answer here is a deliberately plain shape: records below, one governed model in the middle, agents and services above, with nothing outside the perimeter.

4.1  The Pattern and Why It Fits

The stack runs in three bands, and Figure 3 shows the layered whole with a count on every layer. Below sit the five sources: the shared specification drives, the version control system, the requirements system of record, the defect tracker and the vendor design tool suites, all read-only and all owned by the operator. In the middle sits one object model of sixteen objects with typed links, held in Hyper Ontology v0.9 (Semantics plus Kinetics), which is the only place in the estate where a requirement, the block that implements it and the check that proves it are neighbors. Above it run eight services, three surfaces and three agents, with GLM 5.3 serving every one of them. The pattern fits because the operator's problem is a join failure, and the pattern puts the join in one place that the operator owns and that any vendor's tools can read from beneath their own interfaces. It also fits the published landscape: most industrial ontology examples in this sector concentrate on fab-floor data, and the integration shelf behind them holds connectors for fab-floor systems with nothing for a fabless design estate, so this design builds its connector per source rather than inheriting one. The inference arithmetic keeps the whole stack in one room: GLM 5.3 carries a filed count of 753B parameters at FP8, one byte per parameter, so the weights alone are 753 GB; a single node of eight 141 GB GPUs holds 1,128 GB, leaving 375 GB beside the weights for KV cache and activations against the roughly 151 GB that the 1.2 planning factor reserves. Table 7 carries the layer-by-layer register, with the component, the choice and the reason for every layer the platform prints it against.

4.2  The Stack Stage by Stage

Table 3 walks the same stack stage by stage, from the records the operator already keeps to the surfaces its verification lead actually reads. Two stages are worth naming before the table: the sensing stage exists only to record that nothing physical is sensed, and the adapters stage is the single door through which every fact passes. The stages and their components are set out in Table 3.

4.3  A Reusable Pattern

The shape a team carrying a similar brief can reuse is the order of the bands, not their contents. Read-only systems of record sit below; one adapter family is the only door between them and the model, and it stamps provenance on every fact; one governed object model holds the vocabulary of the vertical; agents draft above it, and a named person approves every draft before it becomes a write; every weight runs self-hosted inside the operator's own perimeter. A team swaps the object vocabulary, since sixteen objects chosen for a chip's life from specification to tapeout will not fit a mine or a fleet, and swaps the source list and the model sizing to its own hardware. What it keeps, unchanged, are the three controls that make the model trustworthy rather than merely fluent: the adapter-only door, the approval-only write path, and the reconciliation run after every sync cycle. Those three are independent of industry, and they are the part of this design worth copying first.

Sixteen Objects Turn Design Records Into One Argument

Sixteen objects with typed links carry the lineage from requirement to block to signal to check to test to coverage, so a query can traverse what a document store cannot.

Chapter 4 placed the object model at the center of the stack and put a count on every layer. This chapter opens that center: the sixteen objects, the typed links between them, and the human approvals that stand at the only points where the model is allowed to change.

5.1  Every Object and Its Typed Links

The model holds sixteen objects: the specification section, requirement, design block, interface, signal, design assumption, verification check, test, coverage result, bug, waiver, design revision, engineer, verification lead, expert lesson and foundry handoff. Each is anchored where its record already lives: the specification section in the shared drives, the requirement in the requirements system of record, the design block, interface, signal, verification check, test and design revision in the version control system, the coverage result in the simulation and regression environment, the bug in the defect tracker, and the expert lesson in a kept record of decisions and outcomes that the next decision reads. Figure 4 shows every object and its typed links, with the verification check as the focal object, and Table 8 carries the same register as object, anchor and links. The links are what a document store cannot hold. The simulated event makes this concrete: one interface requirement changes on one block, and a query starts at the changed requirement, walks back to the specification section and the design revision that produced it, out through the linked verification checks that claim to prove it, on to the tests that run those checks and the coverage result each test produced, across to the signals on the affected interface and the blocks that implement them, and finally to the bugs already filed and the waivers that excuse anything still failing. A document store can return pages that mention the requirement; it cannot walk that chain, so it cannot answer the two questions that decide a tapeout: which requirements have no proof at all, and which impact lists were built from a revision the systems of record have since superseded.

5.2  The Human Loop and the Hosting Posture

The human loop lives at exactly two points, both named in the requirement and both structural. When the spec agent reads a new specification revision into requirements, an engineer confirms each one before it is used anywhere, and the rejection rate is a monitored signal and a phase one gate rather than a courtesy, because a misread requirement propagates into checks, coverage and impact lists. When the check agent drafts a tool-neutral assertion into version control, the verification lead approves every one before it enters the regression, and queue depth and ageing are watched on the observability stack with an escalation path to the senior verification expert after five working days so one approver cannot become the bottleneck. The hosting posture follows from what the objects hold. Everything runs on the company's own hardware on its own premises in Saudi Arabia; identity is carried by Keycloak; there are no external links, and nothing crosses outward, with Harbor's offline installer governing what comes in as the artifact and model registry. The only write path into the regression is the approval-gated one through version control. That posture is not stylistic: design data is the operator's core intellectual property, and the sector's trade secret record includes criminal findings and a 60 million dollar fine in one case (Reuters 2020) and final Supreme Court sentences in another (Focustaiwan 2026), while research security guidance for funded programs treats exactly this class of asset as requiring documented protection (NIST 2024). Need-to-know partitioning per project and block is enforced in the schema, mirroring the existing tool permissions, with a PDPL Article 25 impact assessment before go live.

5.3  One Object in Its Recorded Form

The verification check is the object where the design's guarantees meet, since it carries the assertion, its tool-neutral form, the requirement it claims to prove, its author and its approver, and a status ladder whose vocabulary, from Drafted through Awaiting approval and Approved to In regression, Failing and Waived, encodes the human loop in the record itself. Its recorded form, as the platform prints it below, shows every property and link.

{ "id": "specification-section", "label": "Specification section", "kind": "document", "anchored_in": "The shared drives for specifications", "properties": [ "Section number", "Specification revision", "Source document and page", "Owning author", "Status" ], "status_vocabulary": [ "Draft", "Released", "Superseded" ], "links": [] }

Every Source Enters Through an Adapter, Never Directly

Each of the five source systems is read through the integration adapter family, which stamps every fact with its tool, file and revision and reconciles the model against the systems of record after every sync cycle.

Chapter 5 described what the object model holds and where the approvals sit. This chapter describes how data reaches it: every source enters through the integration adapter family, never directly, and every fact arrives stamped with the tool, file and revision it came from.

6.1  Five Sources, One Adapter Family

All five sources are operator-owned and read-only, and Figure 5 maps each one to its provenance class and its adapter path. The shared specification drives hold the specification documents the spec agent reads; a chip specification runs to hundreds of pages and keeps changing, so every read is versioned against the drive's own state. The version control system is the system of record for blocks, interfaces, signals and revisions, and it is also the destination of the assertions the check agent drafts, which keeps the drafted checks inside the same review machinery as the design itself. The requirements system of record is projected rather than replaced: the ontology reads it and holds the requirements as objects with traceability links, but the operator's system remains authoritative. The defect tracker supplies open bugs by block to the command center, and the escaped bugs found late become one of the baseline measures bound in phase two, after the pilot proves the model. The vendor design tool suites are integrated by exposure rather than connection: the model sits under the vendors' own tools and agents, so any of them can work from it, which is what vendor neutrality means in practice. Phase one reads only the files and repositories the operator already owns, fixed at intake, which keeps the first gate cheap.

6.2  What the Adapter Tier Guarantees

The adapter tier guarantees three things. First, provenance: every fact carries the tool, file and revision it came from, which is what lets a requirement trace to what implements it and what proves it, and what lets the conversational interface cite the record rather than assert from memory. Second, reconciliation: a reconciliation job runs after every sync cycle, comparing the model against the systems of record, and impact lists built from unreconciled revisions are automatically flagged stale and excluded from citations, so a drifting model cannot silently mislead the verification lead. Third, legality: design tool and foundry license terms can restrict reading a vendor's records or outputs into a company-owned model, so each vendor's terms are confirmed in discovery before its connector is built, and phase one touches nothing beyond the operator's own files. The write path is narrower still: the assertions the check agent drafts enter version control only through the verification lead's approval, and no agent changes a design file or the regression without it.

6.3  The Event Backbone

Ordering, delivery and replication are carried by Apache Kafka 4.3.x running in KRaft mode with three dedicated controllers and a dynamic quorum, so the cluster tolerates a controller change without losing the log. Ordering of revisions and approvals is carried by the backbone's own sequencing together with the version control system's commit order, which is why the design needs no sensor time synchronization: the only ordering that matters is which revision came before which approval. Events are held in a replicated, replayable log, so a service that falls behind resynchronizes by replaying rather than by asking the sources again, and buffering survives the gap between a sync cycle and the consumers that read it. Service health is carried by the observability layer of Prometheus v3.15.0, Grafana v13.2.3 and Loki v3.7.8, since no machine telemetry is in scope, and identity on site is carried by Keycloak. The one boundary that exists, the artifact and model registry, is governed by Harbor with its offline installer: updates and model artifacts come in through it, inspected, and nothing goes out. That asymmetry is the design's answer to the sector's documented loss pattern, in which design secrets leaving a perimeter ended in criminal convictions (Bloomberg 2020); here the perimeter is the operator's own, and there is no outward path to guard or to leak through.

All Reasoning Stays Inside the Company's Perimeter

Every weight runs self-hosted on one node of eight 141 GB HBM-class GPUs on the company's own premises, with the memory arithmetic to prove it and no design data crossing the boundary in any direction.

Chapter 6 described how every source enters through the adapter tier and lands in the object model with its tool, file and revision attached. This chapter describes where the reasoning itself runs, and why the answer is one room: the company's own server room, on its own hardware, with the memory arithmetic that proves the frontier model fits and nothing crossing the perimeter in either direction.

7.1  Three Tiers, One Room, One Node

The design has no edge estate, so its inference tiers are separated by function rather than by location, and all of them run inside the company's premises on hardware the company owns. The central tier is GLM 5.3, the 753B-parameter work surface model, served on vLLM from one node of eight GPUs of the 141 GB HBM class; it carries the spec agent that reads specification revisions, the check agent that drafts tool-neutral assertions, and the natural language answers the verification lead asks for. The retrieval tier is BGE-M3, which embeds specifications, requirements, checks and records so that every answer can cite the record it came from; it is small enough to run on CPU or a modest GPU beside the serving node. The document parsing tier is PaddleOCR-VL 1.6, which turns the hundreds of pages of a chip specification into structured text at ingestion, and which also fits on a site GPU. Figure 6 sets the three tiers side by side with what runs on each.

The memory arithmetic settles the central tier's size, and it is worth stating in full because it is the difference between a plan and a wish. The model's filed parameter count is 753B, held at FP8 precision, which at one byte per parameter is 753 GB of weights. Applying the frontier model GPU footprint sizing rule used with vLLM and SGLang, a 1.2 planning factor for KV cache and activations brings the requirement to 904 GB the GPUs must hold. One node of eight 141 GB GPUs provides 1,128 GB, which holds the weights with room to spare: after the weights and the planning reserve, roughly 280 GB of KV cache ceiling remains for concurrent engineers working at the same time. The node carries a load of roughly ten kilowatts, which is a question for the company's facilities team rather than for this design, and it is a 4A090 item for a D:4 destination, so a BIS license determination is named as a phase one checkpoint before any class is quoted; until the node lands, the platform runs on the company's existing hardware.

7.2  The Latency Budget

The latency budget in this design is shaped by the fact that its slowest loop is a person, not a machine. No assertion enters the regression until the verification lead approves it, so the approval queue sets the pace of the whole system, and queue depth and ageing are monitored on the observability stack with an escalation path to the senior verification expert after five working days. The spec agent's reading is batch work bounded by a revision cycle, not by seconds: a new specification revision arrives, the agent reads it, and an engineer confirms each extracted requirement before it is used, which means the loop is measured in working sessions rather than round trips. The interactive surface is the natural language interface, where the verification lead asks a question and expects an answer with citations; because GLM 5.3, BGE-M3 and the object model all sit on the same premises network, that answer makes no external hop, and its latency is owned entirely by the company's own room. Retrieval and embedding are the only sub-second commitments, and they run beside the serving node precisely so that they never become the bottleneck in front of it.

7.3  The Boundary and Its Failures

Nothing crosses the network boundary outward in any direction: designs, specifications and models stay in the operator's environment on the company's own hardware, and there is no third party model service to leak toward. That constraint is not paranoia but arithmetic of consequence, because design data is the company's core intellectual property and the industry's record shows what its loss costs: a Taiwanese court fined a foundry operator tens of millions of dollars over employees who stole memory-maker trade secrets (Bloomberg 2020), the same operator paid a 60 million dollar fine in the United States for the theft (Reuters 2020), and final sentences were upheld for former employees of another chipmaker in a separate leak case (Focustaiwan 2026). Research security guidance under the United States CHIPS program treats exactly this class of information as requiring protection controls (NIST 2024). Inbound, the only door is the artifact and model registry, Harbor with its offline installer, which governs what comes in; updates arrive as artifacts through that registry and never as live pulls from outside.

Each failure path has a named answer. If the link fails, nothing stops, because nothing depends on an external link: the site is the perimeter, and the event backbone's own sequencing carries on locally. If power fails, the roughly ten kilowatt node is the exposure, which is why it is an open question for the facilities team and why the platform runs on existing company hardware until the node is in place. If the update path fails, the registry holds the last good artifact set and the system keeps serving what it already holds, with no silent substitution of a smaller GPU class while the BIS determination is pending.

Licenses Decide What the Company Owns Outright

GLM 5.3, BGE-M3 and PaddleOCR-VL 1.6 were chosen as much for their licenses as for their capability, because the license terms decide whether the operator can hold its own weights, fine tune them and keep them sovereign.

Chapter 7 placed every weight inside the company's perimeter and proved the frontier model fits its node with room for a KV cache ceiling. This chapter turns to the models themselves, because in a design the operator must own outright, the license attached to each weight matters as much as the capability of the weight: the license terms decide whether the company can hold the model, fine tune it, redistribute it, and keep it sovereign on its own hardware.

8.1  Three Models, Three Licenses

Figure 7 shows the model stack: GLM 5.3 at the center, BGE-M3 for retrieval beneath it, and PaddleOCR-VL 1.6 at the document edge where specifications enter. GLM 5.3 is the rollout model the operator named, a frontier-class model whose filed parameter count is 753B, served at FP8 precision on vLLM from the single eight-GPU node described in Chapter 7; its role is the agentic work surface, carrying the spec agent, the check agent and the natural language answers over the design model. Its license is the GLM-5.3 bespoke license, whose terms allow commercial use, fine tuning and redistribution, and those three permissions are precisely what let the operator hold the weights outright rather than rent them: the company may run them for its own work, adapt them, and move them inside its own estate without asking again. At about 756 GB of weights at FP8 as published, roughly 1.5 TB at BF16, it is the one model in the register whose filed count places it in the frontier class, and it was chosen on that basis.

BGE-M3 is the embedding model, licensed under MIT, which is the most permissive license in the register and carries no field-of-use restriction at all. It runs at FP16 inside the perimeter on CPU or a modest GPU, at about 1.1 GB at that precision against about 2.27 GB at float32, and it was chosen for a technical reason as much as a legal one: it produces dense, sparse and multi-vector output from a single pass, which keeps requirement identifiers and signal names retrievable alongside prose, and its multilingual coverage suits a bilingual Saudi engineering estate. PaddleOCR-VL 1.6 is the parsing model, about 0.96B parameters under Apache-2.0, running at BF16 at roughly 1.9 GB by the arithmetic of its parameter count, small enough to sit on a site GPU beside the serving node. Its table, formula and layout parsing is what a chip specification actually consists of, which is why it stands at ingestion; its Arabic coverage rests on the 1.0 card's 109-language claim, so it is validated on the operator's own documents in phase one with a human check stage rather than assumed.

8.2  The Model and Equipment Register

Table 4 gathers the register in one place: each model with its license, the hardware classes and sizing rules the placement stands on, the sensing question, the patterns the design leans on, and the ground the whole stack runs on. The sensing row is deliberately short, because a design office engagement has no cameras, no machine telemetry and no physical AI: the only location in this design is which block and which project a record belongs to, and the traceability is between records, carried by the object model. The pattern rows carry the controls the design cannot work without: engineer-confirmed extraction, because a misread requirement propagates into checks and coverage; tool-neutral assertions drafted into version control, so any of the vendors' tools can run them; expert lessons held as memory rather than fine tuning, so senior reasoning stays inspectable, citable and partitionable; and provenance on every fact, so each statement carries the tool, file and revision it came from. The ground row is the simplest and the most important: the company's own hardware, on its own premises, in Saudi Arabia, with no third party model service anywhere in the stack.

One Block and One Revision Cycle Prove It First

Phase one proves the governed model on one block and one specification revision cycle against the operator's own baseline measures, and only its exit gate extends the model chip-wide.

Chapter 8 closed the model register with three named weights and the licenses that let the operator hold them inside its own perimeter. This chapter sets out how the build earns trust: a first phase deliberately confined to one block and one specification revision cycle, measured against the operator's own baseline, and an exit gate that must be passed before anything extends chip-wide.

9.1  Two Phases and One Gate Between Them

Phase one is deliberately small, because a small perimeter is what makes the proof cheap to stop. It covers one design block and one full specification revision cycle, carried by 15 items across six workstreams: Agents and approvals, Change impact and coverage, Command center, Design model and ontology, Pilot and rollout, and Sovereign platform and compliance. Its items bind the phase one sources as files and repositories the company already owns, read the specifications into governed requirements, and carry the simulated event, one interface requirement change on one block, from specification to interface to signals to checks to tests to coverage. The exit gate is the governed record itself: the block modeled from specification to tapeout, with the requirement change traced to everything that implements it and everything that proves it. Phase two carries 3 items across three workstreams, and its items, exposing the model vendor neutrally beneath the design tools, writing the agent drafting standard, and extending the model chip wide, are scheduled only once that gate is passed. Requirement coverage across the six requirements the operator stated stands at six covered, none partial and none a gap. Figure 8 lays out both phases with their item counts, workstreams and gates.

9.2  What the Rollout Measures

The rollout measures itself against the operator's own baseline, taken before anything changes, and every figure either cites its source or is marked an assumption, which is the operator's own rule. The primary measure is the engineer rejection rate on requirements the spec agent extracts: because a misread propagates into checks, coverage and impact lists, the confirmation step is a control, and its rejection rate is a monitored signal and a phase one gate rather than a courtesy. Alongside it, the rollout measures how many requirements the coverage agent finds with no proof, whether the reconciliation job that runs after every sync cycle finds divergence between the ontology and the systems of record, and the depth and ageing of the approval queue on the observability stack, reviewed at the pilot gate. Escaped bugs found late are bound as a baseline measure in phase two, after the pilot has proved the model, so the chip-wide extension can be judged against the block that came before it.

9.3  Failure Modes and What the Design Does About Them

Table 5 states the failure modes the design plans for and the response each one carries; none of them is treated as a surprise to be discovered during the rollout.

9.4  Lessons From the Pilot Shape

Confirm every requirement before it is used. The spec agent is the entry point for everything downstream, and the engineer who confirms each extraction is the control that keeps a misread from propagating into checks, coverage and impact lists; making the rejection rate a gate turns that control into a measurement. Read only what the company already owns. Phase one confines its reads to the files and repositories the company already holds, which keeps the license question narrow in the phase that must be cheap to stop, and defers each vendor's terms to discovery before any connector is built. Never let an unreconciled list reach a citation. An impact list drawn from an unreconciled revision is worse than no list, because it carries the authority of the model behind it; flagging such lists stale and excluding them from citations keeps that authority earned.

9.5  Open Questions and What Each Would Settle

Three questions remain open. The frontier node's roughly ten kilowatt load is a question for the company's facilities team, and settling it either confirms the 141 GB class node on the company's own premises or forces a smaller class and a fresh sizing. The export license determination for that node, run as a phase one checkpoint with the class and end user named, has an unknown lead time, and settling it sets when the frontier tier runs on its own hardware rather than the company's existing hardware in the meantime. The Arabic document parsing claim behind the ingestion model rests on its model card's language coverage and is validated on the operator's own documents in phase one with a human check stage; settling it decides whether the parsing tier stands as chosen or needs a different model and additional check stages. Each vendor's terms, confirmed in discovery, decide which connectors exist at all.

The Intelligence Stays with the Company That Produced It

The object model, the weights, the decision record and the boundary all belong to the operator, and keeping senior verification reasoning as inspectable, citable memory rather than opaque weights is what makes that ownership real.

Chapter 9 left the rollout ending at a gate, and what the gate protects is the question this chapter answers: who owns what the build produces, and why the form of that ownership matters more than the fact of it.

10.1  What the Company Owns

The object model is the company's from the first sync: sixteen objects that project the systems of record rather than replace them, every fact carrying the tool, file and revision it came from, so the graph can always be rebuilt from what the company already holds and no vendor can hold it hostage. The weights are the company's in the strongest available sense: GLM 5.3 is held under a license that permits commercial use, fine tuning and redistribution, and the embedding and parsing models carry MIT and Apache-2.0 terms, so nothing in the stack depends on a model service that a third party could withdraw. Under this architecture nothing is trained or distilled into weights, which means the only weights to own are the ones already held. The decision record, every approval, waiver and expert lesson, is kept as inspectable, citable memory partitioned by need-to-know, and that form is the point: senior verification reasoning kept as records stays readable, citable and partitionable per project and block, where the same reasoning distilled into weights would be none of those things. The boundary is the company's own hardware on its own premises, with nothing crossing outward and the artifact registry governing what comes in. The severity is documented rather than assumed: trade-secret theft in this sector has ended in a 60 million dollar fine (Reuters 2020) and final criminal sentences for engineers who moved design knowledge outward (Focustaiwan 2026), and the protection such knowledge relies on is legal protection against unlawful acquisition, use and disclosure (Europa 2016), which a hosted path would place in a third party's care.

10.2  The Offer Behind the Design

CodeNinja produced this design on Praxis, its platform for designing physical AI systems, and the design maps directly onto its offer: Decision Systems is the change-impact ranking and the coverage recommendation the verification lead decides on; Hyper Ontology is the object model itself; Hyper Pragma is the command center and the surfaces where the company's own engineers build and run their agents over that model; Hyper Engram is the kept record of decisions and expert lessons that each next decision reads; and Sovereign Infrastructure is the own-hardware, open-weight, in-country operation the whole design runs on.

A Traceable Design Record the Company Owns

The design is one governed model of a chip's record, from specification section to foundry handoff, in which every fact carries the tool, file and revision it came from and every check carries a named approver: agents read specifications and draft assertions, engineers confirm and approve, coverage finds requirements with no proof, and the reasoning behind checks and waivers is kept as memory the next project reads, all on the company's own hardware inside its own perimeter.

Running the same shape elsewhere takes the four things this design leaned on: a system of record that can be projected rather than replaced, an object model whose lineage matches the industry's own traceability chain, licenses that let the operator hold its weights, and a first gate small enough to stop the work cheaply, here one block and one revision cycle against the operator's own baseline before anything extends chip-wide.

Every Choice Traces to Recorded Reading

Every design in this series is produced on Praxis, and this chapter lets a reader trace any choice in this paper back to the ask, the records in the room and the eight lenses that reasoned over them.

Chapter 10 closed the ownership argument, and ownership of the reasoning behind the design is the same question one level up: a reader should be able to hold this paper's choices against the records that produced them. Every design in this series is produced on Praxis, and this chapter lets a reader trace any choice back to what justified it (Figure 9).

11.1  Contextualizing the Ask

The ask, in the operator's own words, was one governed model of the design, from specification to tapeout: specification sections, requirements, blocks, interfaces, signals, assumptions, verification checks, tests, coverage, bugs, waivers and revisions, each fact tied to the tool, file and revision it came from, so that a requirement traces to what implements it and what proves it. Agents would read new specification revisions, draft formal verification checks and find requirements with no proof, with the verification lead approving every check, and the whole system vendor neutral beneath the existing design tools and sovereign on the company's own hardware, with GLM 5.3 named as the model to run. Praxis assigned the industry as semiconductors and the family as system of context, the architecture whose work surface is part of the architecture itself. In the room were the pinned semiconductors brief, a case, a tooling shelf, and three models checked live this run, GLM 5.3, BGE-M3 and PaddleOCR-VL 1.6, each carrying its URL and source date in the register. 744 records were in the room and 126 were read in full; the other 618 were listed and read on demand.

11.2  The Eight Lenses

Table 6 states, lens by lens, what Praxis could see, what it cited and what each lens contributed; a lens that returned nothing is shown as the gap it was.

11.3  Patterns Adopted and Set Aside

Three patterns were adopted. The first is the traceable graph: one object vocabulary whose lineage from requirement to block to signal to check to test to coverage makes statements computable, taken from the pinned brief's first-principles instinct that knowledge lives as timestamped true statements. The second is confirmation as structure: the engineer confirming each extracted requirement and the verification lead approving each drafted check are named people in the loop, not courtesies. The third is memory over weights: expert lessons kept as inspectable, citable records under the pinned architecture, rather than fine tuning on past verification data. Set aside with reasons: the fab-floor data sources, SEMI interfaces and cleanroom physics of the pinned brief were read and rejected as not fitting a design office engagement; the connector into any one vendor's silo was rejected in favour of exposing the ontology beneath all the vendors' tools; and the hosted frontier model API was ruled out by the operator's own constraint that no third party model service touches the design data.

11.4  Where the Reasoning Lands

The reasoning lands on three equipment classes: the 141 GB HBM GPU class, the frontier model GPU footprint sizing rule for serving runtimes such as vLLM and SGLang, and the GLM 5.3 node count by GPU class, under which one node of eight GPUs holds the 753 GB of FP8 weights with 375 GB beside them for KV cache and activations, against the 151 GB the 1.2 planning factor reserves. Every model named was checked live and carries its source; every regulation cited sits in the register; every pattern stands on a record that was read in full. Everything shown in this paper was recorded reading, and nothing is inferred.