Skip to main content

Contract Governance

Documentation Map​

Contract Governance

This page documents how jhf-dobby stays contract-correct without becoming a competing governance source.

Canonical Truth Boundaries​

Fabric is the source of truth for:

  • capability class
  • contract families
  • schema catalog
  • producer/consumer matrix
  • JARVIS adoption posture
  • admission posture

Warp is the source of truth for:

  • approval-lane objects
  • approval binding and expiry semantics
  • fail-closed approval outcomes

Dobby is the source of truth for:

  • run records
  • replay records
  • proposal records
  • Dobby metrics
  • Dobby runtime readiness materialization

Local Materialization Rules​

Dobby may materialize:

  • derived readiness and drift views
  • effective service mode
  • contract-family views derived from Fabric
  • replay and proposal lineage derived from Dobby-owned inputs

Dobby must not materialize as local source of truth:

  • a second contract registry
  • a second admission system
  • a second approval owner
  • business-domain truth from ERP, CRM, procurement, or ticketing systems

Current Contract Surfaces​

  • Manifest and runtime publication: ../fabric-manifest.json (fabric-manifest.json)
  • Stack publication: STACK_CONTRACT.md (docs/STACK_CONTRACT.md)
  • Runtime integrations: INTEGRATIONS.md
  • API-facing contract projection: API.md
  • QA feature inventory: MODULE_FEATURES.md (docs/MODULE_FEATURES.md)

Planned Governance Expansion​

Planned future work such as business-process optimization signals must keep the same rule set:

  • external business truth remains owned by domain systems
  • Dobby only consumes governed evidence
  • recommendations must be replayable, explainable, and approval-aware

Tracked future feature:

  • jhf-dobby#41 business-process self-learning signals for supplier and workflow quality optimization

License: AGPLv3. See ../LICENSE (LICENSE).
Learn more at helpifyr.com.