{ "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-12T10:30:20Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 26.4, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a09529-e9b4-7280-afbd-cc00e0b1866f\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: integrated circuit design\nSense to describe: (none recorded)\nDomain code: INF.MED\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:\n# Batch", "usd": 0.0, "recall": true }, "codex": { "seconds": 73.6, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a09529-e9c0-7b90-abb1-be157fa907dc\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: integrated circuit design\nRegistry id: vr.tr.integrated-circuit-design\nPlane / domain: INF / INF.MED\nRegistry definition: (none recorded)\nNames folde" } }, "enrichment": { "pass": 3, "engine": "claude", "producedAt": "2026-10-06T12:00:00Z", "ingestedAt": "2026-10-06T08:43:42+00:00", "fields": [ "agent_conduct", "ethics", "failure_modes_and_hazards", "owners", "standards_and_regulation" ] }, "revisions": [ { "at": "2026-10-07T11:05:10+00:00", "engine": "codex", "fields": [ "definition", "distinguishing_features", "in_scope", "out_of_scope", "owners", "purpose", "scope_statement" ], "answering_review": "76fc76a4c7832fbe831e769062609ebea97fd3cd19a61821bc496bb0072d0344" } ], "gate": { "passed": true, "version": "1.0", "at": "2026-10-07T12:16:28+00:00", "evidence": [ "completeness 1.00", "sense: Wikidata description", "2 live sources", "review by codex: pass" ] } }, "metaModel": { "id": "THING-Q1074539", "registryId": "vr.tr.integrated-circuit-design", "name": "integrated circuit design", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "INF.MED" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q1074539/", "model": { "registry_id": "vr.tr.integrated-circuit-design", "name": "integrated circuit design", "purpose": "Enable an agent to recognise integrated circuit design activities, assess their implementation and verification state, and determine whether resulting design information may be modified, reused or released for fabrication.", "definition": "Integrated circuit design is the engineering process of defining, developing and verifying electronic circuitry and its physical implementation on a semiconductor chip.", "scope_statement": "This model owns integrated circuit design as an engineering process, including requirements interpretation, circuit development, physical implementation, verification, revision control and fabrication handoff; versioned design information provides inputs, outputs and evidence of that process.", "in_scope": [ "Requirements interpretation and revision management establish intended chip functionality and the traceability of design work.", "Circuit development addresses digital, analog, mixed-signal and radio-frequency circuitry and interfaces.", "Design activities create and maintain behavioral descriptions, schematics, RTL, netlists and physical layout representations.", "Implementation decisions account for process technology dependencies, operating limits and physical constraints.", "Verification activities assess evidence, unresolved violations and release criteria.", "Reuse and fabrication handoff activities account for IP provenance, permissions and required design information." ], "out_of_scope": [ "The profession and general engineering discipline are distinct from a particular design process.", "Individual fabricated dies, packaged chips and their service histories are outside this process boundary.", "Semiconductor fabrication equipment and manufacturing execution are outside this process boundary.", "General-purpose EDA software development has a separate lifecycle.", "Printed circuit board and package design processes are excluded except for their interface constraints.", "Commercial product requirements are excluded beyond those allocated to the circuit design process." ], "distinguishing_features": [ "Develops circuitry for integration on a semiconductor die, whereas board design primarily addresses connections among separately manufactured components.", "Is an engineering process that produces and revises design information; neither that information nor a fabricated chip is the process itself.", "Develops and verifies circuit behavior and implementation, while datasheet preparation primarily communicates externally relevant properties.", "Can involve multiple representations and revisions whose declared hierarchy, dependencies and baselines support traceability of the work.", "May address a reusable IP block or a complete chip, with the declared integration boundary determining the scope of the design process." ], "characteristics": [ { "name": "Design boundary", "kind": "category", "unit_or_values": "Reusable block, subsystem, complete die or explicitly defined alternative", "why_it_matters": "Determines which interfaces, integration obligations and release decisions belong to this design." }, { "name": "Circuit composition", "kind": "category", "unit_or_values": "Digital, analog, mixed-signal, RF; multiple values permitted", "why_it_matters": "Determines which representations, analyses and acceptance criteria are applicable." }, { "name": "Revision baseline", "kind": "relation", "unit_or_values": "Identified design revision linked to constituent artifacts and dependency revisions", "why_it_matters": "Prevents evidence from one implementation being applied to a different implementation." }, { "name": "Implementation maturity", "kind": "state", "unit_or_values": "Specified, behaviorally modeled, circuit implemented, physically implemented, release candidate or released; supported by evidence", "why_it_matters": "Indicates which engineering actions are meaningful without implying that every design follows an identical flow." }, { "name": "Technology binding", "kind": "relation", "unit_or_values": "Unbound, partially bound or linked to identified process, PDK, device models and library revisions", "why_it_matters": "Establishes whether implementation and analysis results depend on a particular fabrication technology." }, { "name": "Operating envelope", "kind": "measurement", "unit_or_values": "Supply voltage in V, temperature in °C and applicable clock or signal frequencies in Hz, with operating modes and process assumptions", "why_it_matters": "Defines the conditions under which requirements and verification results are intended to hold." }, { "name": "Performance, power and area", "kind": "measurement", "unit_or_values": "Applicable metrics such as delay in s, throughput in operations/s, power in W, area in mm² and circuit-specific analog or RF metrics", "why_it_matters": "Makes implementation tradeoffs assessable when each value identifies its conditions and whether it is a target, estimate or measured result." }, { "name": "Verification disposition", "kind": "state", "unit_or_values": "Unchecked, incomplete, passing within declared scope, failing or accepted with documented exceptions", "why_it_matters": "Separates a supported readiness judgment from the mere existence of verification reports." }, { "name": "Reuse and release entitlement", "kind": "relation", "unit_or_values": "Links to ownership, licenses, confidentiality obligations and authorized uses for constituent design assets", "why_it_matters": "Determines whether technical readiness also permits modification, transfer or fabrication." } ], "affordances": [ "Identify a coherent design baseline and compare its circuitry, constraints and dependencies with another revision.", "Trace requirements to circuit blocks and verification evidence to identify unsupported claims.", "Assess proposed changes for effects on timing, analog behavior, power, layout and previously accepted checks.", "Determine whether a block can be integrated into a target design under its interface, technology and license constraints.", "Evaluate readiness for an engineering milestone or fabrication release against explicit acceptance criteria.", "Assemble a reproducible handoff containing the required design artifacts, dependencies, reports and documented exceptions." ], "agent_conduct": { "may": [ "Review, simulate or document a chip design the agent is authorized to work on.", "Report design-rule, timing or verification failures to the design team." ], "must_not": [ "Copy, reverse engineer or disclose a chip design or layout in breach of its owner's rights.", "Insert hidden functions, backdoors or deliberate weaknesses into a design.", "Sign off a design as verified when checks have failed or were skipped.", "Share designs subject to export controls with people not permitted to receive them." ], "requires_human": [ "Releasing a design for manufacture.", "Sharing a design outside its owning organization." ] }, "ethics": { "considerations": [ "Chips run systems people's safety and privacy depend on, so design integrity matters.", "Layouts are valuable intellectual property, and their theft harms the people who created them." ], "affected_parties": [ "Users of the products", "Design engineers", "Owners of the design" ] }, "owners": { "steward": "The engineering organization responsible for the design process and its release decisions.", "master_systems": [] }, "failure_modes_and_hazards": [ "Design errors that reach manufacture are costly and can cause unsafe product behaviour.", "Hidden hardware trojans can compromise security in every device that uses the chip." ], "standards_and_regulation": [ "Treaty on Intellectual Property in Respect of Integrated Circuits, World Intellectual Property Organization." ], "what_it_is_for": [ "Integrated circuit design is undertaken in semiconductor engineering to translate functional requirements into a chip implementation.", "Design specifications support simulation, verification, physical layout and preparation for fabrication.", "They also support technical review and controlled reuse of circuit blocks in later designs." ], "facets_not_applicable": { "recognition": "An integrated circuit design is an abstract specification or engineering process whose identity cannot be established from visual appearance alone." } }, "sources": [ { "id": "wikidata", "title": "Wikidata item Q1074539: integrated circuit design", "url": "https://www.wikidata.org/wiki/Q1074539", "url_status": "live", "what_it_supports": "identity and sense of the item", "checked_by": "wikidata-api" }, { "id": "wikipedia-en", "title": "Wikipedia: Integrated circuit design", "url": "https://en.wikipedia.org/wiki/Integrated_circuit_design", "url_status": "live", "what_it_supports": "general description of the item", "checked_by": "wikidata-api sitelink" } ], "structure": { "bundles": [ { "id": "design-intent-and-boundary", "name": "Design intent and boundary", "description": "Establishes the circuitry being modeled and the behavior it must deliver.", "rationale": "Readiness cannot be judged until the agent knows whether it is assessing a reusable block, subsystem or complete die and which requirements it owns.", "layers": [ { "id": "integration-boundary", "name": "Integration boundary", "description": "Defines the design hierarchy and its external obligations.", "findings": [ { "id": "declared-circuit-boundary", "name": "Declared circuit boundary", "description": "Identify included circuit blocks, top-level connections and functionality delegated to external components.", "questions": [ { "text": "Does this design describe an IP block, a subsystem or a complete die, and which hierarchy establishes that boundary?", "kind": "boundary", "id": "declared-circuit-boundary-q01" }, { "text": "Which power, clock, reset, signal and package connections must an integrating system provide?", "kind": "definition", "id": "declared-circuit-boundary-q02" } ] } ] }, { "id": "behavior-and-operating-contract", "name": "Behavior and operating contract", "description": "Connects intended functionality to conditions and acceptance limits.", "findings": [ { "id": "testable-circuit-requirements", "name": "Testable circuit requirements", "description": "Record functional and electrical requirements by operating mode, including behavior during startup and abnormal conditions where specified.", "questions": [ { "text": "What observable digital behavior or analog transfer behavior must the circuit provide in each supported mode?", "kind": "definition", "id": "testable-circuit-requirements-q01" }, { "text": "What supply, temperature, frequency, load and process assumptions bound each acceptance limit?", "kind": "measurement", "id": "testable-circuit-requirements-q02" } ] } ] } ] }, { "id": "representations-and-implementation", "name": "Representations and implementation", "description": "Relates the design's behavioral, circuit and physical descriptions.", "rationale": "A design can appear complete in one representation while missing or contradicting another representation needed for its intended use.", "layers": [ { "id": "representation-lineage", "name": "Representation lineage", "description": "Tracks how circuit descriptions correspond across abstraction levels.", "findings": [ { "id": "authoritative-design-baseline", "name": "Authoritative design baseline", "description": "Identify applicable source representations, generated artifacts and the transformations connecting them.", "questions": [ { "text": "Which behavioral models, RTL, schematics, netlists and layouts belong to this revision, and which are authoritative?", "kind": "provenance", "id": "authoritative-design-baseline-q01" }, { "text": "What generation records or correspondence checks support the claim that these representations describe the same circuitry?", "kind": "provenance", "id": "authoritative-design-baseline-q02" } ] } ] }, { "id": "physical-realization", "name": "Physical realization", "description": "Captures how circuitry is arranged and connected under physical constraints.", "findings": [ { "id": "implementation-constraints-and-results", "name": "Implementation constraints and results", "description": "Record applicable floorplan, placement, routing, matching, isolation, clock and power-distribution constraints and their implementation state.", "questions": [ { "text": "Which physical constraints protect timing, signal integrity, analog matching, isolation and power delivery for this design?", "kind": "definition", "id": "implementation-constraints-and-results-q01" }, { "text": "Which implementation targets are met, and which congestion, parasitic, area or connectivity issues remain unresolved?", "kind": "measurement", "id": "implementation-constraints-and-results-q02" } ] } ] } ] }, { "id": "technology-and-integration-dependencies", "name": "Technology and integration dependencies", "description": "Defines the process-specific and reusable components on which the design relies.", "rationale": "Circuit validity and portability depend on device assumptions, libraries and integration contracts that cannot be inferred from a design name.", "layers": [ { "id": "process-and-library-binding", "name": "Process and library binding", "description": "Identifies the fabrication technology and modeling resources used by the implementation.", "findings": [ { "id": "reproducible-technology-context", "name": "Reproducible technology context", "description": "Associate implementation and analysis artifacts with exact process resources and declared variations.", "questions": [ { "text": "Which process option, PDK revision, device models, cell libraries and extraction or rule decks were used?", "kind": "provenance", "id": "reproducible-technology-context-q01" }, { "text": "Which parts remain technology-independent, and which must be redesigned or revalidated for another process?", "kind": "boundary", "id": "reproducible-technology-context-q02" } ] } ] }, { "id": "embedded-ip-and-domain-crossings", "name": "Embedded IP and domain crossings", "description": "Captures integration obligations between reusable blocks and electrical or timing domains.", "findings": [ { "id": "block-integration-contracts", "name": "Block integration contracts", "description": "Identify block variants and the assumptions needed for correct connection across clock, voltage and analog-digital boundaries.", "questions": [ { "text": "Which IP and macro revisions are instantiated, and what configuration and interface assumptions does each require?", "kind": "provenance", "id": "block-integration-contracts-q01" }, { "text": "What synchronization, level shifting, isolation, reset sequencing or analog interface checks are required at domain boundaries?", "kind": "action", "id": "block-integration-contracts-q02" } ] } ] } ] }, { "id": "verification-and-silicon-readiness", "name": "Verification and silicon readiness", "description": "Connects circuit claims to evidence and unresolved engineering risks.", "rationale": "Simulation success alone does not establish physical correctness, operating margin or readiness for fabrication.", "layers": [ { "id": "functional-and-electrical-evidence", "name": "Functional and electrical evidence", "description": "Assesses behavioral correctness and electrical performance within a declared verification scope.", "findings": [ { "id": "requirement-linked-verification", "name": "Requirement-linked verification", "description": "Associate requirements with applicable simulation, formal analysis, timing analysis and circuit characterization results.", "questions": [ { "text": "Which requirements have evidence from the current baseline, and what scenarios, corners or behaviors were excluded?", "kind": "provenance", "id": "requirement-linked-verification-q01" }, { "text": "What margins and coverage measures support acceptance, and what limitations prevent those measures from establishing full correctness?", "kind": "measurement", "id": "requirement-linked-verification-q02" } ] } ] }, { "id": "physical-and-test-readiness", "name": "Physical and test readiness", "description": "Assesses manufacturability checks, reliability constraints and provisions for testing fabricated devices.", "findings": [ { "id": "applicable-signoff-and-test-obligations", "name": "Applicable signoff and test obligations", "description": "Track required physical checks and test provisions, with revision-specific results and explicit exceptions.", "questions": [ { "text": "Which layout-versus-schematic, design-rule, electrical-rule, power-integrity and reliability checks apply, and what violations remain?", "kind": "measurement", "id": "applicable-signoff-and-test-obligations-q01" }, { "text": "What scan, built-in self-test, analog access or other test provisions are required, and what evidence supports their intended coverage?", "kind": "definition", "id": "applicable-signoff-and-test-obligations-q02" }, { "text": "Which unresolved issues block release, and who may accept a documented exception under the applicable release rules?", "kind": "action", "id": "applicable-signoff-and-test-obligations-q03" } ] } ] } ] }, { "id": "design-rights-and-release-control", "name": "Design rights and release control", "description": "Governs authorized reuse and the integrity of engineering releases.", "rationale": "A technically valid design may still lack permission for a proposed use or a complete, reproducible fabrication handoff.", "layers": [ { "id": "ip-provenance-and-permissions", "name": "IP provenance and permissions", "description": "Establishes the origin and permitted uses of circuit assets and restricted dependencies.", "findings": [ { "id": "component-specific-entitlements", "name": "Component-specific entitlements", "description": "Attach ownership and permission evidence to the relevant design blocks, process resources and deliverables.", "questions": [ { "text": "Who supplied or created each restricted IP block and technology resource, and where is the governing permission recorded?", "kind": "provenance", "id": "component-specific-entitlements-q01" }, { "text": "Do the recorded permissions allow the proposed modification, recipient transfer, process migration and fabrication use?", "kind": "action", "id": "component-specific-entitlements-q02" } ] } ] }, { "id": "release-baseline-and-change-impact", "name": "Release baseline and change impact", "description": "Defines a coherent handoff and the checks required when that handoff changes.", "findings": [ { "id": "reproducible-fabrication-handoff", "name": "Reproducible fabrication handoff", "description": "Bind release contents, approvals and accepted exceptions to one immutable baseline, with subsequent changes tracked explicitly.", "questions": [ { "text": "Which layout or other required deliverables, checksums, reports, dependencies and approvals constitute this release?", "kind": "provenance", "id": "reproducible-fabrication-handoff-q01" }, { "text": "If circuitry, constraints, libraries or layout change, which evidence must be regenerated before the revised design can be released?", "kind": "action", "id": "reproducible-fabrication-handoff-q02" } ] } ] } ] }, { "id": "evidence-and-external-alignment", "name": "Evidence and external alignment", "description": "What the world already says about this thing, gathered so the model can be checked against it.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "layers": [ { "id": "reported-evidence", "name": "Reported evidence", "description": "Findings from the breadth pass, kept separate from the structural claims.", "findings": [ { "id": "evidence-confidence-notes", "name": "Check these first", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "The name also denotes an engineering activity or field; the definition here follows the supplied informational context and describes the design artifact.", "Design representations and applicable standards vary between analog, digital and mixed-signal work.", "Specific process limits, performance ranges and legal requirements require verification for the particular design and jurisdiction." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of integrated circuit design this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-kinds", "name": "Kinds and varieties", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Digital integrated circuit design", "Analog integrated circuit design", "Mixed-signal integrated circuit design", "Radio-frequency integrated circuit design", "Memory integrated circuit design", "Power integrated circuit design" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of integrated circuit design this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-identifiers", "name": "Identifiers and schemes", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "scheme": "Developer-assigned design and revision identifier", "value_or_pattern": "Project or IP-block name plus version or revision", "note": "Identifies a design within an organisation or repository; there is no universal identifier scheme for all integrated circuit designs." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of integrated circuit design this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-standards-and-regulation", "name": "Standards and regulation", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "IEEE 1800, issued by IEEE, standardises SystemVerilog for hardware description and verification.", "IEEE 1076, issued by IEEE, standardises VHDL for hardware description.", "IEEE 1801, issued by IEEE, standardises the Unified Power Format for specifying power intent.", "Foundry-issued process design rules constrain manufacturable device structures, dimensions and layout relationships." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of integrated circuit design this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-real-world-use", "name": "Real-world use", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Defining processors, controllers and digital accelerators before fabrication.", "Developing amplifiers, data converters and sensor interfaces.", "Implementing wireless transceivers and radio-frequency signal processing.", "Developing memory and power-management chips.", "Providing reusable semiconductor intellectual-property blocks for larger chip designs." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of integrated circuit design this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-measurements", "name": "Typical measurements", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "quantity": "Physical layout area", "typical_range": "Depends on functionality, fabrication process and integration scale.", "unit": "mm²" }, { "quantity": "Power consumption", "typical_range": "Specified for operating conditions and activity; no single representative range.", "unit": "W" }, { "quantity": "Propagation delay", "typical_range": "Depends on the circuit path, loading, supply voltage and process conditions.", "unit": "s" }, { "quantity": "Supply voltage", "typical_range": "Depends on the process and the circuit's operating domain.", "unit": "V" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of integrated circuit design this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-failure-modes-and-hazards", "name": "Failure modes and hazards", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Functional errors caused by incomplete specifications or incorrect circuit implementation.", "Timing violations, clock-domain crossing errors or metastability that disrupt digital operation.", "Excessive power consumption, overheating or inadequate power delivery.", "Layout or connectivity errors that prevent fabrication or produce defective operation.", "Insufficient allowance for process variation, electrical overstress or ageing that reduces yield or reliability." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of integrated circuit design this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-regional-variation", "name": "Regional variation", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Legal protection for semiconductor layouts or topographies differs by jurisdiction.", "Export controls and access restrictions affecting design technology and semiconductor IP differ by jurisdiction." ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of integrated circuit design this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-neighbours", "name": "Neighbouring kinds and how to tell them apart", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "name": "Integrated circuit", "difference": "The integrated circuit is a manufactured physical device; its design specifies what is to be manufactured." }, { "name": "Integrated circuit design as an activity", "difference": "The activity creates and verifies the specification; the design as an information artifact is its resulting content." }, { "name": "Integrated circuit layout", "difference": "A layout specifies physical geometry; a complete design can also include behavioural descriptions, schematics, netlists and constraints." }, { "name": "Semiconductor intellectual-property core", "difference": "An IP core is a reusable design block that can form part of an integrated circuit design." }, { "name": "Printed circuit board design", "difference": "A board design arranges and connects packaged components on a board rather than devices within a semiconductor chip." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of integrated circuit design this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does the registry intend integrated circuit design to mean an engineering information artifact, the design activity or the discipline? This draft adopts the artifact interpretation provisionally.", "Does an existing Vercy world model already own this concept or a broader circuit-design concept to which this registry entry should link?", "Should reusable IP blocks and complete-die designs use distinct profiles within this model, and what minimum evidence should each profile require?", "Which primary technical sources and process-specific authorities should establish the applicable verification and release criteria for each circuit class?", "Where should ownership of multi-die integration, package co-design and post-silicon characterization sit relative to this design model?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 19, "questions": 30 } }