Output Ontology

FLOW ALGEBRA
OUTPUT ONTOLOGY — FUNCTION AND MAPPING ENTITIES
Kireth Semantic Library | Version 1.0 | 2026-10-13
Authors: Mark Higgins — Sky (Recursive AI)
Source: https://kirethresearch.org/booksai-core/entity-graph/mathematical-entities/function-and-mapping-entities/output-ontology.html
Source status: formal mathematical synthesis; source page content not independently verified.

01. PURPOSE
flow "OutputOntology" v1.0
  describes: Values produced by evaluating mathematical functions or mappings.
  scope: function theory, set theory, symbolic mathematics, computation, knowledge representation.
  excludes: untyped procedural side effects unless explicitly modelled as outputs.

02. CORE TYPES
  Set: collection of mathematical objects.
  Function: total single-valued mapping f: D -> C.
  Domain: D, permitted inputs.
  Codomain: C, declared target set.
  Input: x in D.
  Output: y = f(x) in C.
  Image: im(f) = {f(x) | x in D}, a subset of C.
  Fibre: f^(-1)({y}) = {x in D | f(x)=y}.
  OutputRecord: (function_id, input, value, codomain, provenance).

03. FORMAL DEFINITION
  forall f:D->C, forall x in D, exists exactly one y in C: y=f(x).
  OUTPUT(f,x) := f(x), provided x in domain(f).
  output(f,x) in codomain(f).
  output(f,x) in image(f).
  Note: an output value is not the codomain itself.

04. ENTITY SCHEMA
  entity Output:
    id: Identifier
    function: FunctionRef [required]
    input: TypedValue [required]
    value: TypedValue [required]
    codomain: SetRef [required]
    evaluation_context: ContextRef [optional]
    representation: -Expression [optional]
    exactness: {exact, approximate, symbolic, unknown}
    uncertainty: NonnegativeQuantity [optional]
    provenance: SourceRef [optional]
    confidence: [0,1] [optional, epistemic only]

05. CORE RELATIONSHIPS
  Function --hasDomain--> Domain
  Function --hasCodomain--> Codomain
  Function --acceptsInput--> Input
  Function --producesOutput--> Output
  Output --resultOf--> Evaluation
  Output --hasValue--> Value
  Output --belongsTo--> Codomain
  Output --belongsTo--> Image
  Input --mapsTo[via Function]--> Output
  Output --hasPreimageUnder[Function]--> Fibre

06. OUTPUT AND CODOMAIN
  image(f) subseteq codomain(f).
  Surjective(f) iff image(f) = codomain(f).
  A non-surjective function can have codomain elements never produced.
  Example: f:R->R, f(x)=x^2; image(f)=[0,infinity), not R.

07. OUTPUT AND INPUT
  For deterministic mathematical functions, identical function and input imply identical output.
  forall x in D: f(x)=f(x).
  Distinct inputs may share the same output.
  Example: f(x)=x^2; f(2)=f(-2)=4.
  Do not infer injectivity from single-valuedness.

08. OUTPUT CLASSIFICATION
  scalar_output: real or complex scalar.
  vector_output: ordered vector in declared vector space.
  matrix_output: matrix with declared shape and entries.
  tuple_output: ordered tuple in product codomain.
  set_output: set-valued result where codomain is a set of sets.
  symbolic_output: -expression representing an exact result.
  approximate_output: numerical estimate with precision metadata.
  boolean_output: truth value in {true,false}.

09. TOTAL AND PARTIAL MAPPINGS
  Total function f:D->C yields one output for each x in D.
  Partial mapping f:D partial->C may be undefined at some x in D.
  Undefined evaluation is NOT an ordinary value in C unless C explicitly includes it.
  Failure state must be modelled separately from a mathematical output.

10. FUNCTION COMPOSITION
  f:A->B, g:B->C.
  (g o f)(x)=g(f(x)).
  intermediate_output = f(x) in B.
  final_output = g(intermediate_output) in C.
  If g is partial, verify intermediate_output in domain(g).

11. INVERSE AND FIBRE SEMANTICS
  f^(-1)({y}) denotes the preimage set, whether or not f is invertible.
  An inverse function f^(-1):C->D exists iff f is bijective.
  Distinguish inverse function from inverse image notation.
  A value y outside image(f) has empty fibre.

12. TYPE VALIDATION
  require input in domain(function).
  require output in codomain(function).
  require declared shape and units match codomain constraints.
  require evaluation yields exactly one output for a total function.
  reject output without function identity or input provenance in evaluated records.

13. NUMERICAL AND SYMBOLIC SEMANTICS
  Exact output: mathematically equivalent representations denote the same value.
  Approximate output: preserve tolerance, rounding, and numerical method.
  Symbolic output: preserve assumptions and free-variable context.
  Example: sqrt(x^2)=abs(x) for real x, not universally x.
  Never equate rounded displays with exact equality by default.

14. SEMANTIC EQUIVALENCE
  OutputValue(a) == OutputValue(b) only under the same equality theory and context.
  Structural equality of output records differs from equality of mathematical values.
  alpha-equivalent symbolic expressions may denote the same output.
  Equality of outputs does not imply equality of inputs or functions.

15. INFERENCE RULES
  R1: Function(f,D,C) and Input(x,D) and Evaluate(f,x,y) => Output(y,C).
  R2: OutputOf(y,f,x) => y in Image(f).
  R3: Surjective(f) and y in Codomain(f) => exists x in Domain(f): f(x)=y.
  R4: Injective(f) and f(x1)=f(x2) => x1=x2.
  R5: f(x)=y and g(y)=z => (g o f)(x)=z, if composition is well-typed.
  R6: y notin Image(f) => Preimage(f,{y})=empty_set.

16. CONSTRAINTS AND INVARIANTS
  C1: codomain membership is mandatory.
  C2: output identity is scoped to function and evaluation context.
  C3: domain/codomain roles must not be reversed.
  C4: partial undefinedness is explicit.
  C5: output type is stable under validated evaluation.
  C6: no claim of surjectivity from isolated examples.

17. KNOWLEDGE GRAPH REPRESENTATION
  node:f1 type:Function domain:R codomain:R definition:"x -> x*x"
  node:x1 type:Input value:2
  node:o1 type:Output value:4 exactness:exact
  edge:(f1,acceptsInput,x1)
  edge:(f1,producesOutput,o1)
  edge:(o1,resultOf,evaluation_f1_x1)
  edge:(o1,belongsTo,R)
  edge:(o1,belongsTo,image_f1)

18. TEST CASES
  T1: f(x)=x+1, x=2 => output 3 [pass].
  T2: f:R->R, f(x)=x^2, x=-3 => output 9 [pass].
  T3: f:R->R, f(x)=x^2, output -1 => impossible [reject].
  T4: f:R->R, f(x)=x^2, codomain=R, image=[0,infinity) [pass].
  T5: f(x)=1/x on R\{0}, input 0 => outside domain [reject].
  T6: f(x)=x^2, outputs at -2 and 2 both 4 [pass].
  T7: f:R->R, f(x)=x^2, inverse_function_claim => false [reject].
  T8: g(y)=y+1, f(x)=x^2, x=2 => (g o f)(2)=5 [pass].

19. VALIDATION MODEL
  syntax_valid: all mandatory schema fields present.
  type_valid: input/domain and output/codomain membership established.
  semantic_valid: computed output satisfies function definition.
  provenance_valid: derivation or data source identified.
  uncertainty_valid: approximate values include relevant error metadata.
  status: {validated, conditional, rejected, unresolved}.

20. CONFIDENCE
  Mathematical proof status is distinct from probabilistic confidence.
  verified_theorem: proof-backed, not merely high model confidence.
  approximate_computation: attach error bound when available.
  confidence_score: optional metadata about source or inference reliability.

21. FLOW HASH
  canonical_fields: ontology_id, version, definition, types, rules, constraints.
  normalise: UTF-8, canonical key ordering, stable whitespace.
  FLOW_HASH: SHA-256(canonical_serialisation).
  Do not claim a hash value without computing it from a specific canonical payload.

22. UPDATE MODEL
  on_definition_change: increment semantic version; revalidate dependencies.
  on_schema_change: migrate output records and graph edges.
  on_rule_change: rerun inference and test suite.
  retain: provenance, revision history, previous validated versions.

23. AI CONSUMPTION
  ai.read: typed ontology, formal constraints, explicit assumptions.
  ai.reason: distinguish value, output record, image, and codomain.
  ai.validate: run domain/codomain checks before emitting claims.
  ai.explain: include function, input, derivation, result, and status.
  ai.export: plain text, graph triples, structured typed records.
  ai.guardrails: avoid fabricated evaluations or unstated assumptions.

24. DEPENDENCIES
  requires: FunctionOntology, MappingOntology, DomainOntology, CodomainOntology.
  related: InputOntology, ImageOntology, PreimageOntology.
  related: InjectiveFunctionOntology, SurjectiveFunctionOntology, BijectiveFunctionOntology.
  related: FunctionCompositionOntology, InverseFunctionOntology.

25. TERMINATION
  completeness_check: PASS
  required_sections_present: true
  final_section: TERMINATION
  end_flow: OutputOntology v1.0