Show HN: StegCore – a decision boundary for AI systems (truth ≠ permission)
by the_rige1 | 2025-12-26 18:10:57+00:00
TL;DR
Most systems treat “verified” as “allowed.”
StegCore separates those concepts.

StegCore is a small, docs-first project that defines a decision boundary:
given verified continuity (from an external system), it answers allow / deny / defer, with explicit constraints like quorum, guardian review, veto windows, or time-locks.

No policy engine yet. No AGI claims. Just the missing layer.

⸻

The problem

Modern automation — especially AI-driven automation — usually collapses three things into one:
1. Truth (is this authentic / verified?)
2. Authority (is this allowed?)
3. Execution (do the thing)

That works… until it doesn’t.

When something goes wrong, there’s no clean place to:
• pause an action
• require consent
• escalate to a human
• recover without shutting everything down

Verified truth alone doesn’t tell you what is permitted.

⸻

What StegCore does

StegCore defines a narrow interface:

Given verified continuity, can this actor perform this action right now — and under what constraints?

Inputs:
• verified continuity evidence (opaque to StegCore; e.g. from StegID)
• actor class (human / AI / system)
• action intent
• policy context (structure only)

Output:
• allow, deny, or defer
• a stable, machine-readable reason code
• optional constraints (quorum, guardian, veto window, time-lock, escalation)

StegCore:
• does not verify receipts
• does not store identity
• does not execute actions
• does not claim autonomy or intelligence

It declares decisions. Other systems act (or don’t).

⸻

Why “defer” matters

Most systems only support allow or deny.

In real systems, the safest answer is often:
• “not yet”
• “with consent”
• “after review”
• “after a delay”

StegCore treats defer as a first-class outcome, not a workaround.

That’s the difference between:
• brittle automation
and
• recoverable automation

⸻

What’s in the repo today
• Clear decision model and policy shape docs (authoritative)
• Explicit agent lifecycle (intent → continuity → decision → execution)
• A minimal, deterministic decision interface with tests
• Scaffolding for state/audit signals (not continuity truth)

There is no policy engine yet. That’s intentional.

The docs are the contract; code is subordinate.

⸻

What this is not
• Not an AGI claim
• Not an auth system
• Not identity management
• Not a rules engine
• Not a replacement for existing security tooling

It’s a missing layer that can sit between verification and execution.

⸻

Why this exists

We kept seeing the same failure mode:

“The system was technically correct, but it shouldn’t have been allowed to do that.”

StegCore exists to make “allowed” explicit.

⸻

Positioning (locked)

We’re not building general intelligence.

We are enabling:

AI systems that are accountable, recoverable, and constrained by verifiable continuity.

⸻

Status
• v0.1
• docs-first
• minimal decision boundary implemented
• open to feedback before any policy runtime is built

Repo: https://github.com/StegVerse-Labs/StegCore

⸻

Questions we’d love feedback on
• Is the separation between truth and permission clear?
• Are “defer” + constraints useful in your systems?
• Where does this boundary already exist implicitly, but undocumented?
• What would you want before trusting a decision runtime?

Thanks for reading — happy to answer questions and clarify boundaries.