Gativus Notation (GNOT)

2. Gativus Notation (GNOT)

Naming rules · Visualization of NDDI · Shapes and colors · Diagrams · Document numbering

2. 1. Purpose of GNOT

GNOT (Gativus NOTation) is a unified set of naming, visualization, and documentation rules ensuring uniformity across all documents, diagrams, and tools of the Gativus project. GNOT applies to all three books (GTOM, GNET, GATE) and all derived documents.

The necessity of the notation is determined by the project's scale: the architecture contains dozens of entities, hundreds of component types and relationships, thousands of possible configurations. Without a uniform notation, developers reading the specification will inevitably start using their own designations, leading to documentation incompatibility and implementation errors.

GNOT is not a decorative element. It is an engineering standard, analogous to standards for electrical schematics (IEEE), architectural drawings (ISO), or network diagrams (RFC). Every rule has a technical rationale.

2. 2. Naming rules

Rule 1: four characters. All abbreviations in the Gativus project contain exactly four characters. Permitted characters: Latin letters (A–Z) and digits (0–9). No exceptions.

Rationale: the four-character format ensures compactness (fits into a 32-bit word in ASCII encoding), uniformity (all terms of equal length in tables and code), and recognizability (the reader immediately identifies a four-character word as a Gativus term).

Examples of correct naming: NDDI, UNON, LOCN, OPRN, KLEN, MOTV, BLOM, KLOM, WLOM, SERN, SRNT, GATE, GNET, GNOT, APAK, AIOT, RTYP, PLEN, SYGN, NRGN, ANOD, AGMT, GLNS, POCN.

Examples of incorrect naming: REL_TYPE (more than 4 characters, contains underscore), PID (3 characters), MAP (3 characters — used only with a level suffix: MAP1, MAP3, MAP8, MAPA).

Rule 2: level suffix. Entities that exist at multiple levels are named with a base name (3 characters) + level suffix (1 character). Suffix: digit (1–9) or letter (A–D).

Missing numbers (MAP7, DOM7) are not omissions — they are absent from the architecture. MAP7 does not exist. DOM7 is OPN7 (Attention), which has no MAP of its own.

Rule 3: no compound names. Compound names with underscores, hyphens, or camelCase are not used. Each term is a single four-character word.

Examples: instead of REL_TYPE — RTYP. Instead of PAYLOAD_LEN — PLEN. Instead of SRC_ADDR — context is used (UNON in the src header field).

2. 3. Visualization of NDDI

Rule 4: polyhedron. NDDI is visualized as a polyhedron. The base shape is a cube. Each face contains components of one type.

For a cube, three faces are visible simultaneously — top, front, and right. Three visible faces are sufficient to display the main component types in most cases. When more types need to be shown, the polyhedron is rotated (other faces become visible) or a polyhedron with more faces is used.

Rule 5: face naming. A face is named by the type of components located on it: V-face, A-face, D-face, T-face, L-face, R-face, B-face, S-face, N-face, P-face, C-face, W-face, G-face.

Rule 6: grid. Components are placed on a regular rectangular grid of the face. Each grid cell can contain one component. Empty cells are allowed — they indicate the absence of a component in that position. The grid size is determined by the number of components of a given type in a specific NDDI.

Rule 7: minimal NDDI. The minimal node (D + V + A) is visualized as a cube with three visible faces: D-face (code), V-face (values), A-face (activities).

Rule 8: UNON. The UNON name is displayed on the cube (polyhedron) frame, visible from any angle. Name format in GATN:GANN (e.g., 0001:0042). Monospace font.

2. 4. Component shapes

Rule 9: unique shape. Each component type has a unique geometric shape, allowing instant identification without reading a label.

Rule 10: color is mandatory. In color printing or on-screen display, color is a mandatory identification element. In monochrome printing — only shape is used. Shapes are chosen to be distinguishable without color.

2. 5. Connector shapes

Rule 11: pin and socket. A connector is visualized as a pin (outgoing) or a socket (incoming), located on the component body and protruding beyond the face surface.

Rule 12: typing by shape. The connector type is determined by the relationship type. The shape of the pin matches the shape of the socket — but the pin is convex, the socket concave. A pin of one type physically cannot be inserted into a socket of another type — a visual expression of strong typing.

2. 6. Visualization of relationships

Rule 13: line. A relationship between two NDDI is visualized as a line (wire) connecting a pin of one node to a socket of another. The line color corresponds to the relationship type (matches the connector color).

Rule 14: directionality. The line has an arrow at the receiving end (from pin to socket). Bidirectional relationship — two parallel lines with two arrows in opposite directions.

Rule 15: thickness. Line thickness can reflect the intensity of the relationship (frequency of datagram transmission). Thin line — rare events. Thick line — high-frequency flow. If intensity information is unavailable — all lines have the same thickness.

Rule 16: delivery mode. Reliable relationship — solid line. Unreliable relationship — dashed line.

2. 7. Visualization of DOM levels

Rule 17: horizontal layers. DOM levels are visualized as horizontal layers arranged from bottom to top. Bottom layer — physical, top layer — axiological.

Rule 18: virtual levels. Social (virtual) levels (MAP4, MAP5, MAP9, MAPC, MAPD) are visualized with a dashed border — they have no single physical carrier and no OPN/TRL of their own.

Rule 19: vertical connections. Connections between levels (CNN1/CNN2/CNN3 — upward convolution, compilation — downward) are visualized as vertical arrows. Inference — arrow up. Compilation — arrow down. Learning — bidirectional arrow within the target level.

2. 8. Visualization of TRL

Rule 20: tape. TRL is visualized as a horizontal tape on which records are placed from left to right. Left end — past, right end — future. The current OPN position is marked with a vertical marker.

Rule 21: record states. TRL records are visualized differently depending on state:

2. 9. Visualization of vectors

Rule 22: arrow. Vectors (b, P, W) are visualized as arrows. The arrow color corresponds to the vector type. Thickness is proportional to magnitude (distance).

Rule 23: general and specific vector. General vector (direction without magnitude) — dashed arrow without length indication. Specific vector (with coordinates and magnitude) — solid arrow, length proportional to magnitude.

2. 10. Visualization of routing

Rule 24: G1/G2/G3 levels. The three routing levels are visualized with different line strokes of the relationship line:

Rule 25: GATE. A GATE device is visualized as a rectangle with a thick border, containing many NDDI (polyhedra). The GATN name is displayed in the rectangle header.

2. 11. Document numbering

Rule 26: SPC prefix. Documents of the Gativus project have the prefix SPC (SPeCification) and a subsystem code:

Rule 27: document number. After the prefix — a three-digit sequential number. Example: SPC-GATE-814, SPC-GNET-001.

Rule 28: diagram captions. Each diagram is captioned with: figure number, title, document number. Example: "Drawing 4: Relation over IP concept. SPC-GATE-814".

2. 12. Diagram formatting rules

Rule 29: mandatory elements of an NDDI diagram. Each NDDI diagram contains: UNON name, visible faces (at least three), components on faces (in correct shapes and colors), connectors with counter-names.

Rule 30: mandatory elements of a relationship diagram. Each relationship diagram contains: two (or more) NDDI, a line between connectors, relationship type (RTYP), directionality (arrow), delivery mode (solid or dashed).

Rule 31: mandatory elements of a group diagram. A functional group diagram contains: an NDDI with a G-component (ANOD), child NDDI, relationships between them, group boundary (dash-dotted line), inter-group relationships (if any).

Rule 32: scale. When visualizing a system of many NDDI, simplification is allowed: NDDI is displayed as a point (without faces), relationships as lines between points. Connector shapes and colors are not shown in this mode. This mode is used for overview diagrams of large networks.

2. 13. Conclusions

GNOT defines 32 rules for naming, visualization, and documentation. The rules ensure:

• Uniformity: any element of the Gativus architecture is uniquely identified by its shape, color, and four-character name.

• Strong typing: the connector shape guarantees visual incompatibility of heterogeneous relationships.

• Scalability: from a detailed diagram of a single NDDI to an overview diagram of a network of millions of nodes.

• Compatibility: the notation is applied consistently in GTOM (theory), GNET (network), and GATE (platform).

Compliance with GNOT is mandatory for all documents of the Gativus project.