Skip to content

About us

INFORMATION LASTS
LONGER THAN ITS SYSTEMS.

Product and business information stays in use for years: through new systems, new languages, new channels and now AI. c-rex.net exists so that it keeps its meaning along the way, and so that the people responsible for it stay in control of it.

Why we exist

MEANING DOES NOT TRAVEL ON ITS OWN

A specification, a safety notice or a translated manual is written once and used for a long time. Over that time almost everything around it changes: the authoring tool, the portal, the languages, the product versions, the regulations and the systems that read it.

Information can come through all of that byte for byte and still be wrong. A value that was correct for one firmware ends up in a context where it no longer applies, and nothing in the file shows it. Information does not report its own change. What it means, where it applies and who is responsible for it therefore have to be stated explicitly and checked again whenever it moves.

That is the problem we work on. We call the work Information Engineering: treating information as something that is specified, traceable to its source, transformed under stated conditions and checked before it is handed on, rather than something that is merely stored.

Vision and mission

WHAT WE ARE WORKING TOWARDS

Our vision

Business and product information that keeps its meaning and stays in the hands of the people responsible for it, whatever systems, languages and technologies come next.

Our mission

We engineer technical information to remain meaningful, governed and traceable as it moves between systems and contexts: with information models, transformations, delivery, translation, automation and controlled processes.

How we think

WHERE CHANGE BELONGS

Our architecture follows one principle: Stable inside. Dynamic outside. Inside are the information models, rules, relationships and processes that give information its meaning. Outside is everything that changes for good reasons: channels, applications, languages, product versions, regulations, users and AI.

The inside does not stand still. Changes there are governed, explicit and reconstructable: they happen on purpose and leave a record.

Two consequences follow for how we design. The model describes the subject matter, not the systems that consume it: the page structure of a portal or the needs of a search index belong to the adaptation for that system, not to the model everyone shares, and a new product variant should normally be new data in the model rather than a new model. And the decisive work happens at the crossing: whenever information moves into another system or context, the conditions under which it is valid have to be kept or re-established.

For you this means that a new channel, application or language should not require rebuilding your information foundation. It does not mean that nothing ever has to be adapted.

How your sources, the stable inside, the changing outside and AI relateConceptual illustration. On the left, your sources: authoring and CCMS, business systems, files and archives. They remain authoritative. In the middle, the stable inside: models, rules, relationships and processes, inside a ring that asks at every crossing whether the information is still valid. On the right, the dynamic outside: channels, applications, languages and users, and an AI model joined through a controlled integration as one participant that can be replaced where the architecture permits. Arrows run both ways.Your sourcesAuthoring and CCMSBusiness systemsFiles and archivesremain authoritativeStable insideModelsRulesRelationshipsProcessesStill valid here?Dynamic outsideChannelsApplicationsLanguagesUsersAI modelone participant, replaceablewhere the architecture permitscontrolled integration
Your information can stay where it is maintained. In the middle are the models, rules, relationships and processes that keep it meaningful, and the question every crossing has to answer.

AI

WHERE AI FITS

AI changes how quickly information can be found, transformed, translated and explained. We work with it. But we do not put a model at the centre of the architecture. The centre is your information and the processes that govern it.

In our architecture AI is one participant on the dynamic outside: it uses information, contributes to it or transforms it. It works with governed information and inside defined processes. It does not decide what is valid, and an answer does not become authoritative because a model produced it.

That is also why models and providers sit behind controlled integrations, so that they can be replaced where the architecture permits it. Replacement still has a cost. A different model has to be checked again, and provider-specific features create dependencies. We would rather make those dependencies visible than pretend they do not exist.

Control and choice

WHAT DIGITAL SOVEREIGNTY MEANS TO US

For us, digital sovereignty is not mainly a question of where a server stands. It is the practical ability to keep control and choice: over your information and which source is authoritative, over your processes, the systems you use, the infrastructure they run on and the providers you work with, with the dependencies stated openly.

Hosting in a particular country or on your own premises can be part of that. On its own it settles little. A system can run on your premises and still hold your information in a form nothing else can work with.

Our design principle is that your information remains yours. For a defined process, that means specifying which source stays authoritative and how processed and generated results come back to you during normal operation. We prefer portable, standard formats where they fit the task, so that what you need to keep working does not exist only inside our systems.

That does not make replacing c-rex.net effortless. Integrations, configurations and know-how have value and take work to reproduce. But your information should never be held hostage.

Open standards, with their limits

DITA for structured authoring, XLIFF for exchange in translation, TMX for translation memories, iiRDS for packaging technical information and its metadata for delivery. Each covers a different boundary. None makes a whole system interchangeable.

Why customers should stay

Because our software, our service and our work together keep being worth it, and because we keep developing what we build. Not because leaving was made difficult.

From principle to product

HOW THIS SHAPES WHAT WE BUILD

The principles above are design decisions. This is where they show. It describes how our products are designed and where they are heading, not which product is available in which form.

  • Information models and semantics

    Information carries its meaning, applicability and relationships as metadata instead of leaving them to whoever reads it next. For delivering technical information we build on iiRDS, an open standard for technical documentation and its metadata, which is based on Linked Data. Still, the information problem decides the representation, not the other way round.

  • Transformation and delivery

    Transformation and delivery are separate services in our architecture. One converts information under stated rules; the other delivers it into each context with the metadata that says where it applies. Neither becomes the source of truth just by taking part.

  • A workspace and automation

    Our direction is one workspace in which people set up and review information processes, and automation that runs them: a supported process is configured once and then runs repeatedly, while people stay responsible for the decisions that need judgement.

  • Ask, Deliver, Translate, Convert

    The four outcomes on this site are different uses of one foundation, not four separate systems. Starting with one should not mean starting over for the next.

  • Your existing systems

    We design to connect to the systems you already work with instead of asking you to move everything into ours; our projects have connected authoring, translation, content management and service systems. c-rex.net does not need to become the permanent home of your information. Working with it can still mean processing, indexing or temporarily holding parts of it, and what that involves is stated for each use case.

  • Origin and traceability

    Information should be able to show where it comes from, which version and conditions it applies to and what changed it. That has to be planned from the start, because it cannot be reconstructed later from the file alone.

Who we are

WHERE THIS THINKING COMES FROM

c-rex.net was founded by Markus Wiedenmaier. He has developed software in the field of component content management since 2001 and is a founding member of the iiRDS Consortium.

The thinking on this page grew out of our project work: structured documentation, publishing, translation processes and delivering technical information to where it is used. Our project reports on the c-rex.net Blog, published from 2021 onwards, describe work for industrial manufacturers and publishers: migrating, translating and integrating technical information, building iiRDS metadata and delivering content into service systems.

c-rex.net is based in Cape Coral, Florida.

Founder

Markus Wiedenmaier

Founder of c-rex.net and CEO of c-rex.net LLC

  • Software development in the CCMS domain since February 2001
  • Expertise in DITA, XML, XSLT, publishing, iiRDS, Machine Translation Processes and Agentic AI
  • Diplom-Informatiker (FH) and MBA in Quality and Environmental Management
  • Founding Member of the iiRDS Consortium

Blog

MORE FROM OUR WORK

We write about information, standards and our projects on the c-rex.net Blog.