{"id":49284815,"url":"https://github.com/theislampill/daee-epistemics","last_synced_at":"2026-05-20T06:06:17.696Z","repository":{"id":351406112,"uuid":"1210835608","full_name":"theislampill/daee-epistemics","owner":"theislampill","description":"A modular LLM skill for epistemic operations and noetic analysis: a cognitive-security framework (SOC) for classifying discourse and diagnosing orientation, deformation, and concealment; routing engagements through matched case modules and tactics, techniques, and procedures (TTPs), grounded in sound reason and normative disposition.","archived":false,"fork":false,"pushed_at":"2026-04-22T23:26:09.000Z","size":705,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-04-23T01:20:02.783Z","etag":null,"topics":["agentic-ai","diagnostic-framework","epistemology","knowledge-representation","llm-skill","meta-epistemology","metaphysics","noetic","ontology","philosophy","reasoning"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/theislampill.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-04-14T20:01:24.000Z","updated_at":"2026-04-22T23:10:08.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/theislampill/daee-epistemics","commit_stats":null,"previous_names":["theislampill/daee-epistemics"],"tags_count":5,"template":false,"template_full_name":null,"purl":"pkg:github/theislampill/daee-epistemics","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/theislampill%2Fdaee-epistemics","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/theislampill%2Fdaee-epistemics/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/theislampill%2Fdaee-epistemics/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/theislampill%2Fdaee-epistemics/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/theislampill","download_url":"https://codeload.github.com/theislampill/daee-epistemics/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/theislampill%2Fdaee-epistemics/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":32276628,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-25T18:29:39.964Z","status":"ssl_error","status_checked_at":"2026-04-25T18:29:32.149Z","response_time":59,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["agentic-ai","diagnostic-framework","epistemology","knowledge-representation","llm-skill","meta-epistemology","metaphysics","noetic","ontology","philosophy","reasoning"],"created_at":"2026-04-25T21:01:38.482Z","updated_at":"2026-05-20T06:06:17.681Z","avatar_url":"https://github.com/theislampill.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# daee-epistemics\n\n`daee-epistemics` is a modular LLM skill and governed diagnostic framework for epistemic operations and noetic analysis. It uses a limited cognitive-security analogy as onboarding language, but the release claim is the repo-native runtime discipline: compact DSL/IR diagnosis, recursive state re-read, owner/TTP routing, bounded response release, and evidence-bound packaging.\n\nThis repository now has two deliberate layers: canonical atomized source under [`atomics/skill/`](atomics/skill/) and a generated compiled Claude runtime under local/CI `skill/`.\n\nThe package is grounded in the coherence and convergence of a common sense account of sound reason, the *fiṭrah* (the innate normative disposition toward truth), and revelation. \nIt is designed to examine the condition of the *qalb* (heart-mind) and the *ʿaql* (intellect or reason) before replying to doubts, objections, and worldview conflicts. \nIts governing aim is not to manufacture novelty or simply accumulate clever refutations, but to restore sound cognition so that foundational knowledge, inference, testimony, signs, and revelation are encountered in their proper order.\n\nRuntime coverage and scope in the repository are represented by generated `skill/SKILL.md`,\nmodule front matter preserved from source, `compiled-module-map.json`, repo-only catalogue and\nrouting indexes, and explicit owner/router scope notes. Future scope decisions live in\n[`TODO.md`](TODO.md).\n\n## Table of Contents\n- [Before You Use This Skill](#before-you-use-this-skill)\n- [Terminology Note](#terminology-note)\n- [Core Thesis](#core-thesis)\n- [Runtime Architecture, Not Prompt Advice](#runtime-architecture-not-prompt-advice)\n- [Why This Framing Fits the Repository](#why-this-framing-fits-the-repository)\n- [What the Skill Protects](#what-the-skill-protects)\n- [Threat Model](#threat-model)\n- [Operational Governance](#operational-governance)\n- [Render Modes](#render-modes)\n- [Integration Boundary](#integration-boundary)\n- [Source / Runtime Layout](#source--runtime-layout)\n- [Repository Architecture](#repository-architecture)\n- [Repository Diagram](#repository-diagram)\n- [Install, Package, and Runtime Use](#install-package-and-runtime-use)\n\n## Before You Use This Skill\nThe skill needs a practitioner whose own *fiṭrah* is in reasonable health.\n\nObstacles to clear:\n- *bidʿī ʿaqlī* (contaminated rationality)\n- *bidʿī naqlī* (corrupted transmission)\n\nThe diagnostic faculty is subject to the same taxonomy it applies. \n\nThe skill identifies in interlocutors seven deformations of the *fiṭrah* — \n- *iʿtiqādāt mawrūtha* (inherited beliefs)\n- *hawā* (whim, preconceived bias, or stubbornly clinging to personal opinion in the face of countervailing evidence)\n- *ẓann* (conjecture)\n- *taqlīd* (blind imitation)\n- *ʿāda* (unreflective habit)\n- *gharaḍ* (ulterior motive or vested interest)\n- *shubhah* (doubt or misgivings)\n\nA practitioner's diagnostic reads are only as reliable as the health of the practitioner's own noetic structure. \nA practitioner operating under *hawā* (will dug in), *gharaḍ* (something at stake), or *iʿtiqādāt mawrūtha* (invisible inherited filters) will produce reads contaminated by those deformations — and will execute every downstream tactic on the basis of those reads. The procedure does not fix a deformed faculty; it inherits its condition.\n\nThe skill is ordered toward restoration, not performance. \nThe standpoint stated in §I — removal of occlusion, not construction of novelty; the task of reminder and restoration, not of winning — applies to the practitioner first. \nUsing this skill as a debating instrument, a credential, or a means of forcing verbal concession is itself a deformation: *gharaḍ* or *hawā* operating in the practitioner rather than in the interlocutor.\nThe character note in §I is not decorative. \n\"The absence of defensiveness, the quality of genuine listening\" are epistemically constitutive — they are part of what makes the engagement reach where argument cannot, especially where doubt is entangled with damaged trust or bad religious experience.\n\nThe symmetric check applies inward before outward. \n`references/tactics/symmetric-taqlid-check.md` exists for a reason: an atheism absorbed from one's intellectual environment without genuine investigation is *taqlīd*, and so is a theism held by convention without genuine examination. Before deploying V7 against an interlocutor's assumed-by-default skepticism, the practitioner should have applied the same check to their own positions. The practitioner who holds their own commitments by *taqlīd* rather than *taḥqīq* has no standing to press the outward check. \nThis is not a one-time gate — it is a standing discipline, because *iʿtiqādāt mawrūtha* can reestablish itself and *ʿāda* deepens with time.\n\nThe tool can assist getting there. \nThe skill's diagnostic vocabulary — Deformation Types, Discourse Orientation, Noetic Structure across the nine analytical dimensions — is available for self-application. A practitioner who suspects their own reads are contaminated can run the noetic reading checklist and the seven deformations taxonomy on themselves, not only on interlocutors. \nDimension 8 (discourse orientation) is especially apt: determine whether your own engagement is ordered toward truth and warrant, or toward identity-performance or vested outcome. This is a feature of the architecture, not an afterthought — the same instruments that produce a structured diagnostic of an interlocutor's noetic structure can produce one of the practitioner's own.\n\n## Terminology Note\n\nThe repository uses Arabic and philosophical vocabulary because the framework itself is articulated in those terms. \nFor fuller definitions, see [`references/terminology.md`](atomics/skill/references/terminology.md).\n\nReaders unfamiliar with the vocabulary should treat these terms as named components of the framework. \nThe repository's own method requires clarity before response, and that applies to terminology as well.\n\n## Core Thesis\n\n\u003e `daee-epistemics` is best understood as a governed diagnostic-and-release runtime:\na structured system for identifying, classifying, and remediating epistemic distortion affecting the heart-mind.\n\nThe point of that analogy is architectural (onboarding-oriented), not ornamental. \n\nMore fundamentally, the skill is attempting to formalise not only the handling of cases within the domain, but the domain’s own **epistemology, noetic analysis, diagnostic ontology, and meta-level grammar** by which cases are subjected to **first-order analysis, higher-order diagnosis, case-typing, routing, interpretation, and restoration**.\n\nThe skill covers a governed diagnostic and restorative framework for epistemological, ontological, metaphysical, theological, and related philosophical cases, while also formalising the meta-level grammar by which such cases are typed, routed, interpreted, and restored. \nIt aims to externalise the domain’s diagnostic ontology into a compact DSL/IR so that both higher-order diagnosis and first-order analysis become explicit, auditable, and reusable. \nThis means the encode/decode not just of answers, but the operative ontology of epistemic states, noetic structures and deformations, and restoration transitions: \nwhat kind of case is present, \nwhat level it is operating at, \nwhat is being smuggled or conflated, \nwhat must be clarified first, \nwhat routing follows, and \nhow a case moves from deformation toward restored order.\n\nIn that sense, the framework is not just organising content; it is formalising a meta-epistemology and an operative map of noetic, epistemic, ontological, and meta-level states and transitions. That makes the system more disciplined at runtime, more portable across models, more compressible across context windows, and potentially usable not only as reference material but as a training grammar for diagnosis, analysis, and restoration. Governance determinacy is practitioner-compliance-based: enforcement depends on the practitioner following the governance files, not on a mechanical runtime validator. The `diagnostic-ir.schema.json` is a constraint specification; its compliance is checked conceptually against the schema's rules, not validated automatically at inference time.\n\nThis makes it desirable for both frontier and quantised LLMs, though for different reasons. \nFor frontier models, it functions as external discipline: it reduces drift, forces explicit case-typing and routing, and makes outputs more auditable and reproducible rather than leaving the model to generate persuasive but structurally ungoverned prose. \nFor quantised or smaller models, it functions as external cognitive compression: instead of having to internally reconstruct the whole domain at full resolution, the model can operate through a compact case language, typed state, and bounded restoration grammar.\n\nIn both cases, the point is the same: to shift the burden from vague latent improvisation toward a portable, inspectable, and reusable structure for diagnosis, analysis, and restoration.\n\nThe cognitive-security analogy is helpful only as an onboarding frame. It is secondary to the actual implementation boundary: DSL/IR state, owner/TTP contracts, state-transition discipline, generated runtime, package-shape checks, and evidence-bound release proof.\n\n## Runtime Architecture, Not Prompt Advice\n\nThe easiest way to misread this repository is to treat `SKILL.md` as a sophisticated prompt:\n\"when an objection appears, check these things, then answer.\" That is not the intended\narchitecture.\n\n`daee-epistemics` specifies a runtime execution architecture over a live diagnostic state. The\nDiagnostic IR is not a checklist or answer template; it is the compiler state that carries\nselected or held noetic frames, live registers, burden/dependency structure, held routes, owner\neligibility, and closure posture. If that state collapses into a scalar label such as \"this is a\nTrinity objection\" or \"this is a secular-humanist objection,\" the runtime has lost the field it\nis supposed to govern.\n\nThe operators are part of that state discipline. Plain `∇` reads route-gradient pressure among\neligible live burdens after IR/routing/catalogue gates have constrained the field. `Δ` marks an\nevent-local transition over a burden or field state when a burden lands. `R(H,Δ)` rereads the\nwhole live field after that transition. `∇·` and `∇×` are post-transition diagnostics over the\nfield that `Δ` produced: `∇·` reads residual outward pressure in an explicit target field, and\n`∇×` reads circular or rotational dependency in an explicit target field. A nonzero `∇×T` may\nlicense a target-explicit `LoopBreak(∇×T)` only when an owner-grounded loop-breaker is available.\nThey do not apply to a one-point summary, and they do not replace `Δ`.\n\nClosure is therefore not a stylistic judgment that the reply \"seems complete.\" `𝒞(Ψᴺ)` is a\npositive closure-field condition over the agent execution field: residual divergence/curl pressure\nmust be cleared, integrated, discharged as derivative, held with reason, or carried into `RECURSE`\nor `PARTIAL`. In hard cases with multiple valid noetic-structure selections, the selected\nexecution path is only the release order over the live field. Alternate structures, hidden\ndependencies, circularities, and residual pressures still have to be accounted for, and the final\nrestorative response must preserve the master deformation discovered during execution. The\ninterlocutor's diagnosed field `Ψᴵ` is coupled through language; the runtime does not claim access\nto the soul, guaranteed uptake, or control of guidance.\n\nWhether a particular model instance fully executes this architecture is a behavioral and evidence\nquestion. The architecture itself is not reducible to prompt engineering: it is a stateful,\nowner-governed process with transition, reread, field-diagnostic, and closure conditions.\n\nThe limited security analogy is that a serious response system does not begin by deploying countermeasures blindly; it initiates:\n* intake\n* triage\n* classification\n* root-cause analysis\n* response selection. \n\nThis repository applies a comparable logic to theological and philosophical engagement. \nIt treats an objection not merely as a proposition to rebut, but as an event arising within a wider *noetic structure* (the underlying structure of how a person knows, trusts, reasons, and proportions belief).\n\nNot a storehouse of arguments; this is a diagnostic-response framework for epistemic compromise.\nIts aim is restorative: to clear occlusion, reorder cognition, and return the person to sound perception of truth rather than to construct belief from nothing.\n\n## Why This Framing Fits the Repository\n\nThe analogy also highlights dependency awareness. In this skill, **Noetic Structure** functions like an inventory of live epistemic dependencies.\n\nIt maps:\n* what the person takes as basic\n* what they think counts as evidence\n* whether their commitments are foundational or derivative\n* how they proportion assent\n* what they trust as testimony\n* what inferential norms they presuppose\n* what distortions are already upstream\n\nSo, noetic structure is not just \"their worldview\"; it is more like the **ontology of their epistemic operating environment.**\n\nThe repository begins with diagnosis before rebuttal. \n[`atomics/skill/SKILL.md`](atomics/skill/SKILL.md) instructs the practitioner to identify input type, epistemological position, mode of concealment, deformation, and discourse orientation before selecting any deeper module. \nThat posture is the opposite of generic polemics, which often move straight to proposition-level refutation.\n\nThis matters because the framework treats falsehood as more than a bad conclusion. \nIt also tracks compromised process: \n* inherited priors presented as neutral defaults\n* malformed evidential standards\n* grief operating as epistemic fog\n* socially reinforced habits of discourse\n* volitional resistance masquerading as pure rationality. \n\nA formally correct argument can fail if it is given to the wrong kind of case.\n\nFor that reason, the repository routes engagements by condition, not only by topic. \nIn some cases the appropriate move is inferential; in others it is classificatory, clarificatory, or *maieutic* (a method of drawing out latent recognition rather than supplying wholly new content). \nThe underlying assumption is that truth is often already signified but occluded, displaced, or misread.\n\nPattern-first routing is diagnostic precedence, not abstract universalism. It means the live\ndeformation, concealment, warrant disorder, or authority-order problem governs before superficial\ndenomination/topic labels. It does not make traditions interchangeable under neutral comparative\ncategories, and it does not claim arbitrary pattern-analysis generates truth. Restoration remains\nordered toward sound *fiṭrah*, sound reason, revelation, and their non-contradictory ordered\nconvergence.\n\nRuntime routing is therefore:\n\n```text\nPattern(deformation/concealment/unsoundness) \u003e denomination/source-label\n```\n\nA named framework, school, source, author, genealogy, or identity may supply internal\nsource-status context, but it is not public-render material by default and is never sufficient to\nroute content or release an apologetic argument bank. Default citation is restricted to Qurʾān,\nSunnah, and sound Salaf narrations with direct source reference. The DSL/IR routes by the detected\nnoetic operation: criterion import, tribunal installation, predication error, authority-order\ndisorder, warrant failure, concealment, deformation, and the active `claim_level` /\n`pattern_profile`.\n\n## What the Skill Protects\n\nThe protected asset is not \"belief\" in a thin or merely verbal sense. \nThe framework is concerned with the integrity of epistemic constitution as rightly ordered toward truth: \n* the *fiṭrah*\n* sound *ʿaql*\n* the right relationship among foundational knowledge\n* inferential knowledge\n* testimony\n* signs\n* revelation.\n\nThat is why the repository is restorative rather than novelty-producing. \nIt assumes that sound reason and authentic revelation agree, and that many objections become persuasive only after the noetic environment has already been disordered. \nThe work, then, is to identify that disorder and respond at the right depth.\n\n## Threat Model\n\nThe framework's threat model includes more than explicit disbelief. It also includes conditions that deform inquiry upstream:\n\n- inherited background assumptions posing as neutrality\n- *taqlīd* (unexamined imitation) and socially inherited defaults\n- malformed evidential standards that treat one narrow criterion as the whole of rationality\n- category mistakes, equivocation, univocal predication failures, domain-boundary violations, and false contrasts\n- grief, injury, or moral protest functioning as epistemic fog\n- identity-protective habits of discourse\n- volitional resistance and vested interest\n- pseudo-rational criteria that parasitize genuine rational norms\n\nIn this model, an objection may be intellectually formulated while still arising from a compromised epistemic process. \nThat is why the repository repeatedly distinguishes deformations, concealment modes, and discourse orientation before recommending a response.\n\n## Operational Governance\n\nThe repository is not only a content store. It carries an explicit governance layer that makes its routing state inspectable:\n\n- a compact case-state schema for naming what kind of case is being read, which module subset is being selected, why, with what confidence\n- a conditional `claim_level` / `pattern_profile` layer in case-state and diagnostic IR for distinguishing first-order objections from meta-epistemic, meta-ontological, and meta-noetic burdens when that distinction changes routing\n- an inference-boundary legend separating direct file content from cross-file synthesis, model inference, and speculative extension\n- mixed-case and insufficient-basis rules to keep the model from overclassifying thin or ambiguous cases\n- an anti-pattern sheet to catch diagnosis collapse, forced fit, tactic over-selection, decorative terminology, higher-order vocabulary theater, rhetorical overreach, excerpt over-read, and register-hold bypass before they harden into output\n\n**Burden-cycle model (orientation for first-contact readers):** The skill is not a one-shot\npipeline. It reduces a live burden into internal Diagnostic IR, routes only after the\ndispatch gate, renders the permitted surface, then re-reads state before STOP, HOLD,\nRECURSE, or PARTIAL. Runtime detail is owned by\n[`diagnostic-ir.md`](atomics/skill/references/diagnostics/diagnostic-ir.md),\n[`recursive-state-transitions.md`](atomics/skill/references/diagnostics/recursive-state-transitions.md),\n[`routing-precedence.md`](atomics/skill/references/diagnostics/routing-precedence.md),\n[`diagnostic-render-contract.md`](atomics/skill/references/rubrics/diagnostic-render-contract.md),\nand [`output-release.md`](atomics/skill/references/rubrics/output-release.md).\n\nThis matters because the repository's thesis is restorative, not merely polemical. \nThe framework should make it easy for a model to say, succinctly, \"this is the kind of case I think this is, this is why I am taking this path, this is how sure I am, and this is where I am inferring beyond the file set.\"\n\n## Render Modes\n\nCanonical invocation forms:\n\n```text\n/daee-epistemics\n/daee-epistemics:dsl\n/daee-epistemics \u003c C:\\path\\input.md \u003e C:\\path\\output.md\n```\n\n- `/daee-epistemics` is the canonical compact DSL-governed runtime:\n  `Layer A(compact DSL/IR header) + Layer B(bounded governed response) + State/noetic re-read`.\n  Layer B visibly includes Hidden Premises, local Core Formulation per released operation,\n  bounded operative submoves, and compact TTP/operator trace when a named operator performs\n  work. State/noetic re-read comes before the single Restorative Response and final Closing Formulation.\n  It does not print raw Diagnostic IR, full Case State, `matched_modules`, route ledger,\n  or load ledger. It is not prose-only mode; DSL/IR is integral to the skill's\n  anti-hallucination, routing, burden-accounting, and restoration discipline.\n- `/daee-epistemics:dsl` is expanded diagnostic/IR visibility: compact Diagnostic IR or Case State, live noetic burden sequence, held material, state re-read, and STOP / HOLD / RECURSE / PARTIAL when visible structure is requested. It is not the first place DSL governance appears.\n- `/daee-epistemics \u003c input.md \u003e output.md` is canonical file-retained execution. It reads the case from `input.md`, writes the full canonical compact DSL-governed answer to `output.md`, and keeps the chat response to status only. This is not the optional script-capable route/check harness; it is the canonical runtime using a safer output transport for hosts whose final-chat channel compresses hard cases.\n\nDefault output must visibly instantiate compact compiler state enough to prevent clean essay\ncosplay. The exact field list and failure modes are owned by\n[`diagnostic-render-contract.md`](atomics/skill/references/rubrics/diagnostic-render-contract.md)\nand the root control plane in [`atomics/skill/SKILL.md`](atomics/skill/SKILL.md).\nRecursive render details are governed by the runtime references, not by the\nREADME; compact output is a concise governed surface, not a thin mode.\n\n`/daee-epistemics:audit` is deprecated as a public render mode and retained only as an internal/development compatibility surface for regression review, bundle/source-basis inspection, and procedural debugging. Default mode must not depend on `:audit` for governance visibility.\n\nThe former external recursive-audit prompt is deprecated for normal use. Its useful traversal discipline is now internal governance; use `:dsl` for expanded diagnostic/IR visibility.\n\n### Canonical File-Retained Execution\n\nUse file-retained execution when the host can read/write files or when hard cases would be\ncompressed in final chat:\n\n```text\n/daee-epistemics \u003c C:\\path\\input.md \u003e C:\\path\\output.md\n```\n\n- `\u003c input.md`: read the case/input from this markdown file.\n- `\u003e output.md`: write the full governed answer to this markdown file.\n- `output.md` must contain the canonical compact DSL-governed surface: compact Layer A,\n  governed Layer B, burden-local operation, `Land(B)`, compact Δ/field diagnostics, `R(H,Delta)`,\n  continue/HOLD/PARTIAL/close, and restoration.\n- The chat response must not replace the file output. It should only report the input file\n  read, output file written, approximate output length, and completion status. It should not\n  add source links, sanity scans, checker notes, verification claims, or commentary.\n- File-retained execution does not run repo checkers, route tools, smoke-artifact tools, or\n  execution-fidelity checks unless developer validation is explicitly requested. The chat status\n  should not add harness verdicts, route-plan claims, or source-audit commentary.\n- Hard or multi-burden file-retained answers should keep explicit `Land(Bn)` and\n  `R(H,Delta)` attachment per released burden rather than replacing them with a generic\n  state paragraph.\n\nBash-style shells use `\u003c` and `\u003e` for redirection. PowerShell supports `\u003e` for output\nredirection, but stdin behavior differs. Because `/daee-epistemics` is a skill invocation,\nnot necessarily a real shell command in every host, `\u003c \u003e` is skill-level file-retained\nexecution syntax where the host/agent supports file reads/writes.\n\n## Integration Boundary\n\nNew background material should be integrated only when it improves routing, restoration, scope control, or terminology discipline.\n\nThe goal is not to accumulate study notes. \n\nThe goal is to extract durable distinctions and convert them into reusable architecture: new Case Modules, tighter Tactic or Technique criteria, clarified Glossary entries, sharper confidence rules, or better routing boundaries. \n\nIf material does not alter how the skill classifies, sequences, or restores, it should usually stay outside the live skill surface.\n\n## Source / Runtime Layout\n\nThe editable source and deployable runtime are intentionally separate:\n\n| Path | Role |\n|------|------|\n| [`atomics/skill/`](atomics/skill/) | Canonical atomized skill source. Edit this tree. |\n| `skill/` | Generated local/CI compiled Claude package root. Ignored by git; do not hand-edit or stage this tree. |\n| [`tools/`](tools/) | Compiler and checker scripts. |\n| [`tests/routing-fixtures/`](tests/routing-fixtures/) | Static routing parity fixtures. |\n| [`docs/`](docs/) | Architecture notes, audits, and verification reports. |\n| [`build/`](build/) | Optional local package/release outputs. |\n\nNormal source workflow:\n\n```bash\npython tools/build_framework_pipeline.py\npython tools/build_compiled_runtime.py\npython tools/check_compiled_runtime_freshness.py\npython tools/check_level3_data_shapes.py --include-generated\npython tools/check_package_shape.py\npython tools/check_compiled_module_boundaries.py\npython tools/check_stub_integrity.py\npython tools/check_consolidation_call_budget.py\npython tools/check_routing_parity.py\npython tools/check_routing_parity.py --strict\npython tools/check_recursive_traversal_governance.py\npython tools/check_render_modes.py\npython tools/check_frontmatter.py\npython tools/check_coverage.py\npython tools/check_framework_pipeline.py\npython tools/check_recursion_collapse_noetic_frame.py\npython tools/check_metacompliance_current_canon.py\npython tools/check_smoke_artifacts.py\npython tools/check_ir_instance_integrity.py\npython tools/check_diagnostic_ir_catalogue_integrity.py\npython tools/check_encoding_hygiene.py\n```\n\nThe compiled runtime may still name atomized paths such as `references/tactics/M9-predication-mode.md`.\nInside generated `skill/`, those are canonical module/source identities, not a claim\nthat `skill/` is tracked source, unless the file actually exists there.\nResolve missing atomized paths through `skill/compiled-module-map.json` to the containing runtime\nbundle and `MODULE_ID` section.\n\n## Repository Architecture\n\nThe repo is organized around one tracked source-of-truth tree, one ignored\ngenerated runtime tree, and several verification surfaces. Edit canonical\nsource under `atomics/skill/`, then regenerate local/CI `skill/`; do not\nhand-edit or stage generated runtime files as source.\n\n| Path | Role |\n|------|------|\n| [`atomics/skill/`](atomics/skill/) | Canonical editable skill source: root instructions, references, owner files, and repo-only optional harness material. |\n| [`atomics/skill/references/`](atomics/skill/references/) | Canonical noetic, diagnostic, TTP/owner, procedure, rubric, and case-library source. |\n| [`atomics/skill/data/`](atomics/skill/data/) | Repo-only optional route/check harness data: trigger matrix, precedence, module catalogue, and ontology licenses. |\n| [`atomics/skill/scripts/`](atomics/skill/scripts/) | Repo-only optional harness source scripts for diagnosis, deterministic routing-given-features, validation, reconstruction, orchestration, and execution checking. |\n| [`atomics/skill/tests/`](atomics/skill/tests/) | Repo-only optional harness fixtures and expected route plans. |\n| `skill/` | Ignored generated runtime root. The canonical user-facing package archives only scriptless runtime material produced here by local/CI build. |\n| `skill/data/`, `skill/scripts/`, and `skill/tests/` | Generated optional harness view for repo/dev validation when present; excluded from the canonical user-facing package. |\n| `skill/references/` | Generated runtime and omnibus bundles. Availability is not activation. |\n| `skill/compiled-module-map.json` | Runtime resolver from original module ID/source path to generated bundle section. |\n| `skill/build-manifest.json` | Generated freshness and source-checksum manifest. |\n| [`tools/`](tools/) | Build, checker, smoke-artifact, IR, routing, reconstruction, and hygiene tooling. |\n| [`tests/`](tests/) | Static routing, IR, and reconstruction fixtures for maintainers. |\n| [`ci/`](ci/) and [`.github/workflows/`](.github/workflows/) | Maintainer CI wrappers around local checks. |\n| [`docs/`](docs/) | Architecture notes, onboarding, release logs, and audit evidence; not runtime source. |\n\nRead behaviorally, the architecture works like this: diagnose the noetic state,\nidentify the live burden and restoration target, classify deformation,\nconcealment, and discourse orientation, route only through licensed owners, land\nthe current burden, re-read state, then stop, hold, recurse, or mark partial.\nIn script-capable runtimes, the optional route/check harness can make that sequence executable\nand checkable; in scriptless runtimes, the canonical compact DSL-governed surface remains the\nportable runtime, not a prose fallback.\n\n[`atomics/skill/references/techniques/heuristics.md`](atomics/skill/references/techniques/heuristics.md) functions as the analyst-discipline layer governing how the framework is used.\n\n## Repository Diagram\n\nThe repo also carries a visual architecture reference:\n[`docs/daee-epistemics-pipeline.html`](docs/daee-epistemics-pipeline.html). It is a\nnavigation aid, not a new source of truth, and should stay in parity with the canonical\ncompact DSL-governed runtime, canonical package boundary, and repo/dev harness boundary.\nThe expanded algebraic notation and schema-light register bridge are preserved in\n[`docs/algebraic-notation-and-noetic-formalism.md`](docs/algebraic-notation-and-noetic-formalism.md)\nand tracked in\n[`docs/register-formalism-implementation-ledger.md`](docs/register-formalism-implementation-ledger.md).\nRead that wording as schema-light register bridge baseline with a schema-light implementation:\nthe registers govern existing IR/control surfaces when live, while mandatory register fields\nremain a separate contract migration decision.\nThe bridge is current where atomics, generated runtime text,\n`tests/register-formalism-bridge-fixtures/`, and the recorded installed-skill hard-smoke audit make\n`heart` / `xi` / `Omega` / `mu` / `kappa` govern existing IR, owner/TTP selection, hold/release,\ncollapse radius, burden landing, state re-read, PARTIAL, anti-symbol-theater, or restoration. This\nis a derived/conditional bridge over the compact runtime, not a mandatory register-field schema\nmigration and not a v0.4.0.0 release/package readiness claim by itself without an authorized\nrelease-package artifact rebake and package-bound smokes.\n\nThe diagrams below split the repo into three views: source layout, runtime\ninvocation, and maintainer verification. The full internal pipeline audit\nsurface remains [`framework-pipeline.md`](atomics/skill/references/diagnostics/framework-pipeline.md);\nabstract recursive state-transition semantics live in\n[`recursive-state-transitions.md`](atomics/skill/references/diagnostics/recursive-state-transitions.md).\n\n### Repository Layout\n\n```mermaid\nflowchart TB\n\nSRC[\"atomics/skill\u003cbr/\u003ecanonical source\"]\nSRCREF[\"references\u003cbr/\u003eowners / diagnostics / rubrics\"]\nSRCL3[\"data + scripts + tests\u003cbr/\u003erepo-only optional harness source\"]\nBUILD[\"tools/build_compiled_runtime.py\u003cbr/\u003ecompiler\"]\nRUNTIME[\"skill\u003cbr/\u003egenerated package root\"]\nRTREF[\"runtime + omnibus references\"]\nRTL3[\"data + scripts + tests\u003cbr/\u003egenerated optional harness view\u003cbr/\u003enot canonical package\"]\nTESTS[\"tests\u003cbr/\u003erouting / IR / reconstruction fixtures\"]\nCI[\"ci + .github/workflows\u003cbr/\u003emaintainer checks\"]\nDOCS[\"docs\u003cbr/\u003eonboarding / audits / release evidence\"]\n\nSRC --\u003e SRCREF\nSRC --\u003e SRCL3\nSRC --\u003e BUILD\nBUILD --\u003e RUNTIME\nRUNTIME --\u003e RTREF\nRUNTIME -. dev/CI only .-\u003e RTL3\nSRC --\u003e TESTS\nTESTS --\u003e CI\nRUNTIME --\u003e CI\nDOCS -. explains .-\u003e SRC\nDOCS -. records evidence .-\u003e RUNTIME\n```\n\n### Runtime Invocation\n\n```mermaid\nflowchart TB\n\nUSER[\"User invokes /daee-epistemics\"]\nSKILL[\"Packaged SKILL.md\"]\nCANONICAL[\"canonical compact DSL-governed surface\u003cbr/\u003eLayer A -\u003e Layer B -\u003e Land(B) -\u003e Δ/field diagnostics -\u003e R(H,Delta)\"]\nFILEQ{\"file-retained syntax?\"}\nCHAT[\"chat response\u003cbr/\u003egoverned answer when host permits\"]\nFILEOUT[\"output.md\u003cbr/\u003efull governed answer\"]\nSTATUS[\"brief chat status\u003cbr/\u003einput / output / length / complete-HOLD-PARTIAL\"]\nDEVREQ{\"explicit maintainer harness request?\"}\nHARNESS[\"repo/dev route-check harness\u003cbr/\u003escripts + tests, not canonical package\"]\n\nUSER --\u003e SKILL\nSKILL --\u003e CANONICAL --\u003e FILEQ\nFILEQ --\u003e|no| CHAT\nFILEQ --\u003e|yes| FILEOUT --\u003e STATUS\nSKILL -. explicit dev/CI request only .-\u003e DEVREQ\nDEVREQ -. yes .-\u003e HARNESS\n```\n\n### Maintainer Verification\n\n```mermaid\nflowchart LR\n\nEDIT[\"Edit atomics/skill\"]\nBUILDPIPE[\"build_framework_pipeline\u003cbr/\u003ebuild_compiled_runtime\"]\nFRESH[\"freshness + module boundaries\u003cbr/\u003estub integrity\"]\nROUTING[\"routing parity\u003cbr/\u003ereconstruction fixtures\"]\nGOV[\"render / recursion / metacompliance\u003cbr/\u003eIR integrity\"]\nL3FIX[\"script-harness fixture runner\u003cbr/\u003estability repetitions\"]\nSMOKE[\"smoke artifact checks\u003cbr/\u003erelease evidence boundary\"]\nPACKAGE[\"optional package build\u003cbr/\u003ehash + current-release smokes\"]\n\nEDIT --\u003e BUILDPIPE --\u003e FRESH --\u003e ROUTING --\u003e GOV --\u003e L3FIX --\u003e SMOKE --\u003e PACKAGE\n```\n\n## Install, Package, and Runtime Use\n\n### Package Boundary\n\nThe canonical user-facing upload name is `daee-epistemics.skill`. For the v0.4.x release line,\nthe package artifact is built from atomics through generated local/CI `skill/` and recorded in\n[`docs/release-artifacts.md`](docs/release-artifacts.md). GitHub Releases are the binary\ndistribution surface; older v0.3.1.0 assets and smokes are historical evidence, not\ncurrent-package evidence for v0.4.0.0.\n`package.ps1` emits a local `.skill.zip` archive because it is a zip payload with the skill root\nat archive root. Publish/upload the same checked payload as `.skill`; do not publish both `.skill.zip`\nand `.skill`, and do not re-zip it.\n\nBinary skill archives and generated `skill/` runtime output are not committed to this repository.\nBuild locally or in CI from `atomics/skill/**` into generated `skill/`, then package that runtime,\nor use the verified public GitHub Release asset.\n\nThe canonical archive root must contain `SKILL.md`, `references/`,\n`compiled-module-map.json`, `build-manifest.json`, and `README.md` directly. It must not\ncontain the repo/dev harness roots `data/`, `scripts/`, or `tests/`. This returns the\nuser-facing package shape to the scriptless runtime boundary used before the optional\nroute/check harness was introduced, while retaining the harness in the repository for\nmaintainer validation. Do not zip the whole repo root, and do not produce a bundle whose top\nlevel is `skill/`. Package the canonical contents selected from the generated `skill/`\ndirectory, not the directory itself.\n\nFor path fidelity, build the archive with the manifest-backed package script. It validates the\ngenerated `skill/` tree, rejects unexpected packageable files, and writes slash-safe archive entry\nnames for skill hosts that inspect the bundle structure directly.\n\nOn Windows, `package.ps1` calls the Python packager in `tools/package_skill.py`. For a v0.4.0.0\nlocal package rebake, the command is:\n\n```powershell\npowershell -NoProfile -ExecutionPolicy Bypass -File .\\package.ps1 build\\daee-epistemics-v0.4.0.0.skill.zip\nCopy-Item build\\daee-epistemics-v0.4.0.0.skill.zip build\\daee-epistemics-v0.4.0.0.skill\n```\n\nFrom any folder, open a Bash-compatible terminal and paste the following if you want a clone-and-package flow. The command clones the repo into a temporary subfolder, builds `daee-epistemics.skill` from the generated `skill/` contents, and removes the temporary clone so the folder you opened ends with only `daee-epistemics.skill`.\n\n```bash\nrepo=\"https://github.com/theislampill/daee-epistemics.git\"\ntmp=\"daee-epistemics-src\"\ntmp_zip=\"daee-epistemics.tmp.skill.zip\"\nout_skill=\"daee-epistemics.skill\"\n\nrm -rf \"$tmp\" \"$tmp_zip\" \"$out_skill\"\ngit clone \"$repo\" \"$tmp\" \u0026\u0026\n(cd \"$tmp\" \u0026\u0026\n  python tools/build_framework_pipeline.py \u0026\u0026\n  python tools/build_compiled_runtime.py \u0026\u0026\n  python tools/check_compiled_runtime_freshness.py \u0026\u0026\n  python tools/check_package_shape.py \u0026\u0026\n  python tools/package_skill.py \"../$tmp_zip\") \u0026\u0026\nmv -f \"$tmp_zip\" \"$out_skill\" \u0026\u0026\nrm -rf \"$tmp\"\n```\n\nIf you open `daee-epistemics.skill`, you should see `SKILL.md`, `references/`,\n`compiled-module-map.json`, `build-manifest.json`, and `README.md` at the top level of the\narchive. You should not see `data/`, `scripts/`, `tests/`, `atomics/`, `tools/`, `docs/`,\n`build/`, `.git/`, `smokes/`, `.daee/`, `level3-runs/`, `__pycache__/`,\n`route_plan.json`, `features.json`, `validation.json`, `reconstruction.json`,\n`execution_verdict.json`, `execution_prompt.md`, `execution_blocked.md`, `partial_banner.md`,\n`retry_prompt.md`, `output.simulated.md`, or `output.model.md`.\n\n### Claude Installation\n\n1. Package the skill from this repository.\n2. Open Claude.ai and go to Settings \u003e Skills, or open [Claude Skills](https://claude.ai/customize/skills).\n3. Upload `daee-epistemics.skill`.\n4. Enable the skill and test it with a query that should trigger epistemic diagnosis or objection handling.\n\n### Codex Invocation\n\nThe same `.skill` bundle may also work in Codex and other skill-capable agent\nplatforms. In Codex, ordinary use should stay simple:\n\n```text\n/daee-epistemics [input]\n```\n\nThe canonical portable behavior for `/daee-epistemics [input]` is the compact\nDSL-governed surface. Runtimes produce that surface directly; there is no prose-only\nfallback and the user should not need a special long prompt to activate it. When a host's\nfinal-chat channel compresses hard cases, use the canonical file-retained syntax:\n\n```text\n/daee-epistemics \u003c C:\\path\\input.md \u003e C:\\path\\output.md\n```\n\nThat syntax is an output transport mode, not prompt engineering and not the optional\nroute/check harness.\n\n### Maintainer Optional Route/Check Harness\n\nThe optional script-capable route/check harness is repo/dev machinery. It can make\nrouting executable rather than merely interpretive for maintainers, but it is not the\npublic identity of the skill, is not packaged in the canonical user-facing artifact, and\nis not the active push/PR execution path. Some implementation files still use the\nhistorical `level3` / `daee_level3` names until a deliberate harness-rename migration:\n\n```text\npython skill/scripts/daee_level3.py --input \u003cinput.md\u003e --out \u003crun-dir\u003e\n```\n\nIt produces `features.json`, `route_plan.json`, reconstruction/validation\nverdicts, and, when the route is valid, `execution_prompt.md`. If route\ngeneration writes `execution_blocked.md`, return that visible PARTIAL/block\nnote and do not execute an ordinary answer. After the model answers from a\nvalid execution prompt, validate the answer against the route plan:\n\n```text\npython scripts/check_execution.py --route \u003crun-dir\u003e/route_plan.json --output \u003crun-dir\u003e/output.md\n```\n\nIf execution validation returns `partial` or `fail`, a maintainer-facing report\nshould include:\n\n```text\nPARTIAL - script-harness execution check: \u003cspecific defect\u003e\n```\n\nHonest maintainer claim: the repository includes deterministic routing\n(`route.py`) over span-backed feature extraction (`diagnose.py`), with route\nplans validated by reconstruction (`reconstruct.py`) and post-output execution\nchecked (`check_execution.py`). That route/check harness is excluded from the canonical\nuser-facing package unless a future dev artifact is explicitly created. Routing is deterministic given features.\nFeature extraction has interpretive components with input-span validation.\nTransformer execution remains probabilistic; highest-complexity burdens remain\nbounded by model capability even under optional script-harness routing. Pure-Hermes parity,\nfixture-18 resolution, catalogue-wide executable harness coverage, codons, and\nowner packs are not claimed.\n\n### Scriptless Compact DSL Runtime\n\nRuntimes that cannot execute repo/dev harness scripts must still produce the canonical compact\nDSL-governed surface. If they label the harness boundary, use a provenance note like:\n\n```text\nOptional script route/check harness unavailable - using canonical compact DSL-governed surface\n```\n\nScriptless compact DSL runtime preserves the governance in `SKILL.md`, but\nit does not claim optional harness route-plan validation or post-output execution\nchecking.\n\n### Maintainer Commands\n\nBefore release, regenerate and verify the runtime with the command set in\n[Source / Runtime Layout](#source--runtime-layout). Maintainers may run the\nlegacy-named optional harness fixtures locally for route/check debugging with:\n\n```text\npython skill/scripts/daee_level3.py --run-fixtures --simulate-output --repeat-stability 5\n```\n\nAny `--simulate-output` run is simulated structural route/check verification only. It must not\nbe reported as behavioral smoke, real model execution, or scriptless shrinkage-regression\nrecovery. Active push/PR CI should not use this legacy harness run as release proof.\n\n### Release Smoke Boundary\n\nSmoke tests should use the current package filename and SHA recorded in\n[`docs/release-artifacts.md`](docs/release-artifacts.md).\nDo not use `build/compiled-skill/` or older local archives as smoke-test inputs. Smoke suites are\nlocal evidence by default and should remain ignored unless a task explicitly authorizes a tracked\nfixture suite.\n`tools/check_smoke_artifacts.py` also compares smoke package provenance against\n`docs/release-artifacts.md` when a smoke root is supplied and rejects unmarked package-hash drift.\nWhen a current-release smoke suite is truthfully regenerated, run\n`python tools/check_smoke_artifacts.py --require-current-release-smokes` as a release-promotion\ncheck. In this source state, no committed smoke suite exists, so the strict flag is expected to fail\nuntil current-release smokes exist.\nCurrent readiness checks and smoke prompts live in [`docs/package-smoke-readiness.md`](docs/package-smoke-readiness.md).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftheislampill%2Fdaee-epistemics","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftheislampill%2Fdaee-epistemics","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftheislampill%2Fdaee-epistemics/lists"}