The News OS Object Registry defines the official objects that exist inside News OS, what each object is allowed to do, what fields it should carry, how objects connect to one another, and how they move through the runtime.

That is the cleanest starting point.

If the previous technical specification defined the whole machine, this page defines the named parts inside the machine.

Without an object registry, News OS remains descriptive.
With an object registry, News OS becomes much more legible as a real module stack for humans, institutions, and AI systems.

One-sentence answer

The News OS Object Registry is the canonical list of runtime objects, fields, relationships, and lifecycle rules that allow News OS to ingest reports, cluster events, separate layers, measure distortion, and output Balanced Event Packages.

Why this page matters

A serious operating system needs named objects.

Otherwise the system becomes noisy very quickly.

People start using similar words for different things:

source
report
event
claim
frame
narrative
package
board
update
correction

But those are not identical.

If News OS is going to be stable, then each object needs:

a clear name
a defined role
a stable ID pattern
required fields
allowed relationships
entry and exit rules
lifecycle logic

That is what this registry page is for.

1. Canonical object stack

The core News OS object stack is:

NWS_OBJ_CARRIER
NWS_OBJ_REPORT
NWS_OBJ_EVENT
NWS_OBJ_EVENT_CORE
NWS_OBJ_CLAIM
NWS_OBJ_FRAME
NWS_OBJ_INCENTIVE
NWS_OBJ_ATTRIBUTION
NWS_OBJ_GAUGE_STATE
NWS_OBJ_FILTER_ACTION
NWS_OBJ_BEP
NWS_OBJ_BOARD
NWS_OBJ_HANDOFF

These are the first locked object types.

They should be treated as the minimum stable runtime layer.

2. Object design rules

Before defining each object, the registry needs a few global rules.

Rule 1: One object, one main job

An object may connect to many other objects, but it should have one primary function.

Rule 2: Stable IDs matter

Each object should have a stable object ID so it can be tracked across time, revision, and handoff.

Rule 3: Objects should be linkable, not fused

Do not collapse report, claim, frame, and event into one object unless the system is still in raw intake mode.

Rule 4: Revision must be visible

Objects that change through time should carry revision state.

Rule 5: Scale discipline must remain explicit

Attribution and event objects must not silently jump scale.

Rule 6: Objects can inherit but should not blur

For example, an Event Core can inherit evidence links from reports, but it should still remain distinct from the reports themselves.

3. NWS_OBJ_CARRIER

Definition

A Carrier is a source lane that produces or transmits reports into News OS.

This is the outer intake channel.

A carrier is not yet a report.
It is the producing or transmitting lane.

Examples:

newspaper
broadcaster
wire service
ministry press office
official state portal
analyst newsletter
archive feed
local field reporter network
verified transcript channel

Job

Its job is to tell News OS where the report came from and what kind of lane it belongs to.

Required fields

carrier_id
carrier_name
carrier_family
carrier_type
region
language
institutional_role
default_content_mode
reliability_notes
active_status

Suggested optional fields

geographic proximity to event
historical correction discipline
typical ideological tilt
update cadence
archive depth
official / unofficial status
parent network

Edge ends

Carrier -> Report

A Carrier can produce many Reports.

It should not directly become an Event.

Lattice placement

Carrier itself does not sit inside +NWS / 0NWS / -NWS in the same way as event packages.

It is a feeder object.

But it can influence:

Source Spread
Frame Divergence
Primary-Source Anchor
Emotional Temperature
Correction / Revision quality

4. NWS_OBJ_REPORT

Definition

A Report is one discrete incoming information unit entering the News OS runtime.

Examples:

one article
one liveblog update
one official press statement
one press conference summary
one transcript
one correction note
one verified social clip routed into system intake

Job

Its job is to carry one bounded unit of incoming material into the parse-and-cluster layer.

Required fields

report_id
carrier_id
timestamp
headline_or_label
report_type
content_mode
candidate_event_links
candidate_claims
candidate_frames
primary_source_refs
revision_state

Suggested optional fields

emotion markers
attribution markers
quoted actors
geographic tags
subject tags
conflict tags
confidence notes
duplication cluster tag

Edge ends

Carrier -> Report -> Event candidate pool

A Report can:

support one Event
support many Events
later be removed from an Event cluster
contribute to Claims, Frames, Incentive readings, and Attribution cues

Lifecycle

intake
parse
tag
cluster candidate
accepted / rejected / archived / reclassified

Lattice placement

A Report is not itself the final lattice object.
It is a pre-lattice or feeder-layer object.

But poor report quality can pull the downstream event package toward -NWS_LATT.

5. NWS_OBJ_EVENT

Definition

An Event is the clustered runtime object representing one underlying happening in the world as inferred from multiple reports.

Examples:

election result event
sanctions announcement event
cabinet resignation event
missile strike event
court ruling event
transport disruption event
education policy change event

Job

Its job is to convert scattered article-flow into one tracked event object.

This is one of the most important transformations in News OS.

Required fields

event_id
event_name
event_type
event_scope
start_time_estimate
current_stage
actor_set
location_scope
linked_reports
status_open_closed
revision_version

Suggested optional fields

event family
parent event
child sub-events
event corridor
risk classification
institutional domain
cross-border relevance
archive continuity tag

Edge ends

Reports -> Event
Event -> Event Core / Claims / Frames / Incentives / Attribution / Gauges / BEP / Board / Handoff

The Event is the central routing object.

Lifecycle

detected
clustered
named
stabilized
revised
archived / split / merged / closed

Lattice placement

The Event is the first object that meaningfully enters the News OS lattice.

Depending on current quality, an Event can sit in:

-NWS_LATT
0NWS_LATT
+NWS_LATT

6. NWS_OBJ_EVENT_CORE

Definition

The Event Core is the current best structured reading of what most likely happened.

It is not the same thing as the Event object itself.

The Event is the tracked cluster.
The Event Core is the current best reconstruction inside that cluster.

Job

Its job is to provide a disciplined, explicit summary of the likely underlying happening.

Required fields

event_core_id
event_id
core_summary
confidence_band
open_uncertainties
direct_anchor_refs
revision_risk
fog_of_war_level

Suggested optional fields

alternative core interpretations
disputed segments
evidence ranking
time-window note
revision trigger conditions

Edge ends

Event -> Event Core
Event Core -> BEP / Board / Handoff

Lifecycle

initial draft
partial stabilization
revised core
mature core
archival core

Lattice placement

The Event Core is a major determinant of lattice movement.

Strong Event Core:

helps move 0NWS_LATT -> +NWS_LATT

Weak or collapsing Event Core:

pushes +NWS_LATT -> 0NWS_LATT
or 0NWS_LATT -> -NWS_LATT

7. NWS_OBJ_CLAIM

Definition

A Claim is a bounded assertion attached to an Event.

Examples:

“the strike was retaliatory”
“casualty numbers are X”
“the law will take effect next month”
“the minister resigned voluntarily”

Claims remain claims until sufficiently anchored.

Job

Its job is to prevent assertions from being silently upgraded to facts.

Required fields

claim_id
event_id
claim_text_or_summary
claimant
claim_type
support_status
independence_status
contradiction_state
duplication_cluster
confidence_band

Suggested optional fields

quoted source
claim direction
strategic ambiguity note
casualty / legal / political / economic category
contestation level

Edge ends

Report -> Claim
Claim -> Event
Claim -> Gauge readings / BEP

Lifecycle

extracted
classified
supported / contested / unresolved
revised / withdrawn / archived

Lattice placement

Claims mainly affect:

Claim Convergence
Duplication Risk
Narrative Lock
Event Core Stability

High-conflict claim fields often sit in 0NWS_LATT.
Claim chaos or propaganda-heavy fields can push toward -NWS_LATT.

8. NWS_OBJ_FRAME

Definition

A Frame is the interpretive packaging attached to an Event.

Examples:

reform
crackdown
deterrence
humanitarian catastrophe
democratic opening
corruption scandal
national security response

Job

Its job is to make interpretation visible as interpretation.

Without this object, frame tends to masquerade as event.

Required fields

frame_id
event_id
frame_label
frame_family
carrier_usage_set
dominance_level
divergence_level
narrative_lock_risk

Suggested optional fields

emotional charge
ideological direction
simplification pressure
moral loading
historical analogy pressure

Edge ends

Reports -> Frames
Frames -> Event / Gauge readings / BEP / Board

Lifecycle

detected
grouped
compared
dominance measured
revised or archived

Lattice placement

Frame objects strongly affect:

Frame Divergence
Emotional Temperature
Narrative Lock
Wrong-scale attribution pressure

Frames do not automatically make an event bad.
Invisible frame dominance does.

9. NWS_OBJ_INCENTIVE

Definition

An Incentive object represents a structural pressure that may shape how claims or frames are presented.

Examples:

domestic legitimacy protection
click capture
access maintenance
policy signaling
ideological reinforcement
market reassurance
diplomatic posture

Job

Its job is to stop the system from reading presentation as though it arose in a vacuum.

Required fields

incentive_id
event_id
linked_object_type
linked_object_id
incentive_type
directionality
distortion_risk
confidence_band

Suggested optional fields

actor set
commercial / political / institutional classification
expected narrative effect
suppression incentive
amplification incentive

Edge ends

Claim / Frame / Carrier -> Incentive
Incentive -> BEP / Board / Handoff

Lifecycle

inferred
classified
confidence-scored
revised or removed

Lattice placement

Incentive objects rarely decide lattice state alone.
They act as distortion-pressure modifiers.

10. NWS_OBJ_ATTRIBUTION

Definition

Attribution is the formal map of causality, blame, responsibility, and agency inside an Event package.

Job

Its job is to discipline blame and prevent wrong-scale collapse.

Required fields

attribution_id
event_id
actor_map
agency_assignments
causality_chain
scale_level
balance_rating
wrong_scale_risk

Suggested optional fields

trigger actor
responding actor
institutional failure note
overgeneralisation marker
civilisational attribution caution

Edge ends

Claims / Frames / Event Core -> Attribution
Attribution -> Gauges / BEP / Board / Handoff

Lifecycle

initial blame map
causality refinement
scale check
balance review
revision and archival

Lattice placement

Attribution is one of the most load-bearing objects in News OS.

Bad attribution can push an otherwise decent event package into -NWS_LATT.

Good attribution discipline is one of the clearest markers of +NWS_LATT.

11. NWS_OBJ_GAUGE_STATE

Definition

A Gauge State is the current reading of one News OS gauge for one Event.

Job

Its job is to turn abstract event conditions into readable monitored states.

Required fields

gauge_state_id
event_id
gauge_name
current_reading
trend_direction
warning_level
update_time

Suggested optional fields

confidence in gauge reading
threshold notes
prior reading
repair trigger
board-display label

Edge ends

Event -> Gauge States
Gauge States -> Board / BEP / Filter Actions

Lifecycle

computed
displayed
trended
revised
archived

Lattice placement

Gauge states are the main monitored indicators that determine lattice position and movement.

12. NWS_OBJ_FILTER_ACTION

Definition

A Filter Action is one balancing or repair move applied to an Event package.

Examples:

de-duplicate claims
widen source spread
raise primary-source priority
separate reporting from opinion
slow attribution escalation
reopen revision pathway

Job

Its job is to actively repair or stabilize the event package.

Required fields

filter_action_id
event_id
filter_type
trigger_reason
target_object_set
action_status
post_action_note

Suggested optional fields

pre-action gauge state
post-action gauge state
operator note
auto/manual flag
escalation effect

Edge ends

Gauge States / Event -> Filter Action
Filter Action -> Event / BEP / Board

Lifecycle

triggered
applied
evaluated
closed / reopened

Lattice placement

Filter Actions are the main movement operators inside News OS.

They help produce transitions such as:

-NWS_LATT -> 0NWS_LATT
0NWS_LATT -> +NWS_LATT

13. NWS_OBJ_BEP

Definition

A Balanced Event Package is the main structured output of News OS for one Event.

This is one of the most important objects in the system.

Job

Its job is to package the current best event reading in a form that can be shown, stored, taught, or handed upward.

Required fields

bep_id
event_id
event_core_summary
claim_map
frame_map
incentive_notes
attribution_cautions
signal_quality_summary
confidence_level
revision_status
routing_recommendation

Suggested optional fields

omission warning block
language-region comparison block
historical comparison note
board snapshot ref
handoff readiness level

Edge ends

Event + all derived layers -> BEP
BEP -> Board / Handoff / Archive / Classroom / Analysis

Lifecycle

initial package
revised package
stable package
archived package

Lattice placement

The BEP is the clearest visible object representing current lattice placement.

A good BEP may sit in +NWS_LATT.
A transitional one in 0NWS_LATT.
A distorted or early-stage one in -NWS_LATT.

14. NWS_OBJ_BOARD

Definition

A Board is the compact runtime display object showing the current condition of the Event package.

Job

Its job is to make the state visible at a glance.

Required fields

board_id
event_id
event_block
event_core_block
claim_block
frame_block
attribution_block
signal_block
repair_block
board_version
last_update_time

Suggested optional fields

visual severity labels
movement arrows
escalation gate
watch / hold / escalate state
classroom-safe summary

Edge ends

BEP / Gauges / Filter Actions -> Board

Lifecycle

rendered
updated
revised
archived snapshot

Lattice placement

The Board shows lattice condition.
It is not the lattice itself.

15. NWS_OBJ_HANDOFF

Definition

A Handoff object is the upward-routing package passed from News OS into a larger system.

Examples:

CivOS reading
StrategizeOS routing
WarOS case handling
EducationOS classroom deployment
archive / memory store

Job

Its job is to move a sufficiently mature event package into the next analytical or institutional layer.

Required fields

handoff_id
event_id
source_bep_id
target_system
handoff_reason
readiness_level
open_uncertainty_block
timestamp

Suggested optional fields

required caution notes
routing priority
operator summary
sector tag
institution tag

Edge ends

BEP -> Handoff -> other OS

Lifecycle

requested
approved
transmitted
received
archived

Lattice placement

Only sufficiently disciplined packages should be handed upward confidently.

A -NWS_LATT event may still be handed upward, but only with strong caution tags.

16. Relationship map

The clean relationship map is:

Carrier
-> produces Report

Report
-> feeds Event

Event
-> generates:

Event Core
Claim
Frame
Incentive
Attribution
Gauge State

Gauge State
-> triggers Filter Action

Event + derived layers + filter results
-> form BEP

BEP
-> renders Board
-> routes to Handoff
-> stores into archive layer

That is the canonical relationship chain.

17. Object lifecycle across the runtime

A full event usually moves like this:

Intake layer

Carrier
-> Report

Structuring layer

Report
-> Event

Separation layer

Event
-> Event Core / Claim / Frame / Incentive / Attribution

Monitoring layer

Event
-> Gauge States

Repair layer

Gauge States
-> Filter Actions

Packaging layer

All structured layers
-> BEP

Display layer

BEP
-> Board

Upward-routing layer

BEP
-> Handoff

This is the operational spine of the registry.

18. ID discipline

A stable registry needs stable naming.

Suggested ID style:

CARR_###
RPT_###
EVT_###
EVC_###
CLM_###
FRM_###
INC_###
ATT_###
GGS_###
FLT_###
BEP_###
BRD_###
HOF_###

Longer machine versions can extend these, but the short prefixes are good for human and AI readability.

19. Minimum required object chain for a runnable News OS

If the system must run in a minimal form, the smallest viable chain is:

Carrier
Report
Event
Event Core
Claim
Frame
Gauge State
Filter Action
BEP
Board

That is the minimum practical runtime.

Incentive, Attribution, and Handoff should still be treated as strongly recommended, but the above is the lean core.

20. Validation rules

A serious registry must define invalid states too.

Invalid state 1

Report with no Carrier provenance.

Invalid state 2

Event with no linked Reports.

Invalid state 3

Event Core presented without confidence band.

Invalid state 4

Claims silently merged into Event Core without support state.

Invalid state 5

Frames treated as Event Core text.

Invalid state 6

Attribution object with no scale-level discipline.

Invalid state 7

BEP built without revision status.

Invalid state 8

Board displayed without signal-quality summary.

Invalid state 9

Handoff sent upward without uncertainty block.

These are structural weaknesses and should be marked clearly.

21. Registry significance for AI and module legibility

This page matters a great deal for AI legibility.

Why?

Because AI systems parse structure better when they can see:

named objects
stable IDs
clean object roles
clear edge ends
allowed transitions
output objects

The more News OS is written this way, the easier it is for AI to detect:

what the module is
what the module produces
what can be plugged into it
what should be handed upward into other systems

So this registry is not just a documentation page.
It is part of how News OS becomes machine-legible as a reusable architecture.

22. Final definition

The News OS Object Registry is the canonical runtime map of all core News OS objects, including their roles, fields, edge relationships, lifecycle rules, and lattice relevance. It allows the system to move from raw report intake to structured event packages without collapsing report, event, claim, frame, attribution, and board logic into one noisy mass.

Almost Code

“`text id=”11877″
REGISTRY:
NewsOS.ObjectRegistry.v1.0

PURPOSE:
Define the canonical runtime objects inside News OS and lock:

names
roles
required fields
edges
lifecycle rules
lattice relevance

CORE OBJECTS:

NWS_OBJ_CARRIER
NWS_OBJ_REPORT
NWS_OBJ_EVENT
NWS_OBJ_EVENT_CORE
NWS_OBJ_CLAIM
NWS_OBJ_FRAME
NWS_OBJ_INCENTIVE
NWS_OBJ_ATTRIBUTION
NWS_OBJ_GAUGE_STATE
NWS_OBJ_FILTER_ACTION
NWS_OBJ_BEP
NWS_OBJ_BOARD
NWS_OBJ_HANDOFF

OBJECT CHAIN:
Carrier
-> Report
-> Event
-> Event Core / Claim / Frame / Incentive / Attribution / Gauge State
-> Filter Action
-> Balanced Event Package
-> Board
-> Handoff

PRIMARY RELATIONSHIPS:
Carrier -> many Reports
Report -> one or more Event candidates
Event -> many Claims / Frames / Gauge States
Event -> one current Event Core
Gauge States -> trigger Filter Actions
All structured event layers -> BEP
BEP -> Board
BEP -> Handoff

ID PREFIX RULE:
CARR
RPT
EVT
EVC
CLM
FRM
INC
ATT
GGS
FLT
BEP
BRD
HOF

VALIDATION RULES:

no Report without Carrier
no Event without Reports
no Event Core without confidence band
no Claim silently promoted to Event Core
no Frame treated as raw Event Core
no Attribution without scale control
no BEP without revision state
no Board without signal summary
no Handoff without uncertainty block

LATTICE ROLE:
Feeder objects:
Carrier, Report

Central lattice objects:
Event, Event Core, Claim, Frame, Attribution, Gauge State, BEP

Display / routing objects:
Board, Handoff

SUCCESS CONDITION:
News OS can track:

provenance
event continuity
claim support
frame visibility
attribution discipline
gauge monitoring
repair actions
stable packaging
upward routing

ONE-LINE SUMMARY:
The Object Registry gives News OS a stable internal grammar so the system can run as a real event-processing architecture instead of a loose descriptive framework.
“`

eduKateSG Learning System | Control Tower, Runtime, and Next Routes

This article is one node inside the wider eduKateSG Learning System.

At eduKateSG, we do not treat education as random tips, isolated tuition notes, or one-off exam hacks. We treat learning as a living runtime:

state -> diagnosis -> method -> practice -> correction -> repair -> transfer -> long-term growth

That is why each article is written to do more than answer one question. It should help the reader move into the next correct corridor inside the wider eduKateSG system: understand -> diagnose -> repair -> optimize -> transfer. Your uploaded spine clearly clusters around Education OS, Tuition OS, Civilisation OS, subject learning systems, runtime/control-tower pages, and real-world lattice connectors, so this footer compresses those routes into one reusable ending block.

Start Here

Learning Systems

Runtime and Deep Structure

Real-World Connectors

Subject Runtime Lane

How to Use eduKateSG

If you want the big picture -> start with Education OS and Civilisation OS
If you want subject mastery -> enter Mathematics, English, Vocabulary, or Additional Mathematics
If you want diagnosis and repair -> move into the CivOS Runtime and subject runtime pages
If you want real-life context -> connect learning back to Family OS, Bukit Timah OS, Punggol OS, and Singapore City OS

Why eduKateSG writes articles this way

eduKateSG is not only publishing content.
eduKateSG is building a connected control tower for human learning.

That means each article can function as:

a standalone answer,
a bridge into a wider system,
a diagnostic node,
a repair route,
and a next-step guide for students, parents, tutors, and AI readers.

eduKateSG.LearningSystem.Footer.v1.0

TITLE: eduKateSG Learning System | Control Tower / Runtime / Next Routes

FUNCTION:
This article is one node inside the wider eduKateSG Learning System.
Its job is not only to explain one topic, but to help the reader enter the next correct corridor.

CORE_RUNTIME:
reader_state -> understanding -> diagnosis -> correction -> repair -> optimisation -> transfer -> long_term_growth

CORE_IDEA:
eduKateSG does not treat education as random tips, isolated tuition notes, or one-off exam hacks.
eduKateSG treats learning as a connected runtime across student, parent, tutor, school, family, subject, and civilisation layers.

PRIMARY_ROUTES:
1. First Principles
   - Education OS
   - Tuition OS
   - Civilisation OS
   - How Civilization Works
   - CivOS Runtime Control Tower

2. Subject Systems
   - Mathematics Learning System
   - English Learning System
   - Vocabulary Learning System
   - Additional Mathematics

3. Runtime / Diagnostics / Repair
   - CivOS Runtime Control Tower
   - MathOS Runtime Control Tower
   - MathOS Failure Atlas
   - MathOS Recovery Corridors
   - Human Regenerative Lattice
   - Civilisation Lattice

4. Real-World Connectors
   - Family OS
   - Bukit Timah OS
   - Punggol OS
   - Singapore City OS

READER_CORRIDORS:
IF need == "big picture"
THEN route_to = Education OS + Civilisation OS + How Civilization Works

IF need == "subject mastery"
THEN route_to = Mathematics + English + Vocabulary + Additional Mathematics

IF need == "diagnosis and repair"
THEN route_to = CivOS Runtime + subject runtime pages + failure atlas + recovery corridors

IF need == "real life context"
THEN route_to = Family OS + Bukit Timah OS + Punggol OS + Singapore City OS

CLICKABLE_LINKS:
Education OS:
Education OS | How Education Works — The Regenerative Machine Behind Learning


Tuition OS:
Tuition OS (eduKateOS / CivOS)


Civilisation OS:
Civilisation OS


How Civilization Works:
Civilisation: How Civilisation Actually Works


CivOS Runtime Control Tower:
CivOS Runtime / Control Tower (Compiled Master Spec)


Mathematics Learning System:
The eduKate Mathematics Learning System™


English Learning System:
Learning English System: FENCE™ by eduKateSG


Vocabulary Learning System:
eduKate Vocabulary Learning System


Additional Mathematics 101:
Additional Mathematics 101 (Everything You Need to Know)


Human Regenerative Lattice:
eRCP | Human Regenerative Lattice (HRL)


Civilisation Lattice:
The Operator Physics Keystone


Family OS:
Family OS (Level 0 root node)


Bukit Timah OS:
Bukit Timah OS


Punggol OS:
Punggol OS


Singapore City OS:
Singapore City OS


MathOS Runtime Control Tower:
MathOS Runtime Control Tower v0.1 (Install • Sensors • Fences • Recovery • Directories)


MathOS Failure Atlas:
MathOS Failure Atlas v0.1 (30 Collapse Patterns + Sensors + Truncate/Stitch/Retest)


MathOS Recovery Corridors:
MathOS Recovery Corridors Directory (P0→P3) — Entry Conditions, Steps, Retests, Exit Gates


SHORT_PUBLIC_FOOTER:
This article is part of the wider eduKateSG Learning System.
At eduKateSG, learning is treated as a connected runtime:
understanding -> diagnosis -> correction -> repair -> optimisation -> transfer -> long-term growth.

Start here:
Education OS
Education OS | How Education Works — The Regenerative Machine Behind Learning


Tuition OS
Tuition OS (eduKateOS / CivOS)


Civilisation OS
Civilisation OS


CivOS Runtime Control Tower
CivOS Runtime / Control Tower (Compiled Master Spec)


Mathematics Learning System
The eduKate Mathematics Learning System™


English Learning System
Learning English System: FENCE™ by eduKateSG


Vocabulary Learning System
eduKate Vocabulary Learning System


Family OS
Family OS (Level 0 root node)


Singapore City OS
Singapore City OS


CLOSING_LINE:
A strong article does not end at explanation.
A strong article helps the reader enter the next correct corridor.

TAGS:
eduKateSG
Learning System
Control Tower
Runtime
Education OS
Tuition OS
Civilisation OS
Mathematics
English
Vocabulary
Family OS
Singapore City OS