

  All Discussions  |  

  Hello Post  |  

  Direct Messages  |   

  Categories  |  

  How-To(Forum)

Dependencies between obligations and constraints

TonyS

One clarification that might help simplify things.
Dependencies are not something we define or maintain manually.
At any kind of scale, that simply does not hold.
In practice, they need to be built dynamically from the underlying data -particularly:
• obligations (contracts, SLAs, commitments)
• constraints (capacity, time, legal state, funding)
In the x42 approach, these relationships are derived by the AI-2 layer, primarily from unstructured sources (contracts, documents, operational artefacts), with some support from structured systems.
They do not form simple 1:1 links either.
In reality, the graph is:
• 1 → n (one obligation affecting many outcomes)
• n → 1 (multiple inputs constraining a single outcome)
• n ↔ n (many-to-many interactions across domains)
Each node can have multiple upstream and downstream dependencies, which is why the behaviour only really becomes visible when you look at it as a connected graph, not a set of individual links. (1 → n ↔ 1 → n → 1 → 1 ↔ n ↔ …)
That is important because:
• they reflect how the organisation actually behaves
• they change as conditions change
• and they exist at a volume that is not human-manageable
For context, even a ₅,000-person organisation may have 12,000–15,000 unique contracts.
No one is manually defining or maintaining dependencies across that.
Where people do come in is oversight:
• the system scores its confidence in the relationships it derives
• humans review and challenge lower-confidence areas (e.g. below a threshold)
So, the model remains grounded in reality, without becoming manually curated.
From there:
• Dependencies show how things are connected
• Constraints determine where pressure applies
• Obligations define what must hold
The useful question then becomes:
→ which constraints will prevent which obligations being met
→ and how that impact propagates
That is the step that turns this into something meaningful for decision-making.

DD

Thanks @TonyS .
I agree the dependencies are more complex than simple cause / effect idea.
I have also been raised to understand that we must establish and manage key dependencies - and they need to have an owner. This does not line up with something we can’t define and maintain manually.

But I understand that thousands of contracts and their implications are impossible to maintain manually. This is equally as unmanageable as thousands of dependencies between tasks in plans. In both cases - we need those dependencies for the people at that level to use. These are part of the business fabric.

What I think I’m talking about as establishing / managing are the key dependencies not contained in contracts. e.g.

the sequence implied in strategy
the relationship of threats to objectives
the relationship between key performance indicators and hiring decision

Lots of stuff that I would not see emerging from x42 as I understand x42.

In project terms - while the task to task dependencies are vital - the important ones are the cross project dependencies - we focus on those.

To sum up - I see the content out of x42 as providing commercial integrity, our plans providing plan integrity (in the planning tool) - those we manage manually (perhaps sourced by X42?) and see important enough to assign someone to own) as providing strategic integrity.

Does that work?

ChrisB

DD There are many elements of governance - laid out clearly in BIG BoK and most other treatises on governance.

One of those is culture - which is about trust and relationships when you boil it down.
These are complex and dynamic relationships and are not confined to members of organisations but to all stakeholders. Trust is a key attribute of these and fluctuates dynamically and in complex ways. This trust is established first when people get together to agree on how they will work together (whether openly or simply by actions and interpretations of those actions) - sometimes when signing or interacting on contracts, but very much in all interactions whether or not there are contracts or constraints involved.

These relationships drive decision making - quite often despite what the ‘data’ shows, but very much in the case when there is insufficient factual information on which to base the decision.

It is the job of staff in an organisation to know what the contracts they sign commit them to - and of good governance to make sure they do know this and understand what it means in terms of their relationships with other stakeholders (internal and external), their behaviour, and their decision-making. I don’t buy that there are too many to keep track of manually or via normal automated digital systems, given that the vast majority of such contracts have common terms and conditions, and are supported by standing policies and procedures. I grant that there are probably a few exceptions, but mostly because of poor governance practices that can be fixed.

I see x42 as a key assurance tool however, that can be used to provide backup information, verify if trust levels (positive or negative) being shown by parties are warranted, and with very specific human input be used to do what-if analysis on proposed decisions, or assess impacts of those decisions before committing, perhaps.

There are tools (with AI components) appearing that can help uncover and trace some of these relationships, and also measure our governance performance in the culture aspect, but building and sustaining those relationships is a human effort for the foreseeable future. This is truly complex territory - in my current understanding, x42 current target territory is complicated but not complex.

I do think x42 has a really exciting role to play as an assurance tool for governance.

TonyS

@DD , we are aligned, just at different layers.
You are describing the few, critical dependencies that need to be explicit, owned, and managed.
That’s strategic integrity, and I agree, that has to sit with people.

x42 is dealing with a different problem:
the thousands of implicit dependencies created by contracts, constraints, workforce, systems, etc, the ones no one can realistically define or maintain manually.

Those are not things to assign owners to.
They are the underlying fabric that determines what’s actually possible, and how failure propagates.
So, the split for me is:
• x42 > shows how the business really holds together (and breaks)
• Plans > define intended sequencing
• Governance > owns the critical dependencies that matter most
Where it connects to your point:

x42 helps surface which dependencies are important enough to manage, rather than assuming we already know.

@TonyS

simon

TonyS

They mapping is essentially the risk (threat and opportunity) condition cause consequence triplet that defines a network of links which is different for every observer. Sometimes radically, often varying in probabilities and impacts per stakeholder over time.

Interesting that you put it in terms of contract and I put it in terms of risk both of which are mappings of <term> and <triggering condition>

Ciao
Simon

See slide 28 of https://logicalmodel.net/t/risk/20190220/index.html#inbrowser for the tip of the iceberg…



  All Discussions  |  

  Hello Post  |  

  Direct Messages  |   

  Categories  |  

  How-To(Forum)