engineering-base
type: Ontology
identifier: engineering-base
version: 0.2.0
description: Shared engineering supertypes — the MIF-compliant intermediate layer the engineering domains extend
has namespace:
  semantic memory: semantic
defines entity type: component
defines entity type: architectural-decision
defines entity type: design-pattern
defines entity type: delivery-metric
defines entity type: engineering-practice
defines entity type: process-discipline
defines entity type: control
defines entity type: artifact
defines entity type: policy
defines entity type: provenance
defines trait:
  versioned: versioned
  documented: documented
  dated: dated
  cited: cited
defines relationship:
  depends on: depends_on
  implements: implements
  governs: governs
  attests: attests
  derived from: derived_from
discovery config:
  discovery enabled: true
  confidence threshold: 0.8
  has discovery pattern: https://mif-spec.dev/ns/pattern/0
  has discovery pattern: https://mif-spec.dev/ns/pattern/1

semantic
type: Namespace
has child namespace:
  architecture: architecture
  has discovery pattern: patterns

architecture
type: Namespace
description: System architecture and component designs
type hint: semantic

patterns
type: Namespace
description: Design and architectural patterns
type hint: semantic

component
type: EntityType
base type: SemanticMemory
description: A software/system component, module, or service
negative example: A decision adopted Istio with Envoy sidecars for uniform mTLS across services, rejecting a shared client library since it still requires every team's voluntary adoption. Separately, a decision replaced synchronous inventory/payment/shipping calls with an event-driven OrderPlaced-to-Kafka architecture, decoupling order-service availability from any single downstream service.
negative example: The circuit breaker pattern wraps calls to failure-prone dependencies in a state machine that stops forwarding requests (open state) once a failure rate threshold is crossed, preventing cascading resource exhaustion in the caller.
defines trait: mif:trait/versioned
defines trait: mif:trait/documented
schema.org:
  required: name
  required: responsibility
  properties:
    name:
      type: string
      description: Component name
    responsibility:
      type: string
      description: Single responsibility description
    dependencies:
      type: array
      description: List of component dependencies
      items:
        type: string
    interfaces:
      type: array
      description: Public interfaces/APIs
      items:
        type: string
    owner:
      type: string
      description: Team or person owning this component

architectural-decision
type: EntityType
base type: SemanticMemory
description: An architectural decision with full context
defines trait: mif:trait/dated
defines trait: mif:trait/cited
schema.org:
  required: decision
  required: rationale
  properties:
    decision:
      type: string
      description: The decision made
    rationale:
      type: string
      description: Why this decision was made
    alternatives:
      type: array
      description: Alternatives considered
      items:
        type: object
    consequences:
      type: object
      description: Known consequences and trade-offs
    status:
      type: string
      description: Decision status
      enum: proposed
      enum: accepted
      enum: deprecated
      enum: superseded

design-pattern
type: EntityType
base type: SemanticMemory
description: A design pattern or architectural pattern
negative example: Medallion architecture, popularized by Databricks, organizes a lakehouse into Bronze, Silver, and Gold layers so a pipeline bug can be fixed and rerun from Bronze without re-extracting from source.
defines trait: mif:trait/cited
schema.org:
  required: pattern_name
  required: context
  required: solution
  properties:
    pattern name:
      type: string
    context:
      type: string
      description: When to use this pattern
    solution:
      type: string
      description: How the pattern solves the problem
    consequences:
      type: object
      description: Trade-offs and implications
    related patterns:
      type: array
      items:
        type: string

delivery-metric
type: EntityType
base type: SemanticMemory
description: A delivery, reliability, or operations metric (e.g. DORA four/five keys, SLO/SLI, MTTR, throughput)
negative example: A decision replaced static per-metric alert thresholds with SLO error-budget burn-rate alerting per the Google SRE Workbook, requiring every service to first define an SLO and SLI.
negative example: A retry-with-exponential-backoff-and-jitter pattern resends failed requests with progressively longer delays plus randomized jitter, reducing thundering herd effects when many clients retry simultaneously after an outage.
negative example: A capacity planning review discipline is a recurring meeting where teams forecast resource needs (compute, storage, personnel) for the next quarter based on growth trends and project commitments.
negative example: The freely published Google SRE Workbook's chapter defining multi-window, multi-burn-rate SLO alerting is the reference implementation most teams cite and link directly when adopting burn-rate paging.
negative example: DORA began as an independent research program co-founded by Nicole Forsgren, Jez Humble, and Gene Kim before Google acquired it in 2018, using an empirical, survey-correlated methodology.
defines trait: mif:trait/cited
schema.org:
  required: metric_name
  properties:
    metric name:
      type: string
    definition:
      type: string
      description: What the metric measures
    benchmark:
      type: string
      description: Target or elite-tier value
    source:
      type: string
      description: Originating framework or study

engineering-practice
type: EntityType
base type: SemanticMemory
description: An organizational, cultural, or operating practice (e.g. blameless postmortems, you-build-it-you-run-it, data mesh, federated governance)
negative example: This discipline requires an architecturally-significant change be written up as an ADR with rationale and alternatives before implementation begins. Separately, the Incident Command System assigns named roles, an Incident Commander, Communications Lead, and Subject Matter Experts, for major incidents.
negative example: An organization decentralized data ownership to domain teams once a central team became a bottleneck, accepting shared self-serve infrastructure costs. Separately, a platform team migrated self-managed Kubernetes to Amazon EKS so AWS takes over control-plane patching.
negative example: Charity Majors, Honeycomb's co-founder, argues the 'three pillars' observability framing is a legacy-tooling symptom. Separately, John Allspaw is credited with popularizing the blameless postmortem during his tenure as an Etsy engineering leader.
negative example: Google is credited with originating Site Reliability Engineering in the early 2000s under Ben Treynor Sloss, later publishing its practice in two widely-cited SRE books.
defines trait: mif:trait/cited
schema.org:
  required: practice_name
  properties:
    practice name:
      type: string
    description:
      type: string
      description: What the practice is
    evidence:
      type: string
      description: Empirical support or outcome
    origin:
      type: string
      description: Originating model, study, or author

process-discipline
type: EntityType
base type: SemanticMemory
description: A governance or production-readiness discipline (e.g. PRR, ORR, change enablement, acceptance criteria, stewardship cadence)
defines trait: mif:trait/cited
schema.org:
  required: discipline_name
  properties:
    discipline name:
      type: string
    purpose:
      type: string
      description: What the discipline governs
    criteria:
      type: string
      description: Acceptance or gating criteria
    stage:
      type: string
      description: Lifecycle stage where it applies

control
type: EntityType
base type: SemanticMemory
description: A control or safeguard governing a component, artifact, or asset (security, data-governance, or compliance control)
negative example: etcd is Kubernetes' Raft-consensus datastore, its only direct client being kube-apiserver. Separately, Vault brokers credentials through short-lived leases and starts sealed after any restart, requiring an unseal step before serving secrets.
negative example: A policy restricts production container builds to a centrally-approved base-image set, requiring a review process for exceptions. Separately, a policy designates the incident commander as sole channel for external incident communication, routing anything beyond routine updates through legal review.
negative example: A Change Advisory Board reviews high-risk production changes above a defined threshold before authorization. Separately, a discipline requires new services to pass a security design review, examining auth model and data classification, before launch.
negative example: An organization centralized secret storage on Vault over per-service stores, rejecting a per-cloud-provider secrets manager given its multi-cloud footprint, accepting Vault as a critical-path dependency.
negative example: A documented plan to address identified security risks and compliance gaps through risk assessment, prioritization of remediation activities, and tracking of implementation progress against regulatory deadlines.
negative example: AC-2, one of the most frequently assessed FedRAMP controls, addresses account lifecycle failures like never-deactivated departed-employee accounts, implemented via identity-governance tooling tied to an HR system of record.
defines trait: mif:trait/cited
schema.org:
  required: control_name
  properties:
    control name:
      type: string
    control type:
      type: string
      description: preventive / detective / corrective
    framework ref:
      type: string
      description: Originating framework or catalog (e.g. NIST 800-53 AC-2, SOC 2 CC6.1)
    statement:
      type: string
      description: What the control requires

artifact
type: EntityType
base type: SemanticMemory
description: A produced, content-addressable artifact (software package/build, dataset, model, report)
negative example: A decision adopted gRPC with Protocol Buffers for internal service calls, rejecting REST/OpenAPI and GraphQL federation. Separately, a decision consolidated dozens of repositories into a single monorepo with a unified, change-scoped build graph.
negative example: A guide migrates a production Elasticsearch 6.x cluster to OpenSearch via reindex-from-remote. Separately, a guide migrates a monolith using the strangler fig pattern, requiring each extraction to pass a parity check before the proxy routes its traffic to the new service.
negative example: dbt's run_results.json ties a downstream data-quality issue back to the exact git commit and run responsible. Separately, a CycloneDX SBOM is linked to its exact source commit and attached to the specific artifact digest it describes via the OCI referrers API.
negative example: Fluent Bit is a lightweight C-based log and metrics shipper minimizing per-host footprint, in contrast to Fluentd's heavier but broader Ruby plugin ecosystem.
negative example: Trunk-based development is an engineering practice where all developers commit to a single main branch frequently (multiple times per day) rather than maintaining long-lived feature branches, reducing merge conflicts and enabling continuous integration.
negative example: A 2017 GitLab incident where a primary database was accidentally deleted through a misconfigured backup deletion script, causing hours of data loss and recovery work, resulting in improved runbook procedures.
negative example: The RED method specifies three request-level metrics-Rate (requests per second), Errors (failure rate), and Duration (response time distribution)-for microservice monitoring.
negative example: Raw kernel trace events exported in JSON format enable analysis of system call latency, memory allocation patterns, and I/O performance characteristics.
defines trait: mif:trait/cited
schema.org:
  required: name
  properties:
    name:
      type: string
    artifact type:
      type: string
      description: build / package / image / dataset / model / report
    digest:
      type: string
      description: Content hash (e.g. sha256:...)
    uri:
      type: string
      description: Locator for the artifact

policy
type: EntityType
base type: SemanticMemory
description: A policy: a rule governing access, retention, classification, or change, enforced across the lifecycle
negative example: A retention audit cadence discipline schedules quarterly review confirming purge jobs actually delete data past its retention window. Separately, alert rule review periodically audits production alerting rules against a checklist to counter unpruned alert-set bloat.
negative example: A corrective control requires an automated, scheduled job to delete records exceeding their classified data category's retention limit, validated by confirming the purge job's run history and periodic table sampling.
negative example: Error budget policy is an engineering practice where teams track the difference between their SLO and actual uptime, using the remaining budget to decide whether to prioritize new features or stability work.
negative example: IA-5's password enhancements were reshaped by NIST SP 800-63B's 2017 shift away from mandatory rotation toward length-based requirements and breached-password screening.
negative example: ISO 27001's access-control clause requires documented user registration, deregistration, and periodic access-rights review, mirroring NIST 800-53's AC-2 under a different control catalog structure.
defines trait: mif:trait/cited
schema.org:
  required: policy_name
  properties:
    policy name:
      type: string
    scope:
      type: string
      description: What the policy governs
    enforcement:
      type: string
      description: Mechanism that enforces it (policy-as-code, gate, ABAC tag)

provenance
type: EntityType
base type: SemanticMemory
description: A provenance or attestation record binding an artifact to how it was produced (SLSA/in-toto, OpenLineage)
negative example: A Great Expectations checkpoint emits a validation-result record showing which expectations passed or failed for a run. Separately, OpenLineage's dataset facets snapshot a dataset's schema and row-count at a given run for drift comparison.
negative example: A detective control periodically verifies that an SLI's underlying metric is still receiving data and producing valid values, catching silent instrumentation breakage that would otherwise show as a false perfect SLO.
negative example: An oncall handoff discipline defines how on-call operators transfer responsibility at shift changes, including status briefing on active incidents, escalation contact procedures, and access credential handoff protocols.
negative example: A runbook for addressing TLS certificate expiration incidents includes steps to check certificate expiration dates, renew certificates before expiry, update certificate references in load balancers and services, and verify HTTPS connectivity post-renewal.
negative example: SLSA defines cumulative build-assurance levels motivated by real incidents like SolarWinds, where a compromised build environment defeated code-signing as a standalone integrity guarantee.
negative example: Heartbleed arose because OpenSSL's heartbeat handler trusted a client-supplied length field unvalidated against actual payload size, exposing adjacent heap memory with no server-log trace for over two years.
defines trait: mif:trait/cited
schema.org:
  required: subject
  properties:
    subject:
      type: string
      description: The artifact or entity the provenance describes
    builder:
      type: string
      description: The system/identity that produced it
    predicate type:
      type: string
      description: Attestation predicate (e.g. SLSA provenance, in-toto, OpenLineage run)
    materials:
      type: array
      description: Inputs/materials consumed
      items:
        type: string

versioned
type: Trait
description: Adds version tracking fields
has field:
  version:
    type: string
    pattern: ^\d+\.\d+\.\d+.*$
  changelog:
    type: array
    items:
      type: object

documented
type: Trait
description: Adds documentation reference
has field:
  documentation url:
    type: string
    format: uri
  readme path:
    type: string

dated
type: Trait
description: Adds decision/event date
has field:
  decision date:
    type: string
    format: date
  review date:
    type: string
    format: date

cited
type: Trait
description: Requires citations/sources
requires field: citations

depends_on
type: Relationship
description: Component dependency relationship
domain: mif:entityType/component
range: mif:entityType/component
range: mif:entityType/technology
symmetric property: false

implements
type: Relationship
description: Component implements a pattern or decision
domain: mif:entityType/component
range: mif:entityType/design-pattern
range: mif:entityType/architectural-decision
symmetric property: false

governs
type: Relationship
description: A control or policy governs a component or artifact
domain: mif:entityType/control
domain: mif:entityType/policy
range: mif:entityType/component
range: mif:entityType/artifact
symmetric property: false

attests
type: Relationship
description: A provenance record attests an artifact
domain: mif:entityType/provenance
range: mif:entityType/artifact
symmetric property: false

derived_from
type: Relationship
description: Artifact lineage — an artifact is derived from another
domain: mif:entityType/artifact
range: mif:entityType/artifact
symmetric property: false

https://mif-spec.dev/ns/pattern/0
type: DiscoveryPattern
content pattern: \b(Factory|Singleton|Observer|Repository|Strategy|Decorator)\s+Pattern\b
suggests entity type: design-pattern
suggests namespace: _semantic/patterns

https://mif-spec.dev/ns/pattern/1
type: DiscoveryPattern
content pattern: \b(CQRS|Event\s+Sourcing|Saga)\b
suggests entity type: design-pattern
suggests namespace: _semantic/patterns