Skip to content

GOLNS

GOLNS Properties

Property 1: Immutability, Singularity, and Closure

GOLNS (Guided Operational Language and Naming System) is a single, fixed, non-extensible operational language system. Its terms and definitions do not change. No new GOLNS terms may be added. A usage either matches the applicable GOLNS definition or it does not belong to GOLNS.

Property 2: Optional Participation

  • Use of GOLNS is never required.

  • Any actor may choose to use GOLNS terms, either partially or fully, without penalty or consequence within the system.

Property 3: Non-Enforcement

GOLNS does not enforce behavior, process, or adoption, and does not prescribe actions, restrict choices, or require conformance to any convention or methodology. It does not replace or invalidate non-GOLNS definitions.

Property 4: The Single Requirement Property

  • GOLNS has exactly one requirement: GOLNS = GOLNS.

  • A usage presented as GOLNS must match the applicable GOLNS definition.

  • This requirement is classificatory and does not prescribe behavior or enforce compliance.

  • All other claims of conflict, incompatibility, or contradiction are external to GOLNS.

Property 5: Optional Reference

  • When a GOLNS definition is used, it is not required to state that it is a GOLNS definition.

  • Any such statement is a communicative aid only and has no effect on whether the usage matches the applicable GOLNS definition.

Property 6: Membership

  • A usage belongs to GOLNS when it matches the applicable GOLNS definition. Membership is binary: a usage either belongs to GOLNS or it does not. There are no partial, approximate, or graded levels of membership.

  • Presentation as GOLNS does not determine membership. A usage may match the applicable GOLNS definition without being presented as GOLNS.

  • A usage does not satisfy the Single Requirement when it is presented as GOLNS and does not match the applicable GOLNS definition.

  • Applicability is constrained by the GOLNS term and its associated definitions. If ambiguity arises in application, it may be clarified through interpretation examples without modifying GOLNS.

  • GOLNS defines classification conditions. Determination of classification in ambiguous cases may require interpretation, which does not modify GOLNS.

  • When a term has multiple definitions, applicability determines which definition is used for classification.

Property 7: Non-Universality

  • GOLNS is not required to describe all cases.

  • If a situation does not match the applicable GOLNS definition, it remains outside GOLNS.

Property 8: The System Identity Property

  • GOLNS exists as a single, complete, and permanent system.

  • If any term, definition, or property differs, it is not GOLNS.

Property 9: Term and Definition Relationship Flexibility

  • The GOLNS Terminology document is the single authoritative source of GOLNS definitions, and all other representations are references to it.

  • A GOLNS term may have more than one definition within GOLNS, and multiple terms may share or be grouped within a single definitional unit.

  • Multiple terms may share the same definition when no distinction between them is relevant within GOLNS.

  • Each definition of a GOLNS term must remain exactly as defined within GOLNS.

  • Supplementary material such as notes, examples, or explanations may be included as part of the definition itself. Material outside the GOLNS Terminology document does not constitute part of a GOLNS definition.

  • Notes do not constitute a separate basis for classification beyond the definition in which they are included.

Property 10: Interpretation Expansion

  • Interpretation examples do not modify, extend, or override GOLNS definitions or properties.

  • Interpretation examples should not be confused with the properties of GOLNS, nor the terminology of GOLNS.

GOLNS Terminology

Terminology Interpretation and Meaning Definitions

1. Conflated

Conflated describes terms or concepts that are treated as the same when they are distinct.

Related describes terms or concepts that are connected in a relevant way without being the same.

Related not Conflated describes a condition in which a point is mistaken for conflation when it is actually being presented because it is strongly related to the term or meaning the audience expected.

4. Interpretative Drift

Interpretative Drift is a change in meaning over time due to interpretation rather than definition.

5. Documentation Drift

Documentation Drift is the condition in which documentation becomes outdated or no longer accurately reflects the current state or behavior of the system it describes.

6. Distinction Testing

Distinction Testing is the process of evaluating whether distinctions represent differences by mapping them against defining properties.

Example: The table below shows an implementation of distinction testing.

📝 NOTE: Distinctions and properties may be derived from a subjective interpretation of abstract or non-measurable concepts.

The example constructs a table in which: - rows represent the terms being compared - columns represent defining properties - cells indicate presence or absence using marks such as X or -

Term Is Sweet Is Crunchy Is Citrus Is Red Is Delicious
Apple X X - X -
Orange X - X - X
Carrot - X - - X

7. Expectation Gap

An Expectation Gap is the difference between intended meaning and interpreted meaning that results in unmet expectations.

8. False Constraint

9. Pedantic Interference

10. Artificial Sequencing

False Constraint, Pedantic Interference, and Artificial Sequencing are forms of imposition of structure, distinction, or order that is not required by its intended usage.

11. Buzzwords

Buzzwords are words or phrases that use salesy language or popular trends to generate appeal or impression rather than convey precise or technical meaning.

12. Golden Example

  • 12.1 A Golden Example is a representative example used as a standard or reference for correct understanding or behavior.

  • 12.2 A Golden Example is a structured interpretation example used to demonstrate correct application of GOLNS definitions and properties. If a golden example reveals a conflict within GOLNS, the system is inconsistent.

13. Knowns and Unknowns

Knowns and Unknowns are classifications of knowledge based on what is known and what is not known, including known knowns, known unknowns, and unknown unknowns.

14. Hype

Hype is exaggerated or promotional language used to generate excitement or attention, often beyond what is supported by substance or evidence.

15. Interpretive Variability

Interpretive Variability is the condition where different audiences interpret the same term, definition, or communication differently due to differences in background, context, or assumptions, resulting in inconsistent understanding. This condition is not eliminated by exhaustive or archetypal definitions.

Core Definitions

16. Not Automatable

17. Not Fully Automatable

Not Automatable or Not Fully Automatable describes a condition in which a process or aspect cannot be fully performed through automation and requires a continuous feedback loop to maintain agreement between intent and its interpretation.

18. Dependencies

Dependencies are conditions in which one thing requires another.

19. Single Source of Truth (SSoT)

20. DRY (Don't Repeat Yourself)

  • Single Source of Truth (SSoT) and DRY (Don't Repeat Yourself) describe a pattern in which information or logic is centralized to reduce duplication and maintain consistency.
  • A Single Source of Truth is a source whose data or information is treated as correct.
  • Don't Repeat Yourself is a principle in which duplication of logic or data is avoided.

21. Context

22. Scope

Context and Scope refer to the set of conditions, boundaries, and relevant elements within which something exists or is considered.

23. Bounded Context

A Bounded Context is a context with explicit and defined boundaries.

24. Level of Detail

Level of Detail is the degree of specificity or granularity in the description of something.

25. Immutable History

26. Open/Closed Principle (OCP)

  • Immutable History and Open/Closed Principle (OCP) describe a pattern in which change is applied through extension rather than modification of existing elements.

  • Immutable History is a sequence of recorded changes that are not modified after recording, where new changes are added as additional entries rather than edits to existing ones.

  • The Open/Closed Principle is a design principle in which a system is open for extension but closed for modification.

27. Single Point of Failure

A Single Point of Failure is a component whose failure causes the entire system to fail.

28. Fail Loud Fail Fast

Fail Loud Fail Fast is an approach in which failures are made immediately visible and occur as early as possible.

29. High Cohesion, Loose Coupling (HCLC)

  • High Cohesion and Loose Coupling describe a pattern in which systems are organized with strong internal focus within units and minimal dependency between units.

  • High Cohesion is a property of a system in which elements within a unit are closely related and focused on a single purpose.

  • Loose Coupling is a property of a system in which units have minimal dependencies on each other.

30. Scalability

31. Maintainability

32. Testability

33. Reliability

34. Availability

35. Securability

36. Recoverability

37. Privacy

38. User Confidence

39. Portability

40. (-ability terms in general)

  • Scalability, Maintainability, Testability, Reliability, Availability, Securability, Recoverability, Privacy, User Confidence, and Portability are examples of -ability terms. Ability terms describe system qualities expressed as capabilities or characteristics of a system, commonly denoted by the suffix "-ability."

41. Edge Case

42. Fringe Case

  • An Edge Case is a condition that occurs at the boundary of expected input or behavior.
  • A Fringe Case is a condition that occurs rarely or outside typical usage.

43. Black Box

44. White Box

  • A Black Box is a system or component that is understood or evaluated based only on its inputs and outputs without knowledge of its internal structure.

  • A White Box is a system or component that is understood or evaluated with knowledge of its internal structure and behavior.

45. GOLNS Consistency Check

A GOLNS Consistency Check is an evaluation of the GOLNS system to ensure that all properties, term definitions, and interpretation examples are internally consistent, and non-conflicting.

Development and Testing Definitions

46. Development Pipeline

The Development Pipeline is a GOLNS-defined ordered transformation of a goal or problem statement into source code through pseudocode, visual models, and a How to Run Document. The development pipeline produces a git feature branch ready for testing by continuous integration tests and for merging into a main branch.

47. Goal

48. Problem Statement

Goal and Problem Statement are a description of a desired result in terms of the condition it addresses, authored by the programmer and informed by stakeholder feedback, used to establish shared understanding through early agreement.

49. Feature Branch

A Feature Branch is a branch in version control used to develop a specific feature or change in isolation from the main codebase. It allows work to proceed independently without affecting the stable branch until the feature is complete, tested, and ready to be merged.

50. Pseudocode

Pseudocode is a structured, language-agnostic representation of logic or processes that resembles executable code but is not bound to the syntax or semantics of a specific programming language.

51. Flowchart

52. UML

53. ERD

54. Dataflow

55. Decision Tree

Flowchart, UML, ERD, Dataflow, and Decision Tree are visual models used to represent structure, relationships, logic, or movement in a form intended to support shared understanding.

56. How to Run Document

A How to Run Document is a description of the conditions and actions required to execute something as intended, including explicit tasks, explicit steps associated with those tasks, and support for feedback and pass or fail checks on those steps.

57. Source Code

Source Code is a human-readable set of instructions that defines computer executable behavior.

58. Non-Pipeline Activity

A Non-Pipeline Activity is any activity that is not part of the development pipeline.

Examples include validation testing, acceptance testing, continuous integration, deployment, monitoring, operations, project management, documentation, and methodology-related activities.

59. Regression

Regression is a change that results in a previous or less advanced state, such as when a software change causes previously correct behavior to become incorrect.

60. Test Driven Development (TDD)

Test Driven Development is a development approach in which tests define expected behavior and drive implementation, typically performed by writing a failing test, making changes until the test passes, and then refactoring the implementation.

61. Continuous Integration (CI)

Continuous Integration is a development approach in which changes are automatically built and tested to validate system integration.

62. Test Case

A Test Case is a defined condition and expected outcome used to guide and evaluate the development of executable behavior.

63. CI Test

A CI test is a test used to validate integrated software behavior and detect regression.

64. Automated Test

An Automated Test is a test that is executed automatically by software to verify that a system behaves as expected.

65. User

66. Software User

A User is an actor that interacts with software.

67. User Type

68. User Role

  • A User Type is a classification assigned to a user as a single type.
  • A User Role is a classification assigned to a user, where a user may have one or more roles.

69. Acceptance Criteria

70. Acceptance Test

An Acceptance Test is a test used to determine whether a feature, task, or system meets defined criteria for acceptance. It checks that the implemented behavior matches the expected outcomes and conditions. Acceptance tests are typically derived from acceptance criteria and are written to be clear, observable, and verifiable so that different parties can consistently determine whether the criteria have been met.

71. Artifacts Repo

72. Source Repo

  • An Artifacts Repo is a repository used to store supporting artifacts related to software, such as supporting documentation or project artifacts.

  • A Source Repo is a repository used to store source code for software.

73. Customer Request

A Customer Request is a request made by a customer for new software or a change to existing software.

74. Known Issue

75. Unknown Issue

A Known Issue is a condition that is recognized as a deviation from intended behavior. An Unknown Issue is a condition that exists as a deviation from intended behavior but is not recognized.

Project Management Definitions

76. Project

A Project is a bounded undertaking directed toward an intended result.

77. Task

A Task is a unit of intended work.

78. Step

A Step is a discrete action within a task.

79. Pass / Fail Check

A Pass or Fail Check is a determination of whether a step meets its expected outcome.

80. Backlog

A Backlog is a collection of tasks awaiting work.

81. Timebox

A Timebox is a fixed and limited period during which a task or activity is performed, after which the activity stops regardless of completion state.

82. Feasibility Test

A Feasibility Test is an evaluation of whether a system, solution, or implementation can operate within its intended environment. It is performed in a state where ideas, structures, and implementations are not yet fixed. Feasibility tests may be designed, changed, or discarded as understanding evolves prior to a stable release.

AI Integrity and Usage Definitions

83. Reference

A Reference is a source whose information is used as a basis for agreement.

84. Referential Compliance

Referential Compliance is alignment of information with a reference.

85. AI Assisted

AI Assisted refers to the use of artificial intelligence to support or enhance human tasks or decision-making.

86. Prompt

A Prompt is an input provided to an AI system that defines the task, context, or instructions the AI is expected to respond to.

87. Paper and Pencil Algorithm

A Paper and Pencil Algorithm is a step-by-step procedure that is designed to be executed manually by a human, without reliance on automation, where each step is explicitly defined and can be followed using basic recording or mental operations.

88. Agent

An Agent is an AI system that performs actions within a defined context to achieve an intended outcome based on a prompt, procedure, or input.

Incremental Design and Change Management

89. Evolutionary Design

Evolutionary Design is a design approach in which a system is developed through incremental changes over time, where structure and behavior are continuously refined as understanding increases, rather than being fully defined upfront.

📝 Notes:

  • Development typically begins with a simple implementation that is refined over time.

  • Changes are introduced incrementally rather than through large, upfront redesign.

  • Design evolves in response to increased understanding rather than complete initial specification.

90. Refactoring

Refactoring is the process of modifying the internal structure of a system without changing its external behavior, in order to improve clarity, maintainability, or other system qualities.

📝 Notes:

  • Refactoring is commonly performed in small, behavior-preserving steps.

  • Incremental changes may accumulate to produce significant design improvements over time.

  • A guiding principle is: “Make the change easy, then make the easy change.”

91. Incremental Integration

Incremental Integration is a development approach in which changes to a system are integrated and validated through automated processes to ensure that the system remains in a consistent and functioning state.

📝 Notes:

  • Changes are typically integrated frequently rather than accumulated.

  • Smaller changes reduce risk and simplify validation.

  • Early detection of issues is achieved through continuous validation.

  • Large, infrequent integrations increase the likelihood of instability.

92. Strangler Fig Pattern

93. Branch by Abstraction

The Strangler Fig Pattern and Branch by Abstraction describe approaches in which an existing system or implementation is replaced incrementally by introducing new functionality alongside it, allowing both to coexist while behavior is gradually redirected until the original is no longer used.

📝 Notes:

  • Replacement occurs incrementally rather than through a full system rewrite.

  • New functionality or implementations are introduced in parallel with the existing system.

  • Coexistence allows controlled transition from the original implementation to the new one.

  • System behavior is progressively shifted from the old implementation to the new one.

  • This approach reduces risk compared to large, single-step replacements.

94. Feature Toggles

Feature Toggles are a mechanism for controlling the activation of functionality within a system at runtime, allowing features to be enabled or disabled without modifying or redeploying the system.

📝 Notes:

  • Feature toggles allow incomplete or experimental functionality to exist in a system without being active.

  • Features can be enabled or disabled to control exposure and behavior.

  • This approach supports safe deployment by separating release from activation.

  • Feature toggles may be used alongside incremental replacement approaches.

95. Sacrificial Architecture

Sacrificial Architecture is a design approach in which an initial system or structure is intentionally introduced with the expectation that it will be replaced or significantly changed as understanding increases.

📝 Notes:

  • Initial implementations may prioritize speed of learning over long-term structure.

  • Systems are built with the understanding that they are not final.

  • Change is expected to occur progressively rather than through a complete upfront design.

  • Early designs may be discarded or reworked as requirements and constraints become clearer.

  • Temporary structures such as shims or intermediary components may be used within a sacrificial architecture but are not required.