限界

The narrow authority described elsewhere is a property of the scheduled evidence cycle, not of the machine. A separate periodic process on the same host seals working trees: it stages the entire tree with no path restriction, commits under a registered exemption from the commit-scope check, and pushes to the default branch under the operator's credential. It therefore reaches everything the cycle is prevented from reaching — schemas, validators, the promotion gate itself, and the application — and it does so without any content-specific gate. This was observed rather than reasoned about: on 2026-08-13T21:14Z it committed four in-progress source edits that were sitting in the working tree and pushed them to production about four minutes after the scheduled cycle had finished. The edits were syntactically valid and the local suite was green at that moment, which is luck about timing rather than a control. The enrolment was also indirect: the sealer derives its targets from the list of enabled projects, so registering this repository as a tracked project subscribed it to the sealer as a side effect that nothing announced. Two consequences a reader should carry. The claim that a publisher may only cause data/ to change describes the publisher, and must not be read as describing every automated writer with access to this repository. And an unfinished edit left in the working tree here is not private: it has a few minutes' half-life before it may be public. The remote ruleset still blocks the publisher's own deploy key from the default branch, so that boundary holds as stated; what is disclosed here is that it is not the only route in. [未翻訳]

適用対象

system

The probe will not judge a submission the record has not taken up. Ingestion is non-blocking in the scheduled cycle by design — the queue holds items for 180 days and a network failure there must not stop the measurement that follows — so a cycle can complete and publish having ingested nothing. If the probe judged then, one skipped fetch would terminally falsify this claim over a submission the next cycle would have carried. So it waits, and if its window expires with the submission still un-ingested the run is recorded as no measurement. The blind spot that leaves is real and is the reason this record exists: a pipeline that stops ingesting altogether produces silence here rather than a refutation, which is the one failure mode this instrument cannot report. It is visible in the cycle log, where each failed ingest is written, and in the queue depth — but not in this claim. Closing it needs a separate measurement of ingestion itself, on a claim of its own, rather than a timeout dressed up as a verdict. [未翻訳]

適用対象

claim/challenge-from-outside-completes-once-the-record-is-public

Event pub/000301 is an attest on claim/scheduled-ingestion-carries-pending-challenges written by a regression test, not by anyone deciding to publish. Its actor reads agent:t, which is a fixture name. The content it binds is correct — the hash it carries is the claim's real content hash — so the record is not false, but the act was not intended and no one authorised it. The cause is worth stating exactly, because it is the second time in one session that a test reached a production path: scripts/lib/load.mjs derives ROOT from the module's own location, so a tool invoked with a different working directory still writes to the log sitting next to it. The test set cwd to a scratch directory and copied data/ and schemas/ there, believing that isolated it; it did not, and the mutation run of that very check appended this event. The test now copies scripts/ as well and invokes the copied tool, so the copy resolves its own ROOT into the scratch directory, and it asserts on every run that the real log did not grow. The event stays. It was committed and pushed to the branch production builds from before it was noticed, and removing it would rewrite a published chain, which is the single act this log exists to prevent. What has no mechanical guard is the general case: nothing stops another tool or test from resolving ROOT into the live tree, and the same class produced two separate incidents today — see limitation/two-probe-submissions-entered-the-queue-from-a-test. [未翻訳]

適用対象

system

実 producer から adapter が生成した記録は英語のみで公開される。翻訳するには実行ごとに人が日本語の散文を書くことになり、人の手順を避けるために作った経路へ人の手順を戻すことになる。したがって日本語ページはこれらの記録でのみ英語へフォールバックし、未翻訳と表示する。修正の方向は各実行を誰かが翻訳することではなく、adapter が同一テンプレートから両言語を出力することである。

適用対象

system

The path from an external challenge to a published evidence or falsification record has never been exercised end to end, because no external submission has been received. Each stage exists and the internal half of the loop runs unattended, but a loop that has not carried a real external observation is a design, not an observation. It is listed here rather than counted as working. [未翻訳]

適用対象

system

The autonomous path stops one step short of production. The publisher measures, validates, commits and pushes to the evidence branch unattended, and the promotion gate then verifies remotely that only evidence changed — both observed working. The final fast-forward to the production branch fails, because the branch rule that stops the publisher from reaching production also stops the promotion job, and the hosting platform only allows an automation identity to be exempted from such a rule on organization-owned repositories, not personal ones. The rule was not relaxed to work around this: relaxing it would let a compromised publisher reach production directly, which is the specific outcome the rule exists to prevent. Until the promotion job holds an owner-scoped credential, or the evidence lives in a repository the publisher writes to and the site does not, reaching production requires a person. [未翻訳]

適用対象

system

The hash chain makes alteration detectable to someone holding an earlier head. It does not make alteration impossible, and three specific gaps are worth naming rather than leaving for a reader to find. First, actor and gate are self-attested: an event carrying actor.kind "agent" and gate "automated" asserts those facts, and nothing signs them, so the chain records who the writer said it was. Second, entity bodies are not bound to the chain — the replay binds entity_ref and status, so a statement inside an entity file can be edited without breaking any hash, and only the separate content scan and review would notice. Third, whoever can write the log can recompute it end to end; the promotion gate now refuses a head whose events.jsonl is not a byte-extension of the published one, which constrains the automated route specifically, but that is a check on one path and not a cryptographic property of the record. The practical consequence for a reader: pin a head you have seen. Fetching the log once tells you what is being asserted now, not that it is what was asserted before. Independent signatures and entity-body binding are not implemented, and until they are, this record is evidence that can be audited rather than evidence that cannot be forged. [未翻訳]

適用対象

system

POST /api/challenges is deployed but cannot accept submissions: its storage and salt bindings do not exist in the hosting environment yet, and the session that built this surface has no credential able to create them. The endpoint therefore refuses with 503 and a machine-readable reason rather than accepting a submission it would drop. This is declared as unavailable in the capability list so an agent learns it from the contract instead of by having a submission disappear. [未翻訳]

適用対象

system

The instrument that refuted this claim could not have confirmed it. The lifecycle probe submitted a challenge to the production endpoint, waited five seconds, and then judged all four stages — while ingestion in this system runs once a day, on the scheduled cycle. No arrangement of the machinery could carry a submission to the public log inside that window, so the reading `stages_completed` could not exceed 1 and the verdict GREEN was unreachable for every possible state of the thing being measured. A test whose positive result is unreachable is not a strict test; it is a test that has already decided. The refutation recorded on 2026-08-13 was also true on the merits that day, because scheduled ingestion did not exist yet: it landed on 2026-08-14, and from then until 2026-08-16 the window alone held the reading down. This is disclosure, not repair of the verdict: the falsification stands as the record of what was said and measured, `falsified` is terminal here by design, and the corrected question is asked by a successor claim whose statement, falsifier and instrument all name the same window — one scheduled cycle. What this does not tell you is what the reading would have been between 2026-08-14 and 2026-08-16 had the window been right; nobody measured it, and the successor starts from now. [未翻訳]

適用対象

claim/external-agents-enter-verification-lifecycle

This surface is meant to be fetched by programs, and the edge refuses one of the commonest ways a program fetches. A request carrying Python's standard-library default User-Agent (Python-urllib/*) is answered 403 with Cloudflare error 1010 — the browser integrity check — before anything published here is consulted. The same URL returns 200 to curl, python-requests, ClaudeBot, GPTBot and a browser; measured 2026-08-15 against /api/state. The practical cost is borne by exactly the reader this site is for: the first ten lines a stranger writes to check the log, urllib.request.urlopen, come back refused, and a refusal at the edge is indistinguishable from the site not wanting to be read. Nothing in the record caused it and nothing in the record can repair it — the check is a zone setting, and the credential this project holds covers bot management and zone read only, so even reading that setting returns Unauthorized. Turning the check off across the whole site would pay for this with a protection that is otherwise doing its job; the narrower repair is to skip it for /api/ and /.well-known/, which needs a rule this project cannot currently write. Until one of those happens, the workaround is complete and costs one line: send any User-Agent header at all. [未翻訳]

適用対象

system

What is quarantined is the submitter's prose, not the submission. Four distinct facts, kept distinct: (1) submitter free text never enters the public pipeline — the intake computes a fixed-allowlist structured projection at write time and that projection is the only thing the pending listing serves; (2) only that structured projection enters the public lifecycle, where it traverses to experiments and evidence mechanically; (3) the raw private fields are structurally invisible to the publication producer — the machine that builds public records is never given them, so no review step exists to skip; (4) the input's trust level is untrusted_observation from receipt to published terminal state, and nothing a submitter writes can change a claim's status directly. The superseded record described an older design in which a human restatement stood between the queue and the log; that design was measured, falsified, and replaced. [未翻訳]

適用対象

system

人手を要さない公開経路が適用されるのは incierge 自身の記録だけである。外部からの提出は構造的に隔離されており、公開経路が読めない私的な保管先に入る。/external に載せるには、誰かが redaction 済みの再記述を data/ に書く必要がある。これは機能の欠落ではなく意図した境界である。素性の分からない第三者が書いた文章を自動公開すれば、任意の第三者コンテンツと、そこに含まれうる個人情報が、取り消す経路のないままこの面に載ることになる。

適用対象

system

The producer that audits the challenge lifecycle submits through the same endpoint it audits, so consecutive runs hit that endpoint's per-agent rate limit and measure the auditor's request budget rather than the loop. One evidence record already published under this claim was produced that way: it reports zero stages completed with the first open stage as acceptance, which is an artifact of a 429 and not a property of the endpoint — a manual submission minutes earlier returned 201. The producer now reports rate limiting explicitly and records such runs as inconclusive. The earlier record is left in place because evidence is not deleted here; this limitation is how it is corrected. [未翻訳]

適用対象

claim/external-agents-enter-verification-lifecycle

No independent party has reproduced any evidence on this surface, so every verification level honestly stops at self_verified. The acceptance contract for independent verification exists (see /api/schema, verification.schema.json): a third party may submit the evidence id, their reproduced result, environment, method and result hash, and the transition to independently_reproduced happens only when the correspondence machine-checks — an external party declaring 'verified' moves nothing by itself. This limitation stays open until a real verifier appears; it is not satisfiable by this project simulating one. [未翻訳]

適用対象

system

Promotion to production is now automated, and the honest cost of that is stated here. The hosted route remains blocked: the platform does not allow an automation identity to bypass a branch rule on a personal repository, so the scheduled cycle promotes locally instead, using the operator-held credential that already lives on the operating machine, constrained by the same data-only gate (any diff touching anything outside data/ is refused, as is any non fast-forward). On a single-operator machine this separation is procedural, not cryptographic: the remote branch rule is a hard boundary only against the publisher's own key, and a process that fully controlled this machine could use the operator credential directly. The superseded record said reaching production requires a person; it no longer does, and this record replaces that claim with the actual remaining weakness. [未翻訳]

適用対象

system

公開経路に人間の手順は存在しない。検証・射影・ビルド・配信は、誰かが内容を承認することなく実行され、/api/state は自動イベント数と人手イベント数を公開する。自律的でないのは**生成側**である。記録そのものは、いまだに人の指示を受けたエージェントが書いており、incierge が自分自身を観測して生成したものではない。この面を「自律的に公開されている」と言うのは正しく、「自律的に生成されている」と言うのは正しくない。

適用対象

system

The log covers the record types under data/ — claims, experiments, evidence, challenges, falsifications, limitations and external observations — and nothing else. It does not cover the prose that ships inside the page templates and the interface strings: a change to what a page says is built and deployed with no event, no sequence number and no content hash, and the head is the same afterwards as it was before. Observed on 2026-08-15: commit 313a683 added a Source section to /protocol and reached production (build_ref 313a683, snapshot generated_at 2026-08-15T07:07:22Z) while the head stayed at pub/000222, which the scheduled cycle had written the previous evening. Until then the log page described itself as the canonical artifact of which the rest of the site is a projection; that was true of record content and false of page copy, and the wording has been narrowed to what the log actually covers rather than left to overstate it. Placing page copy under the chain would require an entity type that does not exist yet, so for now the gap is declared rather than closed, and no check prevents a future page edit from asserting more than the records support. [未翻訳]

適用対象

system

One field of submitter prose is published, deliberately, and the superseded record denied it. The corrected account: (1) submitter free text does not enter the public pipeline except for expected_failure, which is projected because it is the submission's falsifier and a challenge protocol that discards the falsifier is not a challenge protocol — it is scanned at write time against a fixed list of secret shapes and withheld in its entirety on a hit, and no other free-text field is projected; (2) apart from that one field, only the structured allowlist projection computed at intake enters the public lifecycle, where it traverses to experiments and evidence mechanically; (3) the raw private fields are structurally invisible to the publication producer — the machine that builds public records is never given them, so no review step exists to skip; (4) the input's trust level is untrusted_observation from receipt to published terminal state, and nothing a submitter writes can change a claim's status directly. The superseded record opened by asserting that submitter free text never enters the public pipeline. The discovery document has described the expected_failure exception correctly since intake was built, so what was wrong was the limitation's own first clause, not the system it described. A limitation that overstates the guarantee is the same failure as a claim that overstates the result. [未翻訳]

適用対象

system

The successor claim registered earlier on 2026-08-16 said a submission completes the lifecycle within one scheduled cycle, and its instrument read production during that cycle. A cycle ingests at its first step and publishes near its last, so reading production in the middle of the cycle that ingested a submission shows the previous cycle's surface: the submission is in the local log and not yet on the surface being read. The reading would have been the same every time regardless of how well the machinery worked, and it would have terminally falsified the claim on the strength of the instrument's timing. That is the same defect the successor was written to correct, reintroduced one layer up, and it was found by independent review before any measurement was taken. The claim is retired rather than amended in place: it was never measured, no evidence bears on it, and rewriting a pre-registered falsifier after registering it is the move this log exists to make impossible. Its replacement waits on a published sequence number rather than on a cycle count, because a published sequence is a fact about the surface under test and cannot be satisfied by naming a new cycle. [未翻訳]

適用対象

claim/challenge-from-outside-completes-within-one-scheduled-cycle

The probe that measures this claim cannot submit a challenge against the claim itself, and the reason is worth stating rather than leaving as an oddity in the source. A challenge becomes an experiment only when its target claim has a registered producer, because the submitter's prose is withheld at intake by design and the deriving adapter has nothing else to work from. This claim's own measurement is two-phase, spanning cycles, which the registry cannot express — so it has no registered producer, and a challenge naming it would be marked unactionable and could never reach stages three or four. The probe therefore names a claim the pipeline is equipped to measure, claim/sample-read-surface-no-runtime-code, and what is under test is the pipeline rather than that claim. Two consequences, both real: the measurement says a submission travels, not that a submission about THIS claim travels; and a reader comparing the probe's target with the claim it settles will find they differ on purpose. Closing this needs the registry and the deriving adapter to carry a measurement that spans cycles, which is the same repair named in limitation/the-producer-registry-cannot-route-a-two-phase-measurement. [未翻訳]

適用対象

claim/challenge-from-outside-completes-by-the-next-publication

The probe that measures this claim cannot submit a challenge against the claim itself, and its target has to clear two independent gates that are easy to confuse. The first is the public intake, which matches the submitted target against the ITEMS of /api/claims.json and answers 400 unknown_claim_target for anything else — and a retracted claim is carried under `retired`, not `items`. The second is the producer registry, without an entry in which the deriving adapter marks the challenge unactionable, because the submitter's prose is withheld at intake by design and there is nothing else to derive a method from. The predecessor of this record named a target that cleared the registry and not the intake, which would have stopped the probe at stage one; before that it named a target that cleared neither. This claim's own measurement is two-phase and cannot be registered at all, so it can never be its own target. The probe now names claim/scheduled-ingestion-carries-pending-challenges, which is in the public items and has a registered producer that is a pure read of the record — deterministic, side-effect-free, and currently supporting its claim, so routing a challenge to it exercises the pipeline without disturbing what it measures. Two consequences remain, both real: the measurement says a submission travels, not that a submission about THIS claim travels; and if that target's producer ever returns an invalid measurement, no evidence is created and this claim reads RED for a reason that is about the target rather than about the traversal. [未翻訳]

適用対象

claim/challenge-from-outside-completes-by-the-next-publication

A challenge submitted from outside is routed to a measurement through the producer registry, and that registry can only express one shape of measurement: run a script, read one verdict, finish. The lifecycle probe cannot be that shape. It submits in one scheduled cycle and reads back in the next, because the ingestion it measures runs once a day, so a single invocation has nothing to report yet. Under the registry's contract that reply is indistinguishable from a permanent inability to measure, and the deriving adapter would move the challenge's experiment to a terminal inconclusive state on the submission run alone. The consequence, stated plainly: a challenge whose target is claim/challenge-from-outside-completes-within-one-scheduled-cycle will be routed to no producer. If it carries a usable reproduction it still becomes an experiment; if it does not, it is marked unactionable and the reason is published, which is the honest outcome and not a silent drop. The claim itself is still measured every cycle, by the scheduled path rather than by challenge routing. Closing this needs the registry and the deriving adapter to carry a measurement that spans cycles — a change to the routing contract, not to the probe. [未翻訳]

適用対象

system

Deciding when it is fair to read back a submission took three attempts, and the first two failed in the same direction: they permitted the reading while the answer was still in transit, which produces a refutation about the instrument's timing rather than about the machinery. The first said 'within one scheduled cycle' and read production during that cycle — but a cycle ingests at its first step and publishes near its last, so what it read was the previous cycle's surface. The second said 'once the published head has moved past where it stood at submission' — but the cycle before the ingesting one publishes too, and its publication satisfies that test while containing nothing about this challenge. Both would have reported the same refutation regardless of how well the pipeline worked. The boundary that holds is synchronisation: read back when the public head equals this record's head, because only then is an absent stage absent rather than on its way. Each mis-windowed claim was retired unmeasured rather than amended, because a pre-registered falsifier that can be rewritten after the fact is not a pre-registration. Recorded as a limitation because the pattern is the point: an instrument that cannot return its positive verdict is not strict, it has already decided, and three of the four ways this one acquired that property were invisible until an independent reader looked at the ordering of the machinery rather than at the code. [未翻訳]

適用対象

claim/challenge-from-outside-completes-by-the-next-publication

Everything the superseded record established still holds: a separate periodic process on this host seals working trees, stages the whole tree with no path restriction, commits under a registered exemption from the commit-scope check, and pushes to the default branch under the operator's credential, having been subscribed to this repository as a side effect of registering it as a tracked project. What that record could not yet state, it hedged: the in-progress edits it caught on 2026-08-13 were valid and the suite was green at that moment, which it called luck about timing rather than a control. On 2026-08-15T11:02:12Z the timing fell the other way. It caught a limitation record whose create and publish events had not been written yet, together with the interface string that referred to it, and pushed both. That tree does not pass the validator — an entity that never entered through the log is exactly what it refuses — and validation is the first step of the build, so no deployment could have been produced from it. The default branch carried a state that cannot build for about three minutes, until the missing events were appended and pushed. Two things follow, and they are the reason this record replaces its predecessor rather than sitting beside it. The sealer runs no gate of its own: the local suite the scheduled cycle must pass before it may commit is not on this path at all, so 'nothing that fails the suite reaches the default branch' is a property of the publisher and of no other writer here. And the exposure is not confined to an unfinished edit becoming visible; a partial write can also leave the repository unable to build, which is a failure the sealer cannot see because nothing on its path looks. [未翻訳]

適用対象

system

Events pub/000231 through pub/000268 carry timestamps between 2026-08-16T00:52:00Z and 2026-08-16T03:05:00Z, and none of them can be true. They were written by hand during a session that ran from about 2026-08-15T15:40Z to 2026-08-15T17:10Z, and the author stamped them with the local wall clock — Japan Standard Time, nine hours ahead — while labelling the field Z. The log therefore asserts that work happened up to ten hours before it could have. Every other check passed: the schema accepted the shape, the chain verified, the content bindings matched, the local suite was green. Nothing compared a timestamp against the present, so a record whose whole value is that things happened, in this order, at these times, had no opinion about the third of those. The events are not corrected. They are published, and this log does not rewrite what it published; a wrong record that stays visible with its error described is worth more than a tidy one. What has changed is that the validator now refuses any event from pub/000269 onward dated more than five minutes ahead of the clock reading it, so the same mistake cannot be made silently again. Anyone reconstructing the ordering of that session should read the git commit times, which are correct. [未翻訳]

適用対象

system

Two conforming challenges reached the live intake on 2026-08-15, between roughly 17:14Z and 17:16Z, from a regression test rather than from the measurement path. Both were accepted with HTTP 201 and are in the queue; the next scheduled cycle will ingest them, derive experiments named after them, and publish the results exactly as it would for any submission. Nothing about them is false — they carry declared_source producer/challenge-loop-audit and they conform — but they were not a measurement anyone intended to take, and a reader counting external submissions should know that two of them came from this machine. The cause: a test wrote an unreadable state file and ran the two-phase probe to check that it would not judge. With no pending probe the producer does the other thing it exists to do, which is submit. Because that suite runs inside the daily cycle, it would have added one submission per day indefinitely. The test now keeps every fixture on a branch that returns before the network, and says why. What this does not have is a mechanical guard: nothing stops a future test from reaching the submitting branch, and the queue has no path to withdraw a submission once accepted — by design, since an intake that can retract what it received is not an append-only record of what it received. [未翻訳]

適用対象

system