Category: Aegis · Cybersecurity & Trust Intelligence
Security decisions you can trace — evidence first, action authorized.
Aegis is an authorized-beta security and trust-intelligence method. It keeps potential technical severity, current threat and environmental context, and evidence confidence as separate decision fields, while treating every active action as a proposal that still requires explicit human authorization.
Built for
- Individuals & executives
- SMEs & operating teams
- Security & compliance professionals
- Status
- Beta
- Ledger step
- Ledger step 3 of 4
- Family
- Workspaces
- Access
- This site only
- Listed
- Last change
- None since listing
- In development
- Beta
- Method boundary
- Authorized-only
- Independent decision fields
- 3 axes
- Active-action boundary
- Human decision
See it working
A real capture of the live product, not a mock.
What this page can show today
- The register marks this track as a public test or verification build.
- This track is documented on this site only.
- Capabilities below are the published feature list for this track.
Limits of this page
- No public product site is published for this track.
- Beta is not a production claim.
- This page does not publish financials, headcount, or client names.
Key features
- 01
One authorized risk view
Website, application, infrastructure, physical-privacy and compliance signals are correlated in one evidence model.
- 02
Evidence before findings
Every finding carries a source, timestamp, method and confidence; severity cannot rise without additional evidence.
- 03
Human approval boundary
Active, disruptive or outbound actions remain blocked until the authorized operator explicitly approves them.
- 04
Verified risk reduction
Remediation is not counted as complete until a retest confirms that the evidence-backed finding is closed.
Published links
Technology stack
Python · Self-contained HTML · Ephemeral in-memory · Physical-privacy
Related platforms
Family on the register: Workspaces Same family first, then tracks at the same lifecycle stage.
Same family · Live
CoreAIPrivate AI Operations
Invite only
Same family · Beta
AperturamacOS Productivity
This site only
Same family · Beta
TetherSession Continuity
This site only
Same stage · Beta
SkillSwipeRecruitment Technology
Public product site
This cell on the investor register
Status and family write into the /investors URL. The holdings table lists every public track in that cell.
Open Beta Workspaces holdingsJSON fields are copied from this row in src/data/platforms.ts. No financials.
How this track works
Audience on the left, the published Ember stack in the middle, capabilities on the right. Every node is copied from this track in the public register.
Inputs
Coreidea and Ember
This track does not name an Ember model on its published stack.
Outputs
Select a node to inspect the published role and capability.
One score cannot carry an entire decision.
A technical severity estimate, current exploitation context and confidence in the underlying observation answer different questions. Collapsing them hides uncertainty and makes review harder.
Severity is not organizational risk
A technical Base score describes intrinsic characteristics under defined assumptions. Threat activity, the environment and business impact still need separate context.
Uncertainty needs its own field
Source identity, method, freshness, scope match and reproducibility determine how strongly an observation is supported. They should not silently rewrite technical severity.
A recommendation is not authority
Evidence and proposed next steps can support a decision. They do not establish permission to scan, probe, change, remediate or close an external system.
Separate the axes. Preserve human authority.
The public beta method defines a traceable evidence vocabulary and an explicit decision rail. It is a design boundary, not a claim of certification, autonomous enforcement or completed implementation.
One scoped evidence view
The intended schema can organize authorized observations from applications, infrastructure, privacy and control reviews without pretending every source is equivalent.
Severity, context and confidence stay separate
Technical severity remains distinct from Threat and Environmental context. Aegis evidence confidence describes support for the observation and is not a CVSS metric.
Active action remains a proposal
The method requires a named owner to review the target, intended effect and evidence before any active step. A proposal is not authorization or execution.
Closure needs fresh evidence
A remediation note does not prove risk reduction. The method keeps closure pending until an authorized retest supplies fresh, scope-matched evidence.
Authorize. Separate. Decide. Retest.
Authorize the scope
Record the owner, target, allowed method, time window and stop conditions before collecting evidence.
Describe the evidence
Attach source identity, observation method, timestamp, scope match and reproducibility notes to each observation.
Keep decision fields independent
Record potential technical severity, Threat and Environmental context, and evidence confidence without collapsing them into one opaque score.
A named human decides
Present the evidence package and proposed next step to the authorized owner. Record approve, reject or request-more-evidence as distinct outcomes.
Remediate, then retest
Treat remediation and closure as separate events. Only fresh authorized evidence can support a later risk-reduction decision.
A public method, with explicit boundaries.
Evidence schema
The proposed schema preserves source, method, freshness, scope and reproducibility alongside the observation it supports.
Independent decision fields
The method does not lower or raise technical severity because evidence confidence changed. It exposes the disagreement for human review.
Decision record
The intended record links a named owner, scope, proposed action, decision and retest evidence without claiming that the beta already enforces every transition.
Framework references, not certification
Aegis references NIST CSF 2.0, FIRST CVSS v4.0, CISA KEV and OWASP verification guidance. Reference does not establish compliance, endorsement or regulator acceptance.
Who the beta method is for.
Risk owners
People who need to see why a technical observation matters now, what remains uncertain and who owns the next decision.
Operating teams
Teams that need a scoped evidence package before deciding whether to investigate, accept, remediate or retest.
Security reviewers
Reviewers comparing technical severity, current threat context and observation quality without hiding disagreement.
Assurance teams
Teams designing traceable review records while keeping framework mapping separate from certification or legal conclusions.
Questions, answered.
What does "authorized-only" mean?
The method requires a named owner, target, allowed method, time window and stop conditions before evidence collection. Nothing in the public artifact grants permission to test a system.
How is severity different from confidence?
FIRST CVSS Base metrics describe intrinsic technical characteristics; Threat and Environmental metrics add context. Aegis evidence confidence instead describes support for the observation and is not a CVSS metric.
What happens when evidence is thin?
The technical severity field remains unchanged. Evidence confidence is marked limited, missing observations are named and the decision can remain pending rather than implying certainty.
How do I get access?
Aegis is in controlled beta. Contact info@coreidea.cn to discuss an authorized testing scope. The public method is not an assessment, certification or authorization.
Bring the scope. Keep the decision.
Request an authorized beta conversation. The public artifact defines the method and its limits; it is not a security assessment or permission to test.