{ "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-12T11:13:21Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 17.2, "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: 01a09551-5ee4-7172-b8f6-6e1acea61375\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: medium dependent interface\nSense to describe: (none recorded)\nDomain code: INF.KNW\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:\n# Batc", "usd": 0.0, "recall": true }, "codex": { "seconds": 68.9, "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: 01a09551-5edc-7982-a06c-c4b9d2706c33\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: medium dependent interface\nRegistry id: vr.tr.medium-dependent-interface\nPlane / domain: INF / INF.KNW\nRegistry definition: (none recorded)\nNames fol" } }, "enrichment": { "pass": 3, "engine": "claude", "producedAt": "2026-10-06T12:00:00Z", "ingestedAt": "2026-10-06T08:44:31+00:00", "fields": [ "agent_conduct", "ethics", "failure_modes_and_hazards", "owners", "standards_and_regulation", "visual_identification" ] }, "gate": { "passed": true, "version": "1.0", "at": "2026-10-07T10:10:26+00:00", "evidence": [ "completeness 1.00", "sense: Wikidata description", "2 live sources", "review by codex: pass" ] } }, "metaModel": { "id": "THING-Q1421871", "registryId": "vr.tr.medium-dependent-interface", "name": "medium dependent interface", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "INF.KNW" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q1421871/", "model": { "registry_id": "vr.tr.medium-dependent-interface", "name": "medium dependent interface", "purpose": "Enable an agent to identify a medium dependent interface, assess its compatibility with a transmission medium and peer interface, and determine which connection, configuration, or verification actions are justified.", "definition": "A medium dependent interface (MDI) is the interface between an Ethernet physical-layer device and its transmission medium, with characteristics specified for the particular Ethernet physical-layer type.", "scope_statement": "This model owns the medium dependent interface (MDI) as an Ethernet interface contract and its realized boundary between a transmission medium and a PHY or MAU, including applicable mechanical, electrical, optical, and power attachment requirements; this interpretation follows the definition reproduced in [IEEE 802.3 working-group correspondence](https://www.ieee802.org/3/cg/email/msg01033.html).", "in_scope": [ "Identification of the Ethernet PHY type, governing specification, and medium-facing interface boundary", "Mechanical mating requirements and contact, pair, lane, or fiber assignments", "Applicable electrical or optical signal requirements at the MDI reference plane", "Media attachment compatibility, including crossover behavior where applicable", "Conditional power delivery requirements at the same attachment boundary", "Evidence supporting interface conformance and permitted connection or configuration actions" ], "out_of_scope": [ "MAC framing, switching, routing, and application protocols", "Media independent interfaces between MAC and PHY, such as MII and GMII", "Internal PHY coding, signal processing, and implementation architecture", "Complete cable or fiber plant design and installation", "Connector products considered independently of their Ethernet interface assignment", "Complete powered-device or power-sourcing-equipment design" ], "distinguishing_features": [ "The boundary faces the transmission medium; a MAC-facing digital interface belongs to an MII-family model instead.", "Identification requires a PHY-specific attachment contract; connector appearance alone cannot establish that two MDIs are compatible.", "Electrical or optical requirements are assessed at an identified medium-facing reference plane, rather than at arbitrary internal PHY nodes.", "An MDI-X designation describes a crossover arrangement within applicable interfaces, rather than a separate networking layer.", "The entry represents an interface concept and its requirements; a cable, PHY chip, or connector is a related implementing object." ], "characteristics": [ { "name": "Governing PHY specification", "kind": "relation", "unit_or_values": "Ethernet PHY designation, standard edition, applicable clauses, amendments, and corrigenda", "why_it_matters": "Determines which interface requirements and exceptions apply." }, { "name": "Transmission medium class", "kind": "category", "unit_or_values": "Balanced copper, optical fiber, coaxial, or another explicitly specified medium", "why_it_matters": "Selects the relevant attachment and signal characteristics." }, { "name": "MDI reference plane", "kind": "relation", "unit_or_values": "Specified physical boundary and associated measurement fixture or de-embedding convention", "why_it_matters": "Makes interface measurements comparable to the governing limits." }, { "name": "Mechanical attachment profile", "kind": "category", "unit_or_values": "Connector or attachment specification, mating geometry, keying, and applicable contact assignment", "why_it_matters": "Establishes whether a proposed attachment can mate correctly." }, { "name": "Signal-path assignment", "kind": "relation", "unit_or_values": "Contacts, pairs, lanes, or fibers mapped to their PHY-specific roles", "why_it_matters": "Exposes wiring, polarity, and direction mismatches." }, { "name": "Supported operating modes", "kind": "category", "unit_or_values": "Declared PHY modes, nominal bit rates in bit/s, and supported duplex or topology options", "why_it_matters": "Provides the mode set against which peer compatibility can be assessed." }, { "name": "Electrical interface measurements", "kind": "measurement", "unit_or_values": "Profile-dependent voltage in V, impedance in ohms, and return loss in dB over a stated frequency range; not applicable for optical-only measurements", "why_it_matters": "Supports electrical conformance decisions without imposing one limit across all PHY types." }, { "name": "Optical interface measurements", "kind": "measurement", "unit_or_values": "Profile-dependent wavelength in nm and optical power in dBm, with measurement conditions; not applicable for electrical-only interfaces", "why_it_matters": "Supports optical compatibility and conformance assessment." }, { "name": "Crossover configuration", "kind": "state", "unit_or_values": "MDI, MDI-X, automatic selection, unknown, or not applicable, qualified by PHY type", "why_it_matters": "Guides pair-mapping checks without assuming all MDIs use crossover behavior." }, { "name": "Power attachment role", "kind": "category", "unit_or_values": "Data-only, PD, endpoint PSE, unknown, or not applicable, with the governing power specification", "why_it_matters": "Determines which additional interface constraints apply before power is enabled." }, { "name": "Interface verification status", "kind": "state", "unit_or_values": "Untested, partially tested, conformant for a stated profile, nonconformant, or indeterminate", "why_it_matters": "Separates observed link operation from documented interface compliance." } ], "affordances": [ "Resolve a port description into a PHY-specific MDI profile and identify missing evidence.", "Compare a proposed medium and peer interface against mechanical, signal, mapping, and operating-mode requirements.", "Determine whether crossover or automatic crossover settings are relevant to a connection problem.", "Select electrical or optical measurements at the correct MDI reference plane.", "Check conditional power attachment requirements before recommending power enablement.", "Recommend connection, reconfiguration, retesting, or replacement based on documented mismatches." ], "agent_conduct": { "may": [ "Identify and document MDI port types and cabling on networks it is authorized to manage.", "Diagnose link problems such as crossover or pair mismatches and report them." ], "must_not": [ "Connect to or tap a network medium it is not authorized to access.", "Change cabling or port settings on a live network without authorization.", "Apply power over cabling to equipment not designed to receive it." ], "requires_human": [ "Changing physical connections on networks that carry critical services." ] }, "ethics": { "considerations": [ "Physical network access can expose others' communications." ], "affected_parties": [ "Network users", "Network administrators", "Organizations relying on the network" ] }, "owners": { "steward": "The owner or operator of the network equipment.", "master_systems": [] }, "visual_identification": [ "A network port, such as an eight-pin modular socket or an optical connector, on an Ethernet device." ], "failure_modes_and_hazards": [ "Wrong pair wiring causes link failure or degraded speed.", "Incorrect power over Ethernet can damage connected equipment." ], "standards_and_regulation": [ "IEEE 802.3, Standard for Ethernet, Institute of Electrical and Electronics Engineers." ], "what_it_is_for": [ "A medium dependent interface is encountered where an Ethernet physical-layer device connects to its specified transmission medium.", "It is used when assessing port, connector and cabling compatibility or diagnosing physical connection problems.", "Its requirements depend on the particular Ethernet physical-layer type and medium." ] }, "sources": [ { "id": "wikidata", "title": "Wikidata item Q1421871: medium dependent interface", "url": "https://www.wikidata.org/wiki/Q1421871", "url_status": "live", "what_it_supports": "identity and sense of the item", "checked_by": "wikidata-api" }, { "id": "wikipedia-en", "title": "Wikipedia: Medium-dependent interface", "url": "https://en.wikipedia.org/wiki/Medium-dependent_interface", "url_status": "live", "what_it_supports": "general description of the item", "checked_by": "wikidata-api sitelink" } ], "structure": { "bundles": [ { "id": "mdi-identity-and-contract", "name": "MDI identity and contract", "description": "Establishes what boundary is being modeled and which Ethernet requirements govern it.", "rationale": "An MDI cannot be evaluated from its name or connector alone; the PHY profile determines the applicable contract.", "layers": [ { "id": "medium-facing-boundary", "name": "Medium-facing boundary", "description": "Locates the interface relative to the PHY or MAU and the transmission medium.", "findings": [ { "id": "boundary-identification", "name": "Boundary identification", "description": "Record the implementing objects on either side and the exact interface boundary, distinguishing the MDI from internal and MAC-facing interfaces.", "questions": [ { "text": "Where does the specified PHY or MAU meet the transmission medium?", "kind": "definition", "id": "boundary-identification-q01" }, { "text": "Which nearby connector, PHY sublayer, or MII-family interface could be mistaken for this boundary?", "kind": "boundary", "id": "boundary-identification-q02" } ] } ] }, { "id": "governing-phy-profile", "name": "Governing PHY profile", "description": "Connects the interface to a versioned set of requirements.", "findings": [ { "id": "profile-and-revision", "name": "Profile and revision", "description": "Record the PHY designation and controlling clauses before assigning interface limits or declaring compatibility.", "questions": [ { "text": "Which standard edition, PHY clauses, amendments, and corrigenda define this MDI?", "kind": "provenance", "id": "profile-and-revision-q01" }, { "text": "Which supported modes share this attachment, and which require a different MDI profile?", "kind": "boundary", "id": "profile-and-revision-q02" } ] } ] } ] }, { "id": "medium-attachment-and-mapping", "name": "Medium attachment and mapping", "description": "Captures how the medium mates with the interface and how signal paths are assigned.", "rationale": "Mechanical fit and correct signal mapping are separate requirements that must both be checked.", "layers": [ { "id": "mechanical-mating", "name": "Mechanical mating", "description": "Identifies the attachment geometry and supported medium termination.", "findings": [ { "id": "attachment-compatibility", "name": "Attachment compatibility", "description": "Record the specified attachment, keying, and termination requirements rather than inferring compatibility from a familiar connector shell.", "questions": [ { "text": "Which connector or attachment specification and mating geometry apply?", "kind": "definition", "id": "attachment-compatibility-q01" }, { "text": "Does the proposed medium termination satisfy the required mating and keying constraints?", "kind": "action", "id": "attachment-compatibility-q02" } ] } ] }, { "id": "signal-path-mapping", "name": "Signal-path mapping", "description": "Describes contact, pair, lane, or fiber roles and applicable remapping behavior.", "findings": [ { "id": "mapping-and-crossover", "name": "Mapping and crossover", "description": "Record path assignments and determine whether fixed crossover, automatic crossover, or polarity handling applies to this PHY.", "questions": [ { "text": "How are contacts, pairs, lanes, or fibers assigned to the signal roles required by this PHY?", "kind": "definition", "id": "mapping-and-crossover-q01" }, { "text": "Which documented crossover or polarity behavior must be considered when selecting or troubleshooting the connection?", "kind": "action", "id": "mapping-and-crossover-q02" } ] } ] } ] }, { "id": "signal-and-power-envelope", "name": "Signal and power envelope", "description": "Defines the profile-specific conditions under which signals and optional power cross the interface.", "rationale": "A physically mating connection may still violate signal or power requirements.", "layers": [ { "id": "electrical-or-optical-envelope", "name": "Electrical or optical envelope", "description": "Selects the relevant signal quantities and their specified limits.", "findings": [ { "id": "signal-limits-at-mdi", "name": "Signal limits at the MDI", "description": "Record only the electrical or optical requirements applicable to the selected profile, including measurement conditions and reference planes.", "questions": [ { "text": "Which electrical or optical quantities and limit curves apply at this MDI reference plane?", "kind": "measurement", "id": "signal-limits-at-mdi-q01" }, { "text": "Which test conditions and calibration or de-embedding procedures make the measured values comparable to those limits?", "kind": "measurement", "id": "signal-limits-at-mdi-q02" } ] } ] }, { "id": "conditional-power-attachment", "name": "Conditional power attachment", "description": "Handles power requirements only where the attachment supports a specified power role.", "findings": [ { "id": "power-role-and-constraints", "name": "Power role and constraints", "description": "Record the applicable power role, conductor usage, and enabling requirements while leaving complete power-system behavior to neighboring models.", "questions": [ { "text": "Does this attachment have a documented PD or endpoint PSE role, or is it data-only?", "kind": "definition", "id": "power-role-and-constraints-q01" }, { "text": "Which power specification and interface checks govern whether power may be enabled on the proposed connection?", "kind": "action", "id": "power-role-and-constraints-q02" } ] } ] } ] }, { "id": "compatibility-and-verification", "name": "Compatibility and verification", "description": "Turns interface requirements and observed evidence into bounded connection decisions.", "rationale": "Agents need to distinguish compatible specifications, successful link operation, and demonstrated conformance.", "layers": [ { "id": "peer-and-medium-fit", "name": "Peer and medium fit", "description": "Compares the local MDI, transmission medium, and remote interface.", "findings": [ { "id": "connection-assessment", "name": "Connection assessment", "description": "Record compatible operating modes and unresolved attachment, mapping, or signal mismatches across the proposed connection.", "questions": [ { "text": "Which operating modes are jointly supported by the local interface, peer interface, and selected medium?", "kind": "boundary", "id": "connection-assessment-q01" }, { "text": "Which identified mismatch requires a configuration change, a different medium, or a different interface?", "kind": "action", "id": "connection-assessment-q02" } ] } ] }, { "id": "mdi-test-evidence", "name": "MDI test evidence", "description": "Associates conformance decisions with reproducible interface measurements.", "findings": [ { "id": "conformance-and-diagnostic-limits", "name": "Conformance and diagnostic limits", "description": "Record test coverage, measured failures, and the limits of conclusions drawn from link status or end-to-end symptoms.", "questions": [ { "text": "Which test reports identify the tested port, PHY mode, reference plane, conditions, and governing limits?", "kind": "provenance", "id": "conformance-and-diagnostic-limits-q01" }, { "text": "What additional measurement would distinguish an MDI defect from a medium fault, peer fault, or internal PHY problem?", "kind": "action", "id": "conformance-and-diagnostic-limits-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 term is interpreted in its established Ethernet sense; no registry definition was supplied.", "The supplied INF.KNW domain and batch field-of-knowledge guidance should be checked: this term denotes a technical interface, not an academic discipline.", "Connector details, signal limits and relevant IEEE 802.3 clauses depend on the particular physical-layer type and require verification." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of medium dependent interface 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": [ "Twisted-pair copper MDI", "Optical-fibre MDI" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of medium dependent interface 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": "IEEE Ethernet physical-layer designation", "value_or_pattern": "10BASE-T, 100BASE-TX, 1000BASE-T", "note": "These identify physical-layer types whose specifications define the corresponding MDI; they are not identifiers for individual interfaces." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of medium dependent interface 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 802.3, issued by IEEE, specifies Ethernet physical layers and their medium dependent interfaces." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of medium dependent interface 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": [ "Connecting Ethernet network adapters, switches and routers to transmission media", "Defining interoperable electrical or optical characteristics at Ethernet media connections", "Testing Ethernet physical-layer conformance at the media interface" ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of medium dependent interface 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": [ "Incorrect pair wiring or incompatible crossover arrangements can prevent a twisted-pair link from operating.", "Impedance discontinuities and excessive reflections can impair copper-link signal integrity.", "Excessive attenuation or optical connector contamination can prevent reliable reception.", "Electrostatic discharge or electrical surges can damage inadequately protected copper interfaces." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of medium dependent interface 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": "Media independent interface (MII)", "difference": "MII connects Ethernet MAC and PHY functions; MDI connects the physical layer to the transmission medium." }, { "name": "Ethernet PHY", "difference": "The PHY implements physical-layer functions; the MDI is its interface to the medium." }, { "name": "MDI-X", "difference": "MDI-X denotes a crossover wiring arrangement for applicable twisted-pair Ethernet interfaces, rather than the general media-interface concept." }, { "name": "Ethernet connector", "difference": "A connector is a physical component; the MDI also encompasses the applicable interface characteristics and signal assignments." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of medium dependent interface this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does the registry intend the general IEEE 802.3 interface concept or the narrower use of MDI contrasted with MDI-X on twisted-pair ports?", "Which existing Vercy model, if any, already owns this interface concept and should remain its single source of truth?", "Which PHY families and standard editions should receive detailed profiles, including applicable corrections to interface limits?", "How should the INF / INF.KNW classification distinguish the abstract interface contract from physical port implementations?", "Which power attachment variants and non-connector implementations must the initial model cover?" ], "statistics": { "bundles": 5, "layers": 9, "findings": 15, "questions": 23 } }