BCOT Core · Modularity

Add amodule.Re-certifynothing.

Real commitments rest on many checks, owned by different teams and authorities. BCOT Core gives every check the same three-state interface, then combines them with one rule: the strictest finding survives. Adding a module can tighten the outcome. It can never loosen it. Risk is never inherited.

Modular governance stack5 independent owners
IdentityWho’s asking
Permit
ScopeWhat’s authorized
Permit
BehaviorHow’s it acting
Observe
AuthorityWho can say yes
Permit
ReversibilityUndo Path Verified
Permit
Shared module contractPermit · Observe · Abstain
Composed without coordinationStrictest finding survivesObserve

Replace one module. The interface and composition rule stay the same.

One language at every boundary

Each module answers one question. None can authorize alone.

A payment might depend on identity, amount, location, merchant status, and sanctions authority—five checks, five owners, one commitment. Modules do not need to know about one another. They report a finding; the architecture composes the set.

Permit means the boundary is clear. Observe means it is unresolved—the evidence needed to close it isn't there. Abstain means a required condition failed.

Permit

This boundary is clear.

Necessary, but never sufficient on its own.

Observe

Resolve this boundary.

The candidate does not commit, and what's missing is named.

Abstain

This boundary failed.

The candidate cannot commit while the condition remains false.

Interactive composition lab

The strictest finding wins—regardless of order.

Change the operating condition to see how independent findings resolve into one stable outcome.

Independent findings

IdentityPermit
Transaction scopePermit
Location fitObserve
Sanctions authorityPermit

Governed outcome

Observe

One check notices something.

Observe activates evidence acquisition and determines the next route.

Change the order of the modules in any of these scenarios and the result is the same. Order does not determine outcome.

Structural guarantees

Your customers can add modules without re-certifying the stack.

The combining behavior belongs to the architecture, not to the implementation order, machine, vendor, or number of checks.

Theorem

One rule underneath.

Verdicts combine by taking the strictest.

01

Adding a module tightens the stack.

It cannot loosen it. A new required module can only restrict what’s authorized.

02

Integration order needs no validation.

Wire modules in any order and the outcome is identical.

03

A hundred approvals cannot outvote one objection.

Repeating a permissive verdict has no effect—Permit is neutral.

04

Group sub-stacks without re-deriving the result.

Evaluating in groups gives the same outcome as evaluating flat.

And one guarantee that isn't a consequence—it's a design decision: Fail-closed. A required verdict that is missing or malformed never resolves to Permit. Absence is not consent.

One interface · many authorities

Strictness can reach beyond your own codebase.

Internal evaluators and external authorities sit under the same interface. A module can compute locally or ask a source at the moment of commitment—without importing the authority’s whole database.

Governed authority networkOne response shape
Inside your systemIdentityBehaviorScope
One interfaceAsk any authority
PAO
Outside your systemSanctions listLicense registryCard network
Different ownersOne governed vocabularyOne composition rule

What modularity gives you

Extend the stack—without re-certification.

01

Customers can add their own checks

A new required module can only preserve or narrow what’s allowed; it cannot open a path that was closed.

02

Not every no is the same

A behavioral flag can route to step-up review while a regulatory block refuses outright. Your customers get a response proportionate to the finding.

03

An unresolved boundary stays unresolved

This isn’t flattened into a yes or a no to fit a two-state interface. What’s missing stays visible and attributable.

04

A regulator can inspect the architecture

Tracing decision making is a list: which modules ran, what each one found, which authority it consulted. Nobody has to read code to reconstruct it.

05

Preserve boundary signal

Observe carries unresolved contact into active assessment and routing instead of silently flattening it into a binary answer.

06

Audit the architecture

A regulator can inspect the module list, interfaces, authorities, and outcomes instead of tracing scattered conditionals across repositories.

After the modules decide

The Manifest makes the decision reconstructable.

See how BCOT Core records every Permit, Observe, and Abstain—with the conditions and deliberation that produced it.

Explore the Manifest

Architecture Review

Bring one commitment. Leave with its boundary.

Tell us a little about your architecture and the commitment you want to review.

We’ll use these details only to respond to your request. Privacy