Method

A transparent semantic recipe
that people and AI agents follow

We aim at delivering impact. We start with one high-value regulated object, follow a semantic recipe that people and AI agents can both execute, and check quality at every phase. Each step is a part and a whole at the same time. Execution is performed by machines and orchestrated by humans. The recipe flexes to new requirements without restarting the engagement.

the backbone

The semantic recipe

Every holon is built from a recipe.

A semantic recipe is a versioned, testable specification: what the object is, what questions it must answer, what rules it must satisfy, and how to check that it does. It is written once, in the open, and then followed exactly, whether a step is performed by a subject-matter expert, a data engineer, or an AI agent. The recipe is the contract between everyone, and everything, that touches the holon.

Example: the batch / lot recipe, lab to market

A recipe reads like a line map crossed with a fishbone: the main line carries the batch from lab to market, and each branch is a quality step that feeds it. Hover or focus any node to read the action, the role that performs it, and the inputs and outputs, like a recipe card.

  1. Materials in (Warehouse / QC): receive and quarantine incoming materials.
  2. Weigh & dispense (Manufacturing): dispense materials against the batch record.
  3. Manufacture (Production): execute the master batch record to bulk product.
  4. In-process control (IPC / QC): test critical process parameters in line.
  5. QC release testing (QC laboratory): run identity, assay, purity, and micro tests.
  6. QA disposition (Qualified Person): review record, deviations, and CoA; decide.
  7. Release to market (Qualified Person): certify, serialize, and ship the batch.

Because the recipe is explicit, two things follow: quality can be checked at every step, not just at the end, and a new requirement is absorbed as a new version of the recipe, not a restart of the project. That is what makes the work fast and trustworthy, instead of fast and fragile.

the engagement

Six phases. Two lanes. One semantic backbone.

We begin with one high-value, regulated object, a target, study, product, batch, submission, claim, or market authorization, and one clearly defined problem. Its governed digital representation is a holon: a self-contained but connected object that brings together identity, meaning, evidence, rules, history, dependencies, and audience-specific views.

top-down

The business view of the world

What the object means, which decisions it must support, how experts understand it, which obligations constrain it, and what success looks like.

bottom-up

The IT and data view of the world

How the object is represented across systems, databases, documents, interfaces, models, and workflows, including data availability, quality, lineage, ownership, and technical limits.

The lanes meet through a shared semantic backbone: the executable recipe that connects a business problem to the right concepts, the best available data, the most appropriate instruments, the applicable rules, and the required outputs. Meaning comes from experts; content comes from systems. Meaning without data is an empty model; data without governed meaning is an untrustworthy pile of disconnected facts.

Built to reduce customer risk

No big-bang transformation. We solve one bounded problem and build one holon before extending the pattern.
No rip-and-replace. Existing systems stay in place unless a separate, justified decision changes them.
No hidden scope growth. Assumptions, exclusions, dependencies, risks, and acceptance criteria are documented before work begins.
No black-box results. Every material fact is connected to its source, transformation, rule, confidence, and approval history.
No unvalidated automation. AI may accelerate the work, but experts remain responsible for meaning and approval.
No semantic lock-in. Models and validation rules use portable standards such as SKOS, OWL, and SHACL.
No forced continuation. The customer keeps the approved deliverables from every completed phase.
No ambiguous success. Each engagement begins with agreed questions, decisions, metrics, and release criteria.

Six time-boxed phases, read left to right in chronological order. Each ends with a release gate; you decide whether to proceed.

Phase 1

Frame the problem and the holon

Agree on the business problem, the regulated object, the decisions it must support, and the measurable outcome before any modeling or technology work begins. We start with the problem, not the data.

Top-down: business reality

  • The problem, requirement, decision or workflow to improve
  • The object and its lifecycle; the audiences and roles
  • Risks, obligations, and boundaries
  • Expected result and success metric
  • The competency questions the holon must answer

Framed as Problem, Requirement, Success, and Metric.

Bottom-up: data and technology reality

  • Relevant systems, files, documents, and external sources
  • Source owners and systems of record
  • Access, privacy, security, and retention restrictions
  • Sample data; known quality and integration issues
  • Existing analytics, models, AI services, and workflow tools

decision → competency question → concept → source → instrument → output → success measure

You receive
  • A one-page engagement charter and holon definition
  • An approved competency-question register
  • A stakeholder and decision map
  • A preliminary source and instrument inventory
  • Documented assumptions, exclusions, risks, and dependencies
Release gate
  • Sponsor confirms the business value
  • A named expert confirms scope and questions
  • Data owners confirm representative sources are accessible
  • Quality, regulatory, privacy, or security confirm the boundaries

No modeling begins until the problem, scope, ownership, and feasibility are agreed.

Phase 2

Specify the semantic recipe

Write the recipe before building the solution. Define what the object means, what rules apply, which evidence is needed, and how the problem will be answered.

Top-down: business meaning and rules

  • Canonical concepts, definitions, and authoritative sources
  • Synonyms, relationships, and dependencies
  • Permitted classifications and controlled values
  • Lifecycle states and transition rules
  • Regulatory, scientific, operational, and access boundaries
  • Events to record and the rules for an acceptable answer

Bottom-up: source and instrument spec

  • Profile structured and unstructured sources
  • Assess completeness, uniqueness, timeliness, and quality
  • Map fields and document content to business concepts
  • Identify gaps, duplicates, conflicts, and unsupported assumptions
  • Evaluate which instruments fit each task

Recipe v1: ontology, identifiers, source-to-concept mappings, boundary rules, provenance, events, projections, instrument-selection logic, and acceptance thresholds.

You receive
  • An approved terminology and concept model, recipe v1
  • A source-to-concept mapping catalogue
  • A data-readiness and quality assessment
  • A question-to-data-to-instrument traceability matrix
  • A prioritized gap register and draft validation shapes
Release gate
  • Every critical question connects to concepts, data, an instrument, rules, an output, a validation test, and named owners
  • Unresolved gaps are made visible and assigned, never hidden

The customer approves the meaning, rules, and recipe before paying for a full build.

Phase 3

Generate and reconcile the holon

Build the first working holon from real business meaning and real customer data.

Top-down: business-led generation

  • Scene graph: the object, context, components, and state
  • Boundary graph: scientific, regulatory, operational, security, and access constraints
  • Event graph: the decisions and transitions that explain its condition
  • Projection graph: what each role may and must see

Bottom-up: IT-led generation

  • Ingest structured data via Table-to-Graph
  • Ingest documents via ontology-guided Doc-to-Graph
  • Normalize terms; resolve duplicate references
  • Map fields and statements to the backbone, with provenance on every fact
  • Isolate exceptions and uncertain extractions for review

The backbone guides what pipelines look for; real data stress-tests the backbone. Surprises are evidence the model must evolve, not licence for the pipeline to invent meaning.

You receive
  • A working holon and its four connected graphs
  • Source and transformation mappings; a governed identity model
  • Machine-readable boundary rules and an event ledger
  • Full source provenance and an exception register
  • Portable model and data exports
Release gate
  • Representative data loads; every fact has a known source
  • Duplicates reconciled; the model passes structural validation
  • Uncertain facts quarantined; model-vs-source gaps documented
  • All components export in agreed formats

Nothing is accepted merely because an automated system produced a plausible result.

Phase 4

Validate the holon

Prove that the holon is semantically correct, technically reliable, useful for the intended decision, and safe within its regulated context.

Top-down: expert validation

  • Competency questions answered correctly
  • Concepts and relationships reflect domain reality
  • The object is interpreted consistently across functions
  • Boundary rules reflect the applicable obligations
  • Role-specific views stay faithful to the same underlying truth

Bottom-up: machine and technical validation

  • SHACL and other machine-checkable constraints
  • Completeness, conformity, uniqueness, and consistency
  • Extraction precision, identity resolution, and provenance
  • Access controls and segregation of duties
  • Pipeline reliability, instrument performance, and response time

question → concept → source evidence → transformation → applied rule → answer → expert approval

You receive
  • A formal validation report and machine-validation results
  • Expert-review records and a competency-question test pack
  • Data-quality and extraction-accuracy results
  • Exceptions, residual risks, and compensating controls
  • A release recommendation signed by named owners
Release gate
  • All critical questions pass and quality thresholds are met
  • Every high-risk exception is resolved or formally accepted
  • Named domain and technical owners sign the validation
  • Quality, regulatory, privacy, and security approve the release

Machine validation and human judgment are both required. Neither substitutes for the other.

Phase 5

Project and operationalize

Turn the governed holon into the practical views, outputs, and workflows each audience needs.

Top-down: role and decision design

  • Express the same object for researchers, clinical, quality, and manufacturing
  • For regulatory affairs, safety, and medical affairs
  • For commercial teams, executives, partners, auditors, or authorities
  • Each projection built around a decision, responsibility, and authorization level

Bottom-up: delivery and integration

  • Dashboards, reports, and document outputs
  • APIs, alerts, and workflow triggers
  • Submission or evidence packages; search and Q&A interfaces
  • Role-based access controls and operational logging
  • Existing systems are integrated, not displaced by default

Every projection is computed from the same governed holon. Audience, detail, and terminology change, but the canonical object is never copied and rewritten.

You receive
  • Role-specific views, deliverables, and integrations
  • Documented access and projection rules
  • User-acceptance results, runbooks, and training materials
  • A rollback and continuity plan
  • A before-and-after comparison against the original process
Release gate
  • Intended users confirm it supports their work
  • Content traces back to the governed holon
  • Access rules tested; old and new processes compared
  • Support and rollback in place; the accountable role signs off

No established process is retired before its replacement is accepted by the people responsible for using it.

Phase 6

Govern, measure, and evolve

Keep the holon current, trustworthy, auditable, and reusable as requirements, evidence, systems, and regulations change.

Top-down: business governance

  • A named business owner with decision and approval rights
  • Lifecycle, retention, review, and decay rules
  • Terminology and policy change control; periodic expert review
  • Value and adoption measures
  • Criteria for correction, retirement, or replacement, and the next holon

Bottom-up: operational governance

  • Monitor data freshness, quality, and source-schema changes
  • Mapping failures and extraction or entity-resolution performance
  • Pipeline availability and model or agent drift
  • Access-control violations and incidents
  • Dependency and change impact

Every recipe change is versioned; impact analysis identifies affected mappings, rules, instruments, projections, and decisions before release. Reusable components carry forward to the next holon.

You receive
  • A governance and ownership charter; a versioned recipe
  • Lifecycle and knowledge-decay rules
  • A monitoring and quality dashboard
  • Change-control and impact-assessment procedures
  • Full documentation and a roadmap for extending the pattern
Release gate
  • Named owners and approved maintenance schedules
  • Tested monitoring, escalation, and recovery procedures
  • Version and change-control processes; agreed service measures
  • Confirmed customer capability to operate and maintain the holon

The customer receives an operable capability, not an undocumented prototype or a permanent consulting dependency.

Definition of done: a holon answers the approved questions, improves the defined decision against its metric, uses controlled terminology on qualified sources, preserves provenance and history, enforces its boundaries, passes machine and expert validation, and generates approved role-specific views from one governed object, with named owners and a controlled path for change. Not another data repository or one-off graph, but a reusable, governed decision capability.

how we engage

Working principles

Open standards. We build on RDF, OWL, SHACL, and ArchiMate so your knowledge stays portable and is not locked to a vendor.

Your sovereignty. Your data and models are yours. We work inside your governance, not around it.

Full transparency. Every quality checkpoint, sign-off, and recipe version is visible to you, not buried in an internal tracker.

Built to flex. The semantic recipe absorbs a new requirement as a new version, not a change request that stalls the engagement.

Slow business. We favor a small, durable foundation over a fast, fragile rollout. Each step has to earn the next.

Human in the loop. AI drafts and accelerates; your experts decide what becomes canon.

The aim: not a one-off project, but a recipe your teams can reuse and extend, to turn more of the organization into governed, computable knowledge.

Start a conversation

Tell us about one object worth governing well, and we will frame a first holon with you.

Contact us to scope a first engagement.

See the holon at work