SDIR: Training Data Contamination and Structural Integrity

What it addresses

Abnormal synthetic content mixed into training data, distribution collapse, and structural quality degradation can undermine the learning foundation of a model. SDIR focuses on structural differences between data samples and changes in contamination proportion to identify early signals of risk formation.

In internal testing on public datasets, SDIR detected 88% of contamination at a 5% contamination rate, and 100% at contamination rates of 10% and above, with a 5% false alarm rate on clean data.

Signals it observes

SDIR observes the structural statistical features of samples or batches, distribution shift, repetition, type proportions, abnormal clustering, and detection response at different contamination proportions. Combined with control samples and detection thresholds, it outputs data integrity signals for re-check.

Separately, an earlier single-document discrimination study reported approximately 0.90 AUC. That figure comes from a different stage and a different metric than the contamination-rate figures above, and it should not be read as the same measurement.

How it is used

SDIR is used mainly for pre-training data inspection, data preparation, batch quality assessment, and technical research on public or authorized datasets. It can provide internal detection results, clues to the location of data anomalies, and re-check material.

SDIR can run on its own and add early risk signals, a second observation layer, and re-check evidence to a customer's existing security system, with little added operating burden. Where protective action is needed, it works within the authorization boundaries set by the customer.

Public demo

SDIR on GitHub | SDIR 3.0 performance showcase

Development status

SDIR has public dataset studies and internal experiment records from the founder, including the contamination-rate test results reported above and the separate single-document discrimination report of approximately 0.90 AUC. Different tasks and experiment versions are reported separately. Work continues on experiment reproduction, threshold analysis, and engineering adaptation.

Back to Frameworks

SOD: Statistical and Structural Anomaly Detection

What it addresses

Complex data flows and system states can shift in statistical structure while still looking normal on the surface. SOD watches whether those shifts cross the boundary of normal variation, helping to surface potential quality, operational, and security problems.

Signals it observes

SOD observes changes in mean and dispersion, the proportion of outliers, distribution shape, change points, deviation within time windows, feature associations, and structural stability across batches. Comparison against baselines and thresholds produces anomaly grading and evidence for re-check.

How it is used

SOD is used for data intake, system state checks, observation of model-related data distributions, and supplementary re-check of operating state. It can serve as a second statistical observation channel alongside existing monitoring systems.

Operating independently, SOD can give a customer's existing security system additional early risk signals, a second observation layer, and re-check evidence, at low added operating cost. Any protective action it supports stays within the authorization boundaries the customer has set.

Development status

SOD has a research and internal experiment base. Its standalone version, indicator configuration, and latest re-verification results are still to be updated against the original records. Research and engineering optimization are in progress.

Back to Frameworks

PAC: Poisoning and Attack Signal Detection

What it addresses

An AI system can be pushed off course by contaminated training material, abnormal input, and hostile calls. PAC studies the link between risk sources and the conditions under which attack succeeds, giving existing security processes an earlier signal of suspicion.

Signals it observes

PAC observes abnormal input batches, sudden shifts in feature distribution, concentration of abnormal sources, short bursts of hostile calls, suspicious injection patterns, and the association between those patterns and changes in system behavior, including differences in state before and after an attack.

How it is used

PAC is used for training-data intake, input interfaces, and related research and testing environments. It supports sending suspicious signals found to re-check, isolation, or other customer-authorized response mechanisms.

Deployed on its own, PAC can supply a customer's existing security system with extra early risk signals, a second observation layer, and evidence for re-check, without adding much operating burden. Where protection is required, it operates inside the authorization boundaries set by the customer.

Development status

PAC has an established research direction, a prototype, and internal experiment records. Measurable indicators for specific attack types and the scope of protection are being further refined and verified.

Back to Frameworks

CPC: Adversarial Input and Security Policy Bypass

What it addresses

In AI interaction, input can attempt to bypass the security boundaries set for the model, the application, or the execution environment. CPC finds the signs of risk in adversarial behavior and changing context, strengthening protection at input and operational boundaries.

Signals it observes

CPC observes unusual interaction sequences, triggers at policy boundaries, tendencies toward instructions beyond authorization, sudden changes in call context, abnormal operation chains, and related execution results, passing signs of departure from authorized rules to the relevant control mechanism.

How it is used

CPC applies to AI service input entry points, application interaction, and security policy coordination, serving as an additional observation layer for a customer's existing input filtering and policy control tools.

As an independent module, CPC can provide a customer's existing security system with additional early risk signals, a second observation layer, and re-check evidence, with low added operating burden. Protective action, where needed, takes place within the authorization boundaries set by the customer.

Development status

CPC has an established research and internal technical validation direction. Its specific version, formal English expansion, and the threat scenarios it covers are being confirmed and extended.

Back to Frameworks

PID: Privacy Information and Authorization Risk Detection

What it addresses

Protecting sensitive information concerns not only the information itself, but also who accesses, processes, or attempts to spread it, and under what conditions. PID focuses on the abnormal relationship between privacy risk and access authorization.

Signals it observes

PID observes access identity and authorization context, frequency of access to sensitive resources, abnormal access times, permission changes, widening access scope, unusually high request density, and signals of departure from the customer's privacy policy.

How it is used

PID is used in enterprise data processing, AI applications, and customer environments with high confidentiality requirements, supporting privacy risk alerts, policy coordination, and local review.

Running independently, PID can add early risk signals, a second observation layer, and re-check evidence to a customer's existing security system, while keeping added operating burden low. Where protective action is required, it acts within the authorization boundaries set by the customer.

Development status

PID is studying privacy-related signals and minimum-necessary data observation methods. The scope of content exposure and the functional effect in different use scenarios continue to be determined through specific implementation and testing.

Back to Frameworks

DAEF: Abnormal Data Exfiltration and Risk Effect Control

What it addresses

Data leakage does not always appear as a single large-scale copy. Abnormal exports, sustained small transfers, and changing data access patterns can also be signs that exfiltration risk is gradually forming.

Signals it observes

DAEF observes changes in the scale of data reads, exports, and transfers relative to the normal baseline, sudden increases and sustained accumulation, abnormal destinations, frequency and time distribution, abnormal sessions, and asymmetry between reads and writes.

How it is used

DAEF works as a supplementary detection module in data systems and in runtime network and process monitoring. Its focus is early warning, coordinating where necessary with customer-authorized restriction, blocking, and review mechanisms.

On its own, DAEF can give a customer's existing security system additional early risk signals, a second observation layer, and re-check evidence, with little added operating burden. Any protective action it supports operates within the authorization boundaries set by the customer.

Development status

DAEF has research and a module design in place. Experiments are in progress on identifying abnormal access and exfiltration signals, risk thresholds, the timing of response, and verification of state before and after an event.

Back to Frameworks

Drift: Runtime Behaviour and System State Drift

What it addresses

A system can drift gradually away from its established normal behaviour while it keeps running, showing up as slow change in performance, access patterns, operating relationships, or task outcomes. Drift is designed to catch these gradual changes early, so risk is visible before a significant incident occurs.

Signals it observes

• Behaviour frequency within sustained time windows
• State transitions
• Resource use patterns
• Anomaly event density
• Deviation magnitude and drift duration
• Sudden versus gradual change
• Consistency across multiple signals

How it is used

Drift supports long-running AI services and related digital systems, helping customers maintain normal baselines, analyse abnormal trends, and receive early risk alerts. It runs alongside the customer's existing monitoring.

Drift can run on its own and give a customer's existing security system additional early risk signals, a second layer of observation, and re-check evidence, with low added operating burden. Where protective action is required, it operates within the authorization boundaries set by the customer.

Development status

Early-stage work on lightweight operation and fixed-threshold detection has produced demonstration material. Further work is under way to evaluate resource consumption and alert quality under different loads.

Public demo: Drift detection demo on GitHub

Back to Frameworks

DRD: Repetition, Redundancy, and Event Processing Stability

What it addresses

Repeated input, replayed messages, or redundant events can cause errors to accumulate, work to be processed twice, or security decisions to be skewed. DRD identifies and suppresses these problems so event processing stays consistent.

Signals it observes

• Event uniqueness and fingerprints
• Repeat arrival frequency
• De-duplication windows
• Replay attempts
• State consistency under concurrency
• Behaviour across tenant boundaries
• How repeated operations affect processing outcomes

How it is used

DRD fits high-concurrency event processing, data streams, monitoring and alerting, and multi-tenant security environments, where it strengthens the stability of existing event processing frameworks.

As an independent module, DRD adds early risk signals, a second observation layer, and re-check evidence to the customer's existing security system, with low added operating burden. Where protective action is required, it operates within the authorization boundaries set by the customer.

Development status

Internal records show DRD v1.6.0-rc2 completed 81/81 internal tests, with a stress test record of 16 threads and 160,000 events. Work continues on version consolidation, re-verification, and reliability testing in wider environments.

Back to Frameworks

Subject Guard: Operating Subjects and Protected Boundaries

What it addresses

Security risk depends not only on whether an input file carries a malicious label, but also on whether the operating subject acting on it stays within its permitted scope. Subject Guard watches the correspondence between identity, permissions, and actual behaviour.

Signals it observes

• Subject identity and session
• Permitted operating scope
• Resource targets
• Abnormal permission changes
• Out-of-boundary access
• Protection action triggers
• Whether abnormal behaviour disappears after intervention

How it is used

Subject Guard is designed for operating environments with clearly defined permission boundaries. Once risk reaches a set threshold, it works with customer-authorized controlled blocking, reversible limits, and recovery procedures.

Running independently, Subject Guard supplies a customer's existing security system with additional early risk signals, a second observation layer, and re-check evidence, with low added operating burden. Where protective action is required, it operates within the authorization boundaries set by the customer.

Development status

A functional design for runtime protection and partial internal testing are in place. Work is under way on authorization consistency across environments, abnormal-action blocking, and recovery verification.

Public demo: Subject Guard demo on GitHub

Back to Frameworks

Ctrl: Customer Policy, Authorization Control, and Chain of Responsibility

What it addresses

Risk detection only creates commercial value when it leads to a reliable, controlled, and traceable response. Ctrl connects detection signals, customer policy, human authorization, and handling outcomes, so a system does not act on its own beyond the responsibility boundaries the customer has defined.

Signals it observes

• Alert levels
• Customer policy matching
• Action authorization status
• Handling requests and execution feedback
• Timeout and failure states
• Recovery gates
• Linked records covering the full course of an event

How it is used

Ctrl coordinates with HAS-Core detection modules or the customer's existing execution control points. It can provide decision support and audit signals only, or it can assist in carrying out protective action within the authorized scope.

On its own, Ctrl can give a customer's existing security system additional early risk signals, a second layer of observation, and re-check evidence, with low added operating burden. Where protective action is required, it operates within the authorization boundaries set by the customer.

Development status

Ctrl v0.1.0 internal simulation and unit tests passed 36/36, covering policy contracts, state, and the response chain. Work is under way on testing at real integration points and in live operating environments.

Back to Frameworks

HEMIG: Runtime and Endpoint Security Protection

What it addresses

HEMIG is the 11th professional security module of HAS-Core (Harmondeg Auditing System Core). It addresses the actual behaviour, abnormal effects, and security protection of AI and related digital systems at runtime and in endpoint environments. It focuses on abnormal behaviour as it happens and its effect on the protected system, supporting timely, controlled, and reversible protection once risk reaches a set intervention threshold, so ongoing operation stays safe and stable.

Signals it observes

• Process and execution activity
• Abnormal access frequency
• Sudden changes in resource use patterns
• Shifts in permission and operating boundaries
• Changes in target resource state
• Event trigger intensity
• Differences in anomaly signals before and after a protective action

Observation is built on a lightweight normal-behaviour baseline for the customer-authorized operating environment, with thresholds, observation windows, and risk response conditions configured for each deployment goal. Monitoring focuses on the necessary state and behaviour signals.

How it is used

HEMIG runs alongside other HAS-Core modules, including data integrity, privacy protection, drift detection, and policy control, or it can be deployed independently as a runtime supplement for a customer who needs it. It adds runtime behaviour observation, early anomaly signals, and a second layer of re-check evidence without replacing the customer's existing security equipment, helping customers decide earlier whether to take protective action.

Deployed on its own, HEMIG gives a customer's existing security system additional early risk signals, a second observation layer, and re-check evidence, with low added operating burden. Where protective action is required, it operates within the authorization boundaries set by the customer.

In normal operation, HEMIG carries out continuous, low-resource runtime observation. When an anomaly reaches an agreed threshold, it can provide early alerts or additional observation results to the customer's existing security system under the customer's security policy, or, in authorized scenarios, carry out limits, blocking, or reversible isolation. After protection, it keeps observing the same runtime signals, compares the state before and after the intervention, verifies that the anomaly is under control, and supports subsequent recovery and responsibility tracing. Risk events are recorded locally with their discovery, handling, authorization, and outcome, so normal user content is not turned into long-term monitoring logs.

HEMIG and HEMIG Mini Guard

HEMIG is the 11th HAS-Core module. HEMIG Mini Guard is a separate terminal application built from HEMIG technology. It is a standalone product with its own installation, authorization, version, and support arrangements. It is not a 12th HAS-Core module, it does not replace the HEMIG module, and it is not the same as HAS-Core itself.

Development status

HEMIG has an established research base in lightweight runtime anomaly monitoring, threshold-triggered protection, controlled blocking and reversible isolation, pre- and post-intervention verification, and local risk event and handling timeline records. The technology has undergone prototype and runtime testing in some Windows and virtual machine environments. Work continues on module engineering, compatibility, protection action reliability, resource cost, recovery verification, and integration with other HAS-Core components. The independent Mini Guard application is being advanced separately as product engineering and commercial release work.

Public demo: Core-guard demo on GitHub

Back to Frameworks