SC-SMT is an AI and automated-decision governance layer designed to keep decisions and downstream actions aligned when the evidence or knowledge behind them changes.
Instead of treating new information as a simple memory update, SC-SMT evaluates how a change affects existing decisions, dependencies, authorizations, and actions.
The system can identify when a previously valid decision is no longer trustworthy, place dependent actions on hold, require revalidation against current authoritative evidence, and prevent stale authorizations from being used for execution.
Modern AI and automated decision systems continuously operate on changing information.
A decision may have been valid when it was created, but the evidence behind that decision can later:
- expire
- be corrected
- be superseded
- conflict with new evidence
- change in authority
- become invalid because of time
- affect downstream rules, summaries, representations, or actions
A conventional workflow may update the latest data without automatically determining which existing decisions and actions have become unsafe or stale.
This creates a critical governance problem:
What happens to an existing decision when the knowledge behind it changes?
SC-SMT is designed to address that problem.
AI systems that remain reliable when knowledge changes.
SC-SMT is intended to provide a governance layer between changing evidence and consequential automated actions.
The product tracks the relationship between:
Evidence
↓
Facts
↓
Rules / Decisions
↓
Downstream Dependencies
↓
Actions
When evidence changes, SC-SMT evaluates the affected dependency chain and determines what must happen next.
The core product workflow is:
Evidence
↓
Evidence Evaluation
↓
Semantic / State Change Detection
↓
Dependency Impact Analysis
↓
Decision Revalidation
↓
Authorization
↓
Execution-Time Validation
↓
External Action
↓
Audit Trail
The system is designed around three primary governance states:
The required checks have passed for the exact decision, evidence versions, policy version, and action parameters.
The action may proceed through the execution gateway.
A defined policy or governance rule explicitly prohibits the action.
The action must not proceed.
Required evidence, verification, dependency processing, or revalidation is incomplete or uncertain.
The action does not proceed until the governance condition is resolved.
The current MVP demonstrates a purchase approval scenario.
A purchase action depends on a vendor qualification.
Initially:
Vendor Qualification = VALID
↓
Decision = CURRENT
↓
Purchase Action = PENDING
When the qualification expires:
Vendor Qualification = EXPIRED
↓
Decision = REVALIDATION_REQUIRED
↓
Purchase Action = HOLD
A new qualification is then received and verified:
New Qualification = VERIFIED
↓
Decision = REVALIDATION_REQUIRED
The new evidence does not automatically authorize the old decision.
The decision must be revalidated:
Verified Evidence
↓
Decision REVALIDATED
↓
Authorization
↓
Execution-Time Validation
↓
Action EXECUTED
SC-SMT is not intended to be:
- another LLM
- another chatbot
- a generic vector database
- a generic knowledge graph
- a simple approval workflow
- a memory store
The core product idea is:
When the underlying evidence changes, determine what decisions and actions are affected and govern whether those decisions and actions can remain valid.
The distinction is therefore:
Traditional Decision System
Current State
↓
What should I decide?
SC-SMT
Evidence changed
↓
What became affected?
↓
What must be revalidated?
↓
What actions must stop?
↓
Can the exact action still execute?
Evidence represents information received by the system.
Evidence is versioned and can carry:
- source
- status
- validity interval
- verification state
- authority state
- timestamps
- supporting context
Examples:
Vendor qualification
Employee certification
Contract approval
Compliance status
Purchase limit
Security authorization
Policy revision
SC-SMT distinguishes between different evidence conditions.
Examples include:
RECEIVED
VERIFIED
AUTHORITATIVE
EXPIRED
SUPERSEDED
CONFLICTED
QUARANTINED
An important product principle is that received evidence is not automatically authoritative evidence.
Decisions and actions depend on specific evidence or derived state.
For example:
vendor.qualification.status
↓
Purchase Approval Decision
↓
Submit Purchase Order Action
When the upstream evidence changes, SC-SMT identifies the affected downstream objects.
A decision represents a governed business or AI decision.
A decision may contain:
- decision identifier
- rule/policy version
- policy hash
- evidence bindings
- current governance state
- dependency relationships
- revalidation status
A decision that was previously valid can become:
CURRENT
REVALIDATION_REQUIRED
BLOCKED
HOLD
depending on the governance condition.
Authorization is not treated as a permanent permission.
It is bound to the exact governed state used when the action was authorized.
The binding can include:
Evidence Version
Policy Version
Decision State
Action Parameters
Therefore, changing the governed state can invalidate an existing authorization.
The execution gateway performs a final validation immediately before an external action is committed.
Conceptually:
Request Execution
↓
Is authorization active?
↓
Is decision still current?
↓
Are evidence bindings unchanged?
↓
Are action parameters unchanged?
↓
Are governance checks satisfied?
↓
EXECUTE
Otherwise:
HOLD / BLOCK
Every important governance transition records:
- actor
- event
- reason
- supporting context
- affected object
- timestamp
Example:
EVIDENCE CHANGED
↓
DECISION REVALIDATION REQUIRED
↓
ACTION HOLD
↓
EVIDENCE VERIFIED
↓
DECISION REVALIDATED
↓
ACTION AUTHORIZED
↓
ACTION EXECUTING
↓
ACTION EXECUTED
This creates a traceable governance history.
The current repository contains the first product-oriented implementation of SC-SMT.
The MVP currently includes:
- persistent SQLite storage
- evidence versioning
- evidence status and validity handling
- dependency registration
- dependency cycle rejection
- decision registration
- evidence bindings
- policy version/hash binding
- decision revalidation
- authorization binding
- action parameter hashing
- execution-time validation
- idempotency-key handling
- audit events
- expiry handling
- purchase-approval demonstration scenario
- browser-based demonstration UI
- automated product tests
- Docker support
The external action is currently simulated.
This is intentional: the MVP focuses on validating the governance mechanism before introducing production external connectors.
Current MVP stack:
Frontend
HTML
CSS
JavaScript
Backend
Node.js
Database
SQLite
Runtime
Node.js 22+
Testing
Node.js test framework
Deployment
Docker
The implementation currently avoids unnecessary third-party runtime dependencies.
┌─────────────────────┐
│ AI / Business Logic │
│ Decision System │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ SC-SMT │
│ │
│ Evidence Registry │
│ State Evaluation │
│ Dependency Engine │
│ Decision Governance │
│ Revalidation │
│ Authorization │
│ Execution Gate │
│ Audit Trail │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ External System │
│ / Action Adapter │
└─────────────────────┘
A simplified governed chain can be represented as:
Evidence
E1
│
▼
Fact
F1
│
▼
Derived Rule
P1
│
▼
Decision
D1
│
▼
Action
A1
A change to E1 can therefore affect downstream state.
SC-SMT is intended to identify that impact and trigger the appropriate governance response.
A successful lifecycle may look like:
SYSTEM SEEDED
↓
EVIDENCE CHANGED
↓
DECISION REVALIDATION REQUIRED
↓
ACTION HOLD
↓
EVIDENCE VERIFIED
↓
DECISION REVALIDATED
↓
ACTION AUTHORIZED
↓
ACTION EXECUTING
↓
ACTION EXECUTED
A failed revalidation may instead produce:
EVIDENCE CHANGED
↓
DECISION REVALIDATION REQUIRED
↓
ACTION HOLD
↓
DECISION REVALIDATION FAILED
↓
ACTION HOLD
SC-SMT is being developed around several principles.
Consequential actions should depend on verified and current evidence.
Changes to evidence should propagate through registered dependencies.
The system should distinguish between permission, prohibition, and unresolved state.
ALLOW
BLOCK
HOLD
An authorization should be associated with the exact governed state under which it was created.
The system should perform a final state check immediately before an external action is committed.
Governance transitions should be reconstructable from the audit history.
Missing, conflicting, expired, or insufficiently verified evidence should not silently result in authorization.
SC-SMT is currently a product MVP / research-derived prototype.
The goal at this stage is to validate the mechanism and product workflow.
It should not yet be considered a production safety or compliance platform.
The current external action adapter is simulated.
Production implementation would require additional work around:
- authentication
- authorization and RBAC
- multi-tenant isolation
- secrets management
- connector security
- external API integration
- idempotency contracts
- durable event/outbox processing
- failure recovery
- observability
- alerting
- backup and recovery
- security testing
- scalability
- compliance controls
Completed / implemented:
Evidence
Dependency Tracking
Decision Revalidation
Authorization
Execution Gate
Audit Trail
Current focus:
Expiry
Old Authorization Reuse
Action Parameter Tampering
Duplicate Execution
Missing Evidence
Conflicting Evidence
Unrelated Evidence Change
Planned:
Impact Map
Dependency Blast Radius
Affected Decision View
Affected Action View
Revalidation Queue
Governance Dashboard
Potential future integrations:
ERP
Procurement
HR
Compliance
Identity
Financial Systems
AI Decision Engines
Workflow Platforms
Planned areas:
Security
RBAC
Multi-tenancy
Connector Authentication
Durable Execution
Observability
Recovery
Scalability
Compliance
SC-SMT/
│
├── server.js
│
├── public/
│ ├── index.html
│ ├── app.js
│ └── styles.css
│
├── test/
│ └── product.test.js
│
├── data/
│ └── .gitkeep
│
├── PRODUCT_BEHAVIORAL_SPEC_v0.2.md
├── data-model.json
├── package.json
├── Dockerfile
├── README.md
└── .gitignore
Install and run with Node.js.
npm install
npm startThe application exposes the local demonstration UI.
The current product demo uses a simulated external action adapter.
Current status: Active development
SC-SMT has progressed from a research concept into a working product-oriented MVP.
The current priority is to validate governance behavior under changing and adversarial conditions before expanding the product surface.
No open-source license is currently applied.
SC-SMT is currently maintained as a private product/research project.
SC-SMT
Working product description:
AI and automated-decision governance for changing knowledge and evidence.
Product promise:
AI systems that remain reliable when knowledge changes.
---
# 2. `PRODUCT_OVERVIEW.md`
```markdown
# SC-SMT Product Overview
## 1. Product Name
**SC-SMT**
### Product Promise
> AI systems that remain reliable when knowledge changes.
### Product Category
AI / Automated Decision Governance
---
# 2. Product Problem
AI systems and automated business systems make decisions using evidence available at a particular point in time.
That evidence can later change.
For example:
```text
Vendor qualification expires
Employee certification expires
Contract changes
Policy changes
Compliance status changes
Authorization changes
Pricing changes
A previously valid decision can therefore become stale.
The core problem is:
How does a system determine what existing decisions and actions are affected when the evidence behind them changes?
SC-SMT introduces a governance layer between evidence changes and consequential actions.
The system:
- registers evidence
- tracks evidence state and version
- registers dependencies
- identifies affected decisions
- requires revalidation
- governs downstream actions
- creates exact-state authorization
- performs execution-time validation
- records the complete audit trail
Evidence
↓
Evidence Evaluation
↓
Change Detection
↓
Dependency Closure
↓
Affected Decision Identification
↓
Decision Revalidation
↓
Authorization
↓
Execution-Time Validation
↓
External Action
↓
Audit Trail
All required governance conditions are satisfied.
The exact action may proceed through the execution gateway.
A policy or governance rule explicitly prohibits the action.
The action must not proceed.
The evidence, dependency state, verification, or revalidation is incomplete or unresolved.
The action must remain stopped.
Qualification VALID
↓
Purchase Decision CURRENT
↓
Purchase Action AUTHORIZED
Qualification expires:
Qualification EXPIRED
↓
Decision REVALIDATION_REQUIRED
↓
Purchase Action HOLD
New qualification arrives:
New Qualification VERIFIED
↓
Decision still requires explicit revalidation
Revalidation succeeds:
Decision CURRENT
↓
Authorization
↓
Execution-Time Validation
↓
Purchase Submitted
A key SC-SMT principle is:
New evidence should not silently make an old decision valid again.
The new evidence must pass the required verification and governance checks.
The dependent decision must be revalidated before the action becomes executable again.
SC-SMT treats authorization as a state-bound object.
Conceptually:
Authorization
│
├── Decision
├── Evidence Version
├── Policy Version
└── Action Parameters
Changing any governed component can invalidate the authorization.
Execution should not rely only on an earlier authorization event.
Immediately before the external action is committed:
Authorization Check
↓
Decision State Check
↓
Evidence Binding Check
↓
Action Parameter Check
↓
Governance Check
↓
External Execution
This is intended to prevent stale authorization from being reused.
The product currently governs:
- registered decisions
- registered actions
- known dependencies
- known evidence
- defined governance rules
The system does not claim to automatically understand every dependency in an arbitrary external system.
Where required evidence is missing or dependency processing is incomplete, the intended behavior is to move to HOLD rather than guess.
The MVP uses a purchase approval scenario.
Action:
SUBMIT_PURCHASE_ORDER
Decision:
D-104
Action:
A-2207
External target:
SIMULATED_PROCUREMENT_SYSTEM
The external adapter is intentionally simulated at this stage.
The long-term goal is to provide a reusable governance layer for AI and automated decision systems that need to operate safely as underlying evidence changes.
Potential use areas include:
Procurement
Finance
Healthcare
Compliance
HR
Identity
Risk
Enterprise AI
Automated Approval
Workflow Automation
These are potential application areas, not current production integrations.
---
# 3. `WORKFLOW.md`
```markdown
# SC-SMT Workflow
## End-to-End Governance Workflow
SC-SMT governs the relationship between changing evidence and downstream automated actions.
---
## 1. Evidence Registration
Evidence enters the system.
Example:
```text
Vendor Qualification
Status = VALID
Source = Verified Vendor System
Version = EV-005
Evidence is stored as a versioned record.
The system determines whether the evidence can be treated as verified and authoritative.
Conceptually:
RECEIVED
↓
VERIFIED
↓
AUTHORITATIVE
The product distinguishes between evidence merely being received and evidence being trusted for governance.
A decision is linked to the evidence required for that decision.
Example:
vendor.qualification.status
↓
D-104 Purchase Approval
↓
A-2207 Submit PO
Evidence can change because of:
Expiration
Correction
Replacement
Supersession
Conflict
Policy Revision
Time Change
Authority Change
Example:
EV-005
VALID
↓ expires
EV-006
EXPIRED
SC-SMT determines which registered objects depend on the changed evidence.
Example:
EV-006
↓
D-104
↓
A-2207
The action becomes part of the governance impact chain.
The previous decision can no longer automatically remain current.
Example:
Decision D-104
CURRENT
becomes:
Decision D-104
REVALIDATION_REQUIRED
A dependent action is prevented from proceeding while its governing decision is unresolved.
A-2207
HOLD
New or corrected evidence is verified.
The decision is explicitly re-evaluated.
Possible outcomes:
CURRENT
BLOCKED
HOLD
When the decision becomes current, an authorization may be created.
The authorization binds to the relevant state.
Example:
Decision = D-104
Evidence = EV-007
Policy = P-v1
Action Hash = ...
Before external execution:
Is authorization active?
Is decision current?
Are evidence bindings unchanged?
Is policy unchanged?
Are action parameters unchanged?
Are governance conditions satisfied?
All required checks must pass.
Only after the gateway accepts the authorization can the external action proceed.
Current MVP:
SIMULATED_PROCUREMENT_SYSTEM
Future production adapters would require their own failure recovery and idempotency contracts.
Every major transition is recorded.
Example:
EVIDENCE CHANGED
DECISION REVALIDATION REQUIRED
ACTION HOLD
EVIDENCE VERIFIED
DECISION REVALIDATED
ACTION AUTHORIZED
ACTION EXECUTING
ACTION EXECUTED
This provides a traceable governance history.
---
# 4. `ARCHITECTURE.md`
```markdown
# SC-SMT Architecture
## High-Level Architecture
```text
┌───────────────────────────────┐
│ AI / Business Decision System │
└───────────────┬───────────────┘
│
▼
┌───────────────────────────────────────────┐
│ SC-SMT │
│ │
│ Evidence Registry │
│ ↓ │
│ State / Validity Evaluation │
│ ↓ │
│ Dependency Engine │
│ ↓ │
│ Decision Governance │
│ ↓ │
│ Revalidation │
│ ↓ │
│ Authorization │
│ ↓ │
│ Execution Gate │
│ ↓ │
│ Audit Trail │
└────────────────┬──────────────────────────┘
│
▼
┌───────────────────────────────┐
│ External System / Action │
│ Adapter │
└───────────────────────────────┘
Maintains versioned evidence records.
Tracks:
- source
- version
- status
- validity
- verification
- authority
- timestamps
Maintains relationships between:
Evidence
Facts
Decisions
Actions
Used to identify downstream impact when upstream evidence changes.
Determines whether an existing decision remains current.
Possible states include:
CURRENT
REVALIDATION_REQUIRED
BLOCKED
Creates an authorization bound to:
Evidence
Decision
Policy
Action Parameters
Performs the final validation immediately before an external action is committed.
The gateway is intended to be the last governance control before consequential execution.
Stores governance events with:
Actor
Reason
Object
Context
Timestamp
Current MVP persistence:
SQLite
Primary entities include:
sources
evidence
dependencies
decisions
actions
authorizations
audit_events
The current external adapter is simulated.
This allows the governance mechanism to be validated without causing real-world side effects.
Production adapters will require:
- authenticated communication
- idempotency
- timeout handling
- retry behavior
- distributed failure recovery
- reconciliation
---
# 5. `DEVELOPMENT_STATUS.md`
```markdown
# SC-SMT Development Status
## Current Version
SC-SMT Product MVP v0.2
---
# Completed
### Core Governance
- [x] Evidence registration
- [x] Evidence versioning
- [x] Evidence validity
- [x] Evidence verification state
- [x] Dependency registration
- [x] Dependency cycle rejection
- [x] Decision registration
- [x] Decision evidence binding
- [x] Policy version/hash binding
- [x] Decision revalidation
- [x] Action authorization
- [x] Action parameter binding
- [x] Execution-time validation
- [x] Idempotency handling
- [x] Audit events
- [x] Expiry handling
---
# Validated Manually
## Qualification Expiry
Validated behavior:
```text
EVIDENCE CHANGED
↓
DECISION REVALIDATION REQUIRED
↓
ACTION HOLD
Attempted revalidation with invalid evidence produces:
DECISION REVALIDATION FAILED
↓
ACTION HOLD
After verified replacement evidence:
EVIDENCE VERIFIED
↓
DECISION REVALIDATED
↓
ACTION AUTHORIZED
↓
ACTION EXECUTING
↓
ACTION EXECUTED
The next validation scenarios are:
- Old authorization reuse
- Action parameter tampering
- Duplicate execution
- Missing evidence
- Conflicting evidence
- Unrelated evidence change
The external execution system is currently simulated.
The product should not yet be treated as a production safety, compliance, or autonomous execution platform.
Show:
Changed Evidence
↓
Affected Dependencies
↓
Affected Decisions
↓
Affected Actions
↓
Required Revalidation
Future dashboard concepts:
Current Decisions
Revalidation Required
Blocked Decisions
Held Actions
Evidence Changes
Affected Actions
Recent Governance Events
Future areas:
Authentication
RBAC
Multi-Tenancy
Connector Security
Secrets Management
Durable Events
Execution Recovery
Observability
Monitoring
Backup / Recovery
Security Testing
Scalability
Compliance
---
# 6. `PRODUCT_POSITIONING.md`
```markdown
# SC-SMT Product Positioning
## One-Line Description
> SC-SMT is a governance layer that keeps AI and automated decisions aligned with changing evidence.
---
## Product Promise
> AI systems that remain reliable when knowledge changes.
---
## Core Question
Traditional AI decision systems ask:
> Given the current information, what should the system decide?
SC-SMT focuses on a different question:
> When the evidence behind an existing decision changes, what becomes affected, what must be revalidated, and can the dependent action still execute?
---
## Product Model
```text
Knowledge Changes
↓
Impact Detection
↓
Decision Revalidation
↓
Action Governance
↓
Execution Control
SC-SMT is centered on change propagation and governance, rather than only generating a new decision from the latest state.
The product attempts to preserve the relationship between:
Evidence
Decision
Dependency
Authorization
Action
when the evidence changes.
Proposed category:
AI Knowledge & Action Governance
Alternative description:
Evidence-Driven Decision Governance
Organizations increasingly use AI and automation to make or execute decisions.
The underlying evidence may change after a decision is made.
SC-SMT is designed to provide a governance layer that identifies affected decisions and prevents stale actions from proceeding without revalidation.
Potential areas include:
- procurement approvals
- financial approvals
- healthcare workforce compliance
- employee certification
- regulatory controls
- policy-driven automation
- enterprise AI decisions
- risk workflows
- automated approvals
These represent potential future application areas rather than existing production integrations.