# Intransic — Foundation, evidence and trust A repository accumulates claims: documents, filenames asserting completion, roadmap entries, an interface that implies a capability. This process sorts the claims that are true from the ones that merely persist, records what supports each, and refuses to publish anything the support does not carry. The core idea: **every claim traces to executable evidence**, recorded in a ledger. Public wording lives in the ledger beside its evidence, and the public trust package is *generated* from it — so a claim cannot drift from its evidence by editing, and a claim whose evidence weakens is downgraded rather than carried forward. ## Authority order Two different questions, and conflating them is how a Foundation goes stale without anyone noticing. **What is currently true?** Evidence decides, higher wins: **implementation → executed tests → direct observation → configuration and schema → infrastructure → documentation last.** Documentation is a claim to be verified, never evidence — and the Foundation is a document. It does not outrank the code it describes. **What must remain true?** The Foundation decides. `change_constraints` and the domain invariants are the ratified constraint set: code that breaches one is a defect to fix, not a new truth to record. When the two disagree — the Foundation asserts something the implementation no longer does — that is a **contradiction to record**, never a silent win for either side. Mark the claim `contradicted`, enter it in the contradiction register, and resolve it deliberately: either the code regressed and must be repaired, or the constraint genuinely changed and the Foundation must be re-ratified. An out-of-date Foundation must never be able to overrule working code, and working code must never quietly redefine a constraint someone ratified. ## Status vocabulary `verified` · `implemented_unverified` · `partial` · `planned` · `deprecated` · `unknown` · `contradicted` A capability is *implemented* only when the operational path exists. An interface, mock, design document or dormant module is not enough. **`contradicted` claims are never published, in any form.** `verified` and `implemented_unverified` are separated by evidence strength, not by confidence. See below. ## Evidence strength What a citation *establishes* is not the same as what it *is*. Weakest first: | Strength | Establishes | Default for | |---|---|---| | `existence` | a file, symbol or interface is present | `documentation`, `git`, `schema` | | `implementation` | an active code path, or committed configuration | `implementation`, `configuration`, `infrastructure` | | `behavioural` | an executed test asserts the behaviour | `test` | | `operational` | the running system was directly observed | `observation` | | `deployed` | production configuration or telemetry | — | | `independent` | external audit or certification | — | **`verified` requires `behavioural` or stronger** (`E-11`). Existence and implementation support `implemented_unverified` at best — that a rate-limit attribute sits in source is not that the limit holds. Documentation and git are never sole support for any publishable status (`E-12`). Set `strength:` on an item explicitly when a citation is *weaker* than its type suggests: a dormant interface cited as `implementation` is `existence`. The default cannot tell a live code path from a dead one. ## Personal data gets the same discipline, at field level `data.classifications` should not stop at a category — trace it to real `fields:` (`path` + `symbol`), checked by `F-10`. A `pii_coverage` conformance rule (see `validation/README.md`) then scans your actual source for PII-shaped field names and flags any absent from that list, so a new field landing in the code doesn't silently outrun the Foundation. `privacy.processors` registers every third party receiving personal or sensitive data — cloud hosting and the LLM provider belong here as much as anything that reads as an "integration" — with `F-11` requiring each entry complete and evidenced. ## Infrastructure is evidence, and its silences are findings The authority order puts configuration and infrastructure above documentation, but nothing collects them on its own. The `infra_posture` conformance kind (see `validation/README.md`) reads a committed infrastructure snapshot and flags any posture — a database open to the public internet, a firewall rule admitting an entire cloud, an application authenticating as a server admin — that the Foundation's `boundaries` or `security` sections never mention. It exists because every other rule falsifies claims, and the most common security failure is not a false claim but no claim at all. --- ## Which job is this? | Situation | Do this | |---|---| | First time in this repository | Full build — read `reference/process.md`, follow the execution sequence below | | Reviewing a proposed change | `prompts/change-review.md` | | Before a release | `prompts/release-validation.md` | | Evidence has moved since last time | `prompts/trust-wall-refresh.md` | | Full reassessment, or onboarding someone | `prompts/repository-review.md` | | Just checking consistency | `python3 intransic/validation/validate_*.py` | --- ## Operating rules These hold throughout, and they are the point of the process rather than ceremony around it. 1. **Evidence before assertion.** For every material claim compare implementation, tests, configuration and infrastructure, schemas and migrations, API contracts, then documentation. Where sources conflict, **record the conflict** — do not silently pick one. 2. **Do not invent maturity.** Never call something implemented because it appears in a roadmap, an ADR proposal, a TODO, a commented-out block, a partially wired module, or an interface with no active implementation. 3. **Separate public from private.** Public assets expose no secrets, credentials, private endpoints, customer identities, exploitable detail, internal architecture, proprietary algorithms or operational weaknesses. Internal assets keep the full technical detail. 4. **Do not modify production behaviour.** No refactoring, no runtime changes, no dependency upgrades, no renames, no infrastructure edits, no new services. You add documentation, schemas and non-invasive validation assets only. 5. **Trace every material claim** to a repository-relative path, symbol, test name, configuration key, schema, route, or commit. 6. **Never print or copy a secret value** you encounter. Record its location, key path and category — nothing else. --- ## Execution sequence Follow it in order. The two approval gates are not optional: this process generates assets that make public claims about someone else's system. **Step 1 — Inspect only.** Produce, in conversation: repository summary, major components, documentation sources, likely-authoritative files, obvious contradictions, proposed file tree, areas requiring caution, analysis confidence. **Create no files.** **Step 2 — Present the generation plan.** Files to create, files to amend, assumptions, information excluded from public assets, likely Foundation sections, likely Trust Wall claims, validation approach. **Wait for approval.** **Step 3 — Generate.** Foundation, internal assets, Trust Wall, validation tooling. Copy `templates/`, `schemas/`, `validation/` and `prompts/` into the target repository, then fill them in from evidence. **Step 4 — Validate.** Schemas parse; YAML and JSON are valid; evidence paths resolve; public claims map to evidence; no secrets in public files; internal and public maturity agree; documentation links resolve; the scripts actually run. **Step 5 — Report honestly.** Files created, files modified, validation results, claims safe to publish, **claims withheld**, unresolved contradictions, highest-risk gaps, recommended next action, exact rerun commands. Prefer under-claiming to over-claiming at every step. Record what you could not determine rather than filling the gap with plausible inference. --- ## Installing into a repository Run from the target repository's root, with `$S` pointing at this skill: ```bash # Installed as a plugin this resolves on its own; otherwise point S at the # skill directory yourself (a vendored checkout, or ~/.claude/skills/intransic). S="${CLAUDE_PLUGIN_ROOT:+$CLAUDE_PLUGIN_ROOT/skills/intransic}" : "${S:=$HOME/.claude/skills/intransic}" mkdir -p intransic/{config,internal,schemas,validation,prompts,reports} cp "$S"/schemas/* intransic/schemas/ cp "$S"/prompts/* intransic/prompts/ cp "$S"/validation/* intransic/validation/ cp "$S"/templates/claim-policy.yaml "$S"/templates/publication-policy.yaml \ "$S"/templates/intransic.config.yaml intransic/config/ cp "$S"/templates/validation-rules.yaml intransic/validation/ ``` Then fill in `intransic/config/intransic.config.yaml` — the one genuinely per-repository file — and write the `repository_conformance` rules, which ship empty with worked examples commented out. Validator dependencies are **development-only** (PyYAML, jsonschema). They must never be added to the application's own manifest. --- ## What is here | Path | What it is | |---|---| | `reference/process.md` | The full ten-phase process. Read for a first build or a full reassessment. | | `prompts/` | Four scoped prompts for recurring work — change, release, refresh, review | | `templates/` | `intransic.config.yaml`, `validation-rules.yaml`, `claim-policy.yaml`, `publication-policy.yaml` | | `schemas/` | JSON Schemas for the foundation, the ledger and published claims | | `validation/` | Runnable checks, and `README.md` explaining what they cannot establish | --- ## What a green validation run means **"Nothing is claimed that the evidence does not support."** Nothing more. It does not mean the system is secure, correct, private or compliant. It does not mean a cited file contains what its explanation claims, that deployed configuration matches committed configuration, or that no secret has leaked — the config scan reads the working tree, and a secret removed from `HEAD` remains in history. Say this plainly whenever you report a passing run. A trust process that overstates its own assurance has failed at the only thing it does.