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:

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?

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:

# 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

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.