@tiinex/app 0.1.1

package/src/schemas/validation/finding/tiinex.validation.finding.v1.schema.md

@@ -0,0 +1,309 @@
+# Continuity Context
+
+- Envelope Schema: [tiinex.root.v1](../../tiinex.root.v1.schema.md)
+- Parent
+  - Parent Schema: [tiinex.root.v1](../../tiinex.root.v1.schema.md)
+  - Created At: 2026-06-14 00:00:00
+  - Trace: [tiinex.root.v1.schema.md](../../tiinex.root.v1.schema.md)
+  - Origin:
+    - [relative](../../tiinex.root.v1.schema.md)
+    - [browse + git](https://github.com/Tiinex/docs/blob/78a3673444666f1145be4feca6e7eb1476a44281/.topics/.schemas/tiinex.root.v1.schema.md)
+- Current
+  - Current Schema: [tiinex.validation.finding.v1](tiinex.validation.finding.v1.schema.md)
+  - Created At: 2026-06-30 00:00:00
+  - Summary: Schema for one concrete validation observation against a bounded target using a declared method or check boundary.
+
+---
+
+# Validation Finding
+
+- Status: draft schema note
+
+## Summary
+
+Schema for one concrete validation observation against a bounded target using a declared method or check boundary.
+
+This schema is human-first. It should be readable by a person who knows the parent schema but does not know a specialized app, programming language, management tool, calendar tool, or database.
+
+## Schema Validation Contract
+
+### Validation Finding Scope
+
+Applies To
+
+- artifacts whose `Current -> Current Schema` is `tiinex.validation.finding.v1`
+
+Rules
+
+- `tiinex.validation.finding.v1` identifies artifacts whose main job is to preserve validation finding semantics.
+- A validation finding artifact should state its identity, boundary, state, related targets, and interpretation limits in human-readable form.
+- A validation finding artifact must not silently become proof, consent, authority, attendance, allocation, validation, or truth unless those claims are separately supported by the appropriate schema or method.
+- Prose outside `Schema Validation Contract` may explain the schema, but it does not add required validation rules.
+
+### Validation Finding Body
+
+Required Shape
+
+- first body heading after the continuity envelope
+- `## Validation Target` section
+- `## Validation Method` section
+- `## Observed Result` section
+- `## Finding Boundary` section
+- `## Suggested Response` section
+- `## Interpretation Limits` section
+
+Optional Sections
+
+- Related Artifacts
+- References
+
+Rules
+
+- A validation finding artifact should begin with a human-readable title.
+- Required sections should be readable without specialized tooling.
+- Required sections should be structured enough that a reader, tool, or LLM can extract boundaries without guessing.
+- Follow-up sections must not replace the declared boundary and interpretation limits.
+### Validation Target
+
+Required Fields
+
+- Target
+- Target Kind
+
+Optional Fields
+
+- Artifact
+- Payload
+- Schema
+- Method
+- Line Or Section
+
+Rules
+
+- `Validation Target` must remain human-readable and bounded.
+- `Validation Target` must state what is known, what is unknown, and what must not be inferred when those limits matter.
+- `Validation Target` may reference relation, evidence, attestation, validation, privacy, source, access, resource, party, event, project, or instrument artifacts when those artifacts own companion semantics.
+
+### Validation Method
+
+Required Fields
+
+- Method
+- Method Scope
+
+Optional Fields
+
+- Validation Method Artifact
+- Tool
+- Human Review Method
+
+Rules
+
+- `Validation Method` must remain human-readable and bounded.
+- `Validation Method` must state what is known, what is unknown, and what must not be inferred when those limits matter.
+- `Validation Method` may reference relation, evidence, attestation, validation, privacy, source, access, resource, party, event, project, or instrument artifacts when those artifacts own companion semantics.
+
+### Observed Result
+
+Required Fields
+
+- Status
+- Observation
+
+Optional Fields
+
+- Pass
+- Warning
+- Fail
+- Skipped
+- Unavailable
+- Inconclusive
+- Finding Code
+- Severity
+
+Rules
+
+- `Observed Result` must remain human-readable and bounded.
+- `Observed Result` must state what is known, what is unknown, and what must not be inferred when those limits matter.
+- `Observed Result` may reference relation, evidence, attestation, validation, privacy, source, access, resource, party, event, project, or instrument artifacts when those artifacts own companion semantics.
+
+### Finding Boundary
+
+Required Fields
+
+- What Was Checked
+- What Was Not Checked
+
+Optional Fields
+
+- Required Context
+- Known Limitation
+- False Positive Risk
+- False Negative Risk
+
+Rules
+
+- `Finding Boundary` must remain human-readable and bounded.
+- `Finding Boundary` must state what is known, what is unknown, and what must not be inferred when those limits matter.
+- `Finding Boundary` may reference relation, evidence, attestation, validation, privacy, source, access, resource, party, event, project, or instrument artifacts when those artifacts own companion semantics.
+
+### Suggested Response
+
+Required Fields
+
+- Recommended Response
+
+Optional Fields
+
+- Repair Suggestion
+- Human Review
+- Ignore Rationale
+- Follow-Up Artifact
+
+Rules
+
+- `Suggested Response` must remain human-readable and bounded.
+- `Suggested Response` must state what is known, what is unknown, and what must not be inferred when those limits matter.
+- `Suggested Response` may reference relation, evidence, attestation, validation, privacy, source, access, resource, party, event, project, or instrument artifacts when those artifacts own companion semantics.
+
+### Interpretation Limits
+
+Required Fields
+
+- Does Not Prove
+- Must Not Be Treated As
+
+Optional Fields
+
+- Trust Boundary
+- Open Questions
+
+Rules
+
+- `Interpretation Limits` must remain human-readable and bounded.
+- `Interpretation Limits` must state what is known, what is unknown, and what must not be inferred when those limits matter.
+- `Interpretation Limits` may reference relation, evidence, attestation, validation, privacy, source, access, resource, party, event, project, or instrument artifacts when those artifacts own companion semantics.
+
+### Allowed Or Common Shapes
+
+Allowed Shapes
+
+- pass
+- warning
+- fail
+- skipped
+- unavailable
+- inconclusive
+- blocked
+- needs human review
+
+Rules
+
+- Allowed shapes are guidance for common reading and grouping, not an exhaustive vocabulary.
+- Local artifacts may use another precise human-readable shape when the declared boundaries remain clear.
+
+### File Naming
+
+Allowed Shapes
+
+- `<lineage>.trace.md`
+- `<lineage>-validation-finding.trace.md`
+- `<lineage>-<validation-finding-slug>.trace.md`
+
+Rules
+
+- Artifacts should keep the lineage label first.
+- The optional slug should describe the bounded artifact role rather than a low-signal implementation detail.
+- Ordinary lineage artifacts should keep the `.trace.md` suffix stable.
+
+### Interpretation Boundaries
+
+Rules
+
+- Use `tiinex.validation.finding.v1` when the main artifact value is the declared validation finding role.
+- Do not use `tiinex.validation.finding.v1` to replace evidence, attestation, validation, consent, relation, task, decision, event, party, resource, or instrument artifacts when those schemas own the main role.
+- Parent remains direct continuity ancestry; related targets should be represented through relation or target fields unless direct continuation is being declared.
+
+## Artifact Creation Contract
+
+### Creation Fields
+
+Required Fields
+
+- Target
+- Target Kind
+- Method
+- Method Scope
+- Status
+- Observation
+- What Was Checked
+- What Was Not Checked
+- Recommended Response
+- Does Not Prove
+- Must Not Be Treated As
+
+### Creation Rules
+
+Rules
+
+- Creation tools should keep the artifact human-readable and bounded.
+- Creation tools should preserve unknown, partial, contested, private, unsafe, unavailable, or ambiguous state instead of inventing certainty.
+## Minimal Example
+
+```md
+# Continuity Footer Warning
+
+## Validation Target
+
+- Target: one trace artifact
+- Target Kind: markdown artifact
+
+## Validation Method
+
+- Method: continuity footer check
+- Method Scope: footer presence and method recognition
+
+## Observed Result
+
+- Status: warning
+- Observation: legacy method used
+
+## Finding Boundary
+
+- What Was Checked: footer method label
+- What Was Not Checked: truth, authorship, consent, or claim correctness
+
+## Suggested Response
+
+- Recommended Response: upgrade footer when tooling is ready
+
+## Interpretation Limits
+
+- Does Not Prove: artifact content is true or false
+```
+
+## Validation-Friendly Shape
+
+Keep this schema note in the exact section order already used here: `Summary`, `Schema Validation Contract`, `Artifact Creation Contract`, `Minimal Example`, `Validation-Friendly Shape`, and `Interpretation Notes`.
+
+Maintain the section headings exactly in this schema note. Free markdown inside those sections is allowed, but adding undeclared new section headings should be treated as schema drift.
+
+The body headings required for artifacts using this schema are: `## Validation Target`, `## Validation Method`, `## Observed Result`, `## Finding Boundary`, `## Suggested Response`, `## Interpretation Limits`.
+
+## Interpretation Notes
+
+- validation finding records a bounded check result
+- the method scope controls what the finding can and cannot mean
+- a finding may suggest repair but is not the repair itself
+
+---
+
+# Continuity Integrity
+
+- sha256-base64url-c14n-v1
+  - Towards: [tiinex.root.v1.schema.md](https://github.com/Tiinex/docs/blob/78a3673444666f1145be4feca6e7eb1476a44281/.topics/.schemas/tiinex.root.v1.schema.md)
+  - Value: BFWYft1v0Ue0gUoO236DGScvnixS7_MIEwO6mhJhkNw
+
+- sha256-base64url-c14n-v2
+  - Towards: self
+  - Value: SaEuCTN9eOJFDouyHzUn8i9rRnSbtj_1uXOz4w1W29Y

package/src/schemas/validation/method/tiinex.validation.method.v1.schema.md

@@ -0,0 +1,280 @@
+# Continuity Context
+
+- Envelope Schema: [tiinex.root.v1](../../tiinex.root.v1.schema.md)
+- Parent
+  - Parent Schema: [tiinex.root.v1](../../tiinex.root.v1.schema.md)
+  - Created At: 2026-06-14 00:00:00
+  - Trace: [tiinex.root.v1.schema.md](../../tiinex.root.v1.schema.md)
+  - Origin:
+    - [relative](../../tiinex.root.v1.schema.md)
+    - [browse + git](https://github.com/Tiinex/docs/blob/78a3673444666f1145be4feca6e7eb1476a44281/.topics/.schemas/tiinex.root.v1.schema.md)
+- Current
+  - Current Schema: [tiinex.validation.method.v1](tiinex.validation.method.v1.schema.md)
+  - Created At: 2026-06-26 00:00:00
+  - Summary: Schema for validation-method definitions that declare verification scope, trust boundary, and failure modes.
+
+---
+
+# Validation Method
+
+- Status: maintained schema note
+
+## Summary
+
+This schema defines validation-method artifacts that describe what a validation
+method verifies, what it does not verify, and where its trust boundary ends.
+
+It exists so Tiinex tools and readers do not collapse byte integrity, schema
+validity, signature validity, human attestation, lineage continuity, and runtime
+reproducibility into one vague word such as `verified`.
+
+## Schema Validation Contract
+
+### Validation Method Scope
+
+Applies To
+
+- artifacts whose `Current -> Current Schema` is `tiinex.validation.method.v1`
+
+Rules
+
+- `tiinex.validation.method.v1` identifies artifacts whose main job is to define the semantics and limits of a validation method.
+- A validation method artifact describes a method contract; it does not by itself prove that a particular target satisfies the method.
+- Validation method artifacts should make positive verification scope and negative scope explicit.
+- Prose outside `Schema Validation Contract` may explain the schema, but it does not add required validation rules.
+
+### Validation Method Body
+
+Required Shape
+
+- first body heading after the continuity envelope
+- `## Method Identity` section
+- `## Verification Scope` section
+- `## Trust Boundary` section
+- `## Failure Modes` section
+- `## Recommended Use` section
+
+Optional Sections
+
+- Canonicalization
+- Required Context
+- Replayability
+- Human Verifiability
+- Machine Verifiability
+- Examples
+- Related Methods
+- Not Recommended For
+
+Rules
+
+- A validation method artifact should begin with a human-readable method name.
+- `Method Identity` must identify the method and version.
+- `Verification Scope` must state both what the method verifies and what it does not verify.
+- `Trust Boundary` must state the assumptions or authority limits of the method.
+- `Failure Modes` must state known ways the method can fail, mislead, or be misapplied.
+- `Recommended Use` must state where the method is appropriate.
+
+### Method Identity
+
+Required Fields
+
+- Name
+- Version
+- Method Family
+- Canonical Identifier
+
+Optional Fields
+
+- Supersedes
+- Related Method
+
+Rules
+
+- `Name` should be stable enough for human-readable method entries and UI surfaces to reference.
+- `Canonical Identifier` should be the stable machine-readable method id used by integrity entries, validator output, and UI method labels.
+- `Version` should change when interpretation, canonicalization, trust boundary, or failure semantics change.
+- `Method Family` should identify the broad method class, such as digest, signature, schema validation, lineage traversal, human attestation, runtime reproduction, or external authority.
+
+### Verification Scope
+
+Required Fields
+
+- Verifies
+- Does Not Verify
+
+Optional Fields
+
+- Target Types
+- Required Inputs
+- Output Signal
+
+Rules
+
+- `Verifies` must describe the positive claim the method can support.
+- `Does Not Verify` must describe important claims the method does not support.
+- A method must not imply truth, authorship, intent, consent, identity, or historical provenance unless those are inside its declared verification scope.
+- UI labels should prefer method-scoped language such as `byte-integrity verified`, `schema-valid`, `lineage-continuity verified`, `human-attested`, or `runtime-reproducible` over generic `verified`.
+
+### Trust Boundary
+
+Required Fields
+
+- Trust Boundary
+- Required Context
+
+Optional Fields
+
+- Machine Verifiable
+- Human Verifiable
+- Replayable
+- Cryptographic Strength
+- Social Or Legal Strength
+
+Rules
+
+- `Trust Boundary` must state what authority, environment, secret, key, witness, runtime, or context the method depends on.
+- `Required Context` must state what a later reader or validator needs before applying the method.
+- Machine-verifiable and human-verifiable status should be explicit when known.
+- Replayability should be explicit when repeat validation is possible.
+
+### Failure Modes
+
+Required Fields
+
+- Failure Modes
+
+Optional Fields
+
+- Ambiguity Risks
+- Misuse Risks
+- Known Weaknesses
+
+Rules
+
+- A validation method should state known failure modes rather than only describing successful use.
+- Non-cryptographic validation methods should be especially explicit about weakness and context dependence.
+- Weak methods may still be useful when their boundaries are clear.
+
+### Recommended Use
+
+Required Fields
+
+- Recommended Use
+
+Optional Fields
+
+- Not Recommended For
+- Example UI Labels
+
+Rules
+
+- `Recommended Use` should state where the method is appropriate.
+- `Not Recommended For` should state common misuse cases when known.
+- `Example UI Labels` should prefer method-scoped language over generic `verified`.
+
+### File Naming
+
+Allowed Shapes
+
+- `<lineage>-<method-slug>.trace.md`
+- `<lineage>-validation-method.trace.md`
+- `<method-slug>.trace.md`
+- `<method-slug>-validation-method.trace.md`
+- `<method-slug>.validator.md`
+- `<method-slug>-validation-method.validator.md`
+
+Rules
+
+- Validation method artifacts should use a slug that identifies the method or method family.
+- Lineage-first `.trace.md` names should be used when the method artifact is part of an ordinary local trace lineage.
+- Canonical registry-like method artifacts may use a method slug without a lineage prefix when the artifact is intentionally maintained as a reusable method definition.
+- Canonical registry-like method definitions may use `.validator.md` when the artifact is intentionally maintained as a reusable validation method definition.
+- `.validator.md` files define validation method semantics; they are not executable validator implementations.
+- `.validator.md` files are not validation result artifacts.
+- Trace-lineage validation method artifacts should keep the `.trace.md` suffix stable.
+
+### Interpretation Boundaries
+
+Rules
+
+- Use `tiinex.validation.method.v1` to define method semantics, not to record one validation result.
+- A specific validation result may reference a validation method artifact but should be owned by the schema that records that result.
+- Integrity-specific methods may later be narrowed by a descendant such as `tiinex.integrity.method.v1` if needed.
+- Attestation-specific methods may later be narrowed by a descendant or companion attestation schema if needed.
+
+## Minimal Example
+
+```md
+# Continuity Context
+
+- Envelope Schema: tiinex.root.v1
+- Current
+  - Current Schema: tiinex.validation.method.v1
+  - Created At: 2026-06-26 00:00:00
+  - Summary: Method boundary for a canonical byte digest check.
+
+---
+
+# SHA-256 Canonical Byte Digest Method
+
+## Method Identity
+
+- Name: SHA-256 canonical byte digest
+- Version: 1
+- Method Family: digest
+- Canonical Identifier: sha256-base64url-c14n-v1
+
+## Verification Scope
+
+- Verifies: same canonical bytes for the declared target
+- Does Not Verify: truth, authorship, intent, consent, semantic correctness, or historical provenance
+
+## Trust Boundary
+
+- Trust Boundary: canonicalization algorithm plus digest implementation
+- Required Context: target bytes and the canonicalization rules
+- Machine Verifiable: yes
+- Human Verifiable: partial
+- Replayable: yes
+
+## Failure Modes
+
+- Failure Modes: wrong canonicalization, wrong target, truncated content, stale digest, implementation bug
+
+## Recommended Use
+
+- Recommended Use: byte-integrity checks for stable artifacts and payloads
+- Not Recommended For: proving truth or authorship
+- Example UI Labels: byte-integrity verified
+```
+
+## Validation-Friendly Shape
+
+Keep this schema note in the exact section order already used here:
+`Summary`, `Schema Validation Contract`, `Minimal Example`,
+`Validation-Friendly Shape`, and `Interpretation Notes`.
+
+Maintain the section headings exactly in this schema note. Free markdown inside
+those sections is allowed, but adding undeclared new section headings should be
+treated as schema drift.
+
+## Interpretation Notes
+
+- validation methods define what a method can and cannot prove
+- method-scoped verification language should replace generic trust language in future UI surfaces
+- integrity methods, attestations, and runtime reproducibility can all reference validation method artifacts
+- `.validator.md` method artifacts are reusable validation method definitions, not executable validators or validation result ledgers
+- this schema should stay method-semantics-oriented rather than becoming a result ledger
+- this support/governance schema intentionally omits `Artifact Creation Contract` until ordinary app creation behavior is explicitly declared
+
+---
+
+# Continuity Integrity
+
+- sha256-base64url-c14n-v1
+  - Towards: [tiinex.root.v1.schema.md](https://github.com/Tiinex/docs/blob/78a3673444666f1145be4feca6e7eb1476a44281/.topics/.schemas/tiinex.root.v1.schema.md)
+  - Value: BFWYft1v0Ue0gUoO236DGScvnixS7_MIEwO6mhJhkNw
+
+- sha256-base64url-c14n-v2
+  - Towards: self
+  - Value: C0az3msKICiqcp2tNF5uWe-qN7Mw7LZdbCcZfSDsx1k